Ohloh by Black Duck

 Follow @ Meta   Join Now

 Settings |  Report Duplicate
Very High Activity
2,874

News

  Analyzed 4 days ago based on code collected 5 days ago.
 
Søren Sandmann Pedersen: The Radix Heap
Posted 1 day ago
The Radix Heap is a priority queue that has better caching behavior
than the well-known binary heap, but also two restrictions: (a)
that all the keys in the heap are integers and (b) that you can never
insert a new item that is smaller ... [More] than all the other items currently
in the heap.

These restrictions are not that severe. The Radix Heap still works in
many algorithms that use heaps as a subroutine: Dijkstra’s
shortest-path algorithm, Prim’s minimum spanning tree algorithm,
various sweepline algorithms in computational geometry.

Here is how it works. If we assume that the keys are 32 bit integers,
the radix heap will have 33 buckets, each one containing a list of
items. We also maintain one global value last_deleted, which is
initially MIN_INT and otherwise contains the last value extracted
from the queue.

The invariant is this:

The items in bucket $k$ differ from last_deleted in bit $k - 1$,
but not in bit $k$ or higher. The items in bucket 0 are equal to
last_deleted.

For example, if we compare an item from bucket 10 to last_deleted,
we will find that bits 31–10 are equal, bit 9 is different, and bits
8–0 may or may not be different.

Here is an example of a radix heap where the last extracted value was
7:

As an example, consider the item 13 in bucket 4. The bit pattern of 7
is 0111 and the bit pattern of 13 is 1101, so the highest bit that is
different is bit number 3. Therefore the item 13 belongs in bucket $3
+ 1 = 4$. Buckets 1, 2, and 3 are empty, but that’s because a number
that differs from 7 in bits 0, 1, or 2 would be smaller than 7 and so
isn’t allowed in the heap according to restriction (b).

Operations
When a new item is inserted, it has to be added to the correct
bucket. How can we compute the bucket number? We have to find the
highest bit where the new item differs from last_deleted. This is
easily done by XORing them together and then finding the highest bit
in the result. Adding one then gives the bucket number:

bucket_no = highest_bit (new_element XOR last_deleted) + 1

where highest_bit(x) is a function that returns the highest set bit
of x, or $-1$ if x is 0.

Inserting the item clearly preserves the invariant because the new
item will be in the correct bucket, and last_deleted didn’t change,
so all the existing items are still in the right place.

Extracting the minimum involves first finding the minimal item by
walking the lowest-numbered non-empty bucket and finding the minimal
item in that bucket. Then that item is deleted and last_deleted is
updated. Then the bucket is walked again and all the items are
redistributed into new buckets according to the new last_deleted
item.

The extracted item will be the minimal one in the data structure
because we picked the minimal item in the redistributed bucket, and
all the buckets with lower numbers are empty. And if there were a
smaller item in one of the buckets with higher numbers, it would be
differing from last_deleted in one of the more significant bits, say
bit $k$. But since the items in the redistributed bucket are equal to
last_deleted in bit $k$, the hypothetical smaller item would then
have to also be smaller than last_deleted, which it can’t be because
of restriction (b) mentioned in the introduction. Note that this
argument also works for two-complement signed integers.

We have to be sure this doesn’t violate the invariant. First note that
all the items that are being redistributed will satisfy the invariant
because they are simply being inserted. The items in a bucket with a
higher number $k$ were all different from the old last_deleted in
the $(k-1)$th bit. This bit must then necessarily also be different
from the $(k-1)$th bit in the new last_deleted, because if it
weren’t, the new last_deleted would itself have belonged in bucket
$k$. And finally, since the bucket being redistributed is the
lowest-numbered non-empty one, there can’t be any items in a bucket
with a lower number. So the invariant still holds.

In the example above, if we extract the two ‘7’s from bucket 0 and the
‘8’ from bucket 4, the new heap will look like this:

Notice that bucket 4, where the ‘8’ came from, is now empty.

Performance
Inserting into the radix heap takes constant time because all we have
to do is add the new item to a list. Determining the highest set bit
can be done in constant time with an instruction such as bsr.

The performance of extraction is dominated by the redistribution of
items. When a bucket is redistributed, it ends up being empty. To see
why, remember that all the items are different from last_deleted in
the $(k - 1)$th bit. Because the new last_deleted comes from bucket
$k$, the items are now all equal to last_deleted in the $(k -
1)th$ bit. Hence they will all be redistributed to a lower-numbered
bucket.

Now consider the life-cycle of a single element. In the worst case it
starts out being added to bucket 31 and every time it is
redistributed, it moves to a lower-numbered bucket. When it reaches
bucket 0, it will be next in line for extraction. It follows that the
maximum number of redistributions that an element can experience is
31.

Since a redistribution takes constant time per element distributed,
and since an element will only be redistributed $d$ times, where $d$
is the number of bits in the element, it follows that the amortized
time complexity of extraction is $O(d)$. In practice we will often do
better though, because most items will not move through all the
buckets.

Caching performance
Some descriptions of the radix heap recommend implementing the buckets
as doubly linked lists, but that would be a mistake because linked
lists have terrible cache locality. It is better to implement them as
dynamically growing arrays. If you do that, the top of the buckets
will tend to be hot which means the per-item number of cache misses
during redistribution of a bucket will tend to be $O(1/B)$, where $B$
is the number of integers in a cache line. This means the amortized
cache-miss complexity of extraction will be closer to $O(d/B)$ than to
$O(d)$.

In a regular binary heap, both insertion and extraction require
$\Theta(\log n)$ swaps in the worst case, and each swap (except for
those very close to the top of the heap) will cause a cache miss.

In other words, if $d = \Theta(\log n)$, extraction from a radix heap will
tend to generate $\Theta(\log n / B)$ cache misses, where a binary heap will
require $\Theta(\log n)$. [Less]
Pekka Paalanen: Weston on Raspberry Pi Accelerated
Posted 2 days ago
Raspberry Pi is a nice tiny computer with a relatively powerful VideoCore graphics processor, and an ARM core bolted on the side running Linux. Around October 2012 I was bringing Wayland to it, and in November the Weston rpi-backend was merged ... [More] upstream. Unfortunately, somehow I did not get around to write about it. In spring 2013 I did a follow-on project on the rpi-backend for the Raspberry Pi Foundation as part of my work for Collabora. We are now really pushing Wayland forward on the Raspberry Pi, and strengthening Collabora's Wayland expertise on all fronts. In the following I will explain what I did and how the new rpi-backend for Weston works in technical terms. If you are more interested in why this was done, I refer you to the excellent post by Daniel Stone: Weston on Raspberry Pi.

Bringing Wayland to Raspberry Pi in 2012

Raspberry Pi has EGL and GL ES 2 support, so the easiest way to bring Wayland was to port Weston. Fortunately unlike most Android-based devices, Raspberry Pi supports normal Linux distributions, and specifically Raspbian, which is a variant of Debian. That means very standard Linux desktop stuff, and easy to target. Therefore I only had to write a new Raspberry Pi specific backend to Weston. I could not use any existing backend, because the graphics stack does not support DRM nor GBM, and running on top of (fbdev) X server would void the whole point. No other usable backends existed at the time.

The proprietary graphics API on RPi is Dispmanx. Dispmanx basically offers a full 2D compositor, but since Weston composited with GL ES 2, I only needed enough Dispmanx to get a full-screen surface for EGL. Half of the patch was just boilerplate to support input and VT handling. All that was fairly easy, but left the Dispmanx API largely unused, not hooking up to the real performance of the VideoCore. Sure, GL ES 2 is accelerated on the VideoCore, too, but it is a much more complex API.

I continued to take more advantage of the hardware compositor Dispmanx exposes. At the time, the way to do that was to implement support for Weston planes. Weston planes were developed for taking advantage of overlay hardware. A backend can take suitable surfaces out from the scenegraph and composite them directly in hardware, bypassing the GL ES 2 renderer of Weston. A major motivation behind it was to offload video display to dedicated hardware, and avoid YUV-RGB color conversion and scaling in GL shaders. Planes allow also the use of hardware cursors.

The hardware compositor on RPi is partially firmware-based. This means that it does not have a constant limit in number of overlays. Standard PC hardware has at most a few overlays if any, the hardware cursor included. The RPi hardware however offers a lot more. In fact, it is possible to assign all surfaces into overlay elements. That is what I implemented, and in an ideal case (no surface transformations) I managed to put everything into overlay elements, and the GL renderer was left with nothing to do.

The hardware compositor does have its limitations. It can do alpha blending, but it cannot rotate surfaces. It also does have a limit on how many elements it can handle, but the actual number depends on many things. Therefore, I had an automatic fallback to the GL renderer. The Weston plane infrastructure made that very easy.

The fallback had some serious downsides, though. There was no way to synchronize all the overlay elements with the GL rendering, and switches between fallback and overlays caused glitches. What is worse, memory consumption exploded through the roof. We only support wl_shm buffers, which need to be copied into GL textures and Dispmanx resources (hardware buffers). As we would jump between GL and overlays arbitrarily and per surface, and I did not want to copy each attached buffer to both of texture and resouce, I had to keep the wl_shm buffer around, just in case it needs to jump and copy as needed. That means that clients will be double-buffered, as they do not get the buffer back until they send a new one. In Dispmanx, the elements, too, need to be double-buffered to ensure that there cannot be glitches, so they needed two resources per element. In total, that means 2 wl_shm buffers, 1 GL texture, and 2 resources. That is 5 surface-sized buffers for every surface! But it worked.

The first project ended, and time passed. Weston got the pixman-renderer, and the renderer interfaces matured. EGL and GL were decoupled from the Weston core. This made the next project possible.

Introducing the Rpi-renderer in Spring 2013

Since Dispmanx offers a full hardware compositor, it was decided that the GL renderer is dropped from Weston's rpi-backend. We lose arbitrary surface transformations like rotation, but on all other aspects it is a win: memory usage, glitches, code and APIs, and presumably performance and power consumption. Dispmanx allows scaling, output transforms, and alpha channel mixed with full-surface alpha. No glitches as we do not jump between GL and overlays anymore. All on-screen elements can be properly synchronized. Clients are able to use single buffering. The Weston renderer API is more complete than the plane API. We do not need to manipulate complex GL state and create vertex buffers, or run the geometry decimation code; we only compute clips, positions, and sizes.

The rpi-backend's plane code had all the essential bits for Dispmanx to implement the rpi-renderer, so lots of the code was already there. I took me less than a week to kick out the GL renderer and have the rpi-renderer show the desktop for the first time. The rest of a month's time was spent on adding features and fixing issues, pretty much.

Graphics Details

Rpi-backend

The rpi-renderer and rpi-backend are tied together, since they both need to do their part on driving the Dispmanx API. The rpi-backend does all the usual stuff like opens evdev input devices, and initializes Dispmanx. It configures a single output, and manages its updates. The repaint callback for the output starts a Dispmanx update cycle, calls into the rpi-renderer to "draw" all surfaces, and then submits the update.

Update submission is asynchronous, which means that Dispmanx does a callback in a different thread, when the update is completed and on screen, including the synchronization to vblank. Using a thread is slightly inconvenient, since that does not plug in to Weston's event loop directly. Therefore I use a trick: rpi_flippipe is essentially a pipe, a pair of file descriptors connected together. Write something into one end, and it pops out the other end. The callback rpi_flippipe_update_complete(), which is called by Dispmanx in a different thread, only records the current timestamp and writes it to the pipe. The other end of the pipe has been registered with Weston's event loop, so eventually rpi_flippipe_handler() gets called in the right thread context, and we can actually handle the completion by calling rpi_output_update_complete().

Rpi-renderer

Weston's renderer API is pretty small:
There are hooks for surface create and destroy, so you can track per-surface renderer private state.The attach hook is called when a new buffer is committed to a surface.The flush_damage hook is called only for wl_shm buffers, when the compositor is preparing to composite a surface. That is where e.g. GL texture updates happen in the GL renderer, and not on every commit, just in case the surface is not on screen right now.The surface_set_color callback informs the renderer that this surface will not be getting a buffer, but instead it must be painted with the given color. This is used for effects, like desktop fade-in and fade-out, by having a black full-screen solid color surface whose alpha channel is changed.The repaint_output is the workhorse of a renderer. In Weston core, weston_output_repaint() is called for each output when the output needs to be repainted. That calls into the backend's output repaint callback, which then calls the renderer's hook. The renderer then iterates over all surfaces in a list, painting them according to their state as needed.Finally, the read_pixels hook is for screen capturing.The rpi-renderer per-surface state is struct rpir_surface. Among other things, it contains a handle to a Dispmanx element (essentially an overlay) that shows this surface, and two Dispmanx resources (hardware pixel buffers); the front and the back. To show a picture, a resource is assigned to an element for scanout.

The attach callback basically only grabs a reference to the given wl_shm buffer. When Weston core starts an output repaint cycle, it calls flush_damage, where the buffer contents are copied to the back resource. Damage is tracked, so that in theory, only the changed parts of the buffer are copied. In reality, the implementation of vc_dispmanx_resource_write_data() does not support arbitrary sub-region updates, so we are forced to copy full scanlines with the same stride as the resource was created with. If stride does not match, the resource is reallocated first. Then flush_damage drops the wl_shm buffer reference, allowing the compositor to release the buffer, and the client can continue single-buffered. The pixels are saved in the back resource.

Copying the buffer involves also another quirk. Even though the Dispmanx API allows to define an image with a pre-multiplied alpha channel, and mix that with a full-surface (element) alpha, a hardware issue causes it to produce wrong results. Therefore we cannot use pre-multiplied alpha, since we want the full-surface alpha to work. This is solved by setting the magic bit 31 of the pixel format argument, which causes vc_dispmanx_resource_write_data() to un-pre-multiply, that is divide, the alpha channel using the VideoCore. The contents of the resource become not pre-multiplied, and mixing with full-surface alpha works.

The repaint_output callback first recomputes the output transformation matrix, since Weston core computes it in GL coordinate system, and we use framebuffer coordinates more or less. Then the rpi-renderer iterates over all surfaces in the repaint list. If a surface is completely obscured by opaque surfaces, its Dispmanx element is removed. Otherwise, the element is created as necessary and updated to the new front resource. The element's source and destination pixel rectangles are computed from the surface state, and clipped by the resource and the output size. Also output transformation is taken into account. If the destination rectangle turns out empty, the element is removed, because every existing Dispmanx element requires VideoCore cycles, and it is best to use as few elements as possible. The new state is set to the Dispmanx element.

After all surfaces in the repaint list are handled, rpi_renderer_repaint_output() goes over all other Dispmanx elements on screen, and removes them. This makes sure that a surface that was hidden, and therefore is not in the repaint list, will really get removed from the screen. Then execution returns to the rpi-backend, which submits the whole update in a single batch.

Once the update completes, the rpi-backend calls rpi_renderer_finish_frame(), which releases unneeded Dispmanx resources, and destroys orphaned per-surface state. These operations cannot be done any earlier, since we need to be sure the related Dispmanx elements have really been updated or removed to avoid possible visual glitches.

The rpi-renderer implements surface_set_color by allocating a 1×1 Dispmanx resource, writing the color into that single pixel, and then scaling it to the required size in the element. Dispmanx also offers a screen capturing function, which stores a snapshot of the output into a resource.

Conclusion

While losing some niche features, we gained a lot by pushing all compositing into the VideoCore and the firmware. Memory consumption is now down to a reasonable level of three buffers per surface, or just two if you force single-buffering of Dispmanx elements. Two is on par with Weston's GL renderer on DRM. We leverage the 2D hardware for compositing directly, which should perform better. Glitches and jerks should be gone. You may still be able to cause the compositing to malfunction by opening too many windows, so instead of the compositor becoming slow, you get bad stuff on screen, which is probably the only downside here. "Too many" is perhaps around 20 or more windows visible at the same time, depending.

If the user experience of Weston on Raspberry Pi was smooth earlier, especially compared to X (see the video), it is even smoother now. Just try the desktop zoom (Win+MouseWheel), for instance! Also, my fellow collaborans wrote some new desktop effects for Weston in this project. Should you have a company needing assistance with Wayland, Collabora is here to help.

The code is available in the git branch raspberrypi-dispmanx, and in the Wayland mailing list. On May 23rd, 2013, the Raspberry Pi specific patches are already merged upstream, and the demo candy patches are waiting for review.

Further related links:
Raspberry Pi Foundation, Wayland preview
Collabora, press release [Less]
Daniel Stone: Weston on Raspberry Pi
Posted 3 days ago
One of the platforms we’ve been working on for a while at Collabora is the Raspberry Pi. Obviously the $25 pricepoint makes it hugely appealing to a lot of people — including free software developers who up until now have managed to avoid ... [More] the agonyjoy we experience on a daily basis working on embedded and mobile platforms — but there are a couple of aspects which speak specifically to us as a company.

Firstly, we did quite a bit of work on OLPC through the years, which had a similar, very laudable, educational mission encouraging not just deep computer literacy in children, but also open source involvement. The Raspberry Pi has broadly the same aims, a very education-friendly pricepoint, and has seen huge success.

Less loftily, it’s a great example of a number of architectures we’ve been quietly working on for quite some time, where hugely powerful special-purpose (i.e. not OpenGL ES) graphics hardware goes nearly unused, in favour of heavily loading the less powerful CPU, or pushing everything through GL.

 

background etc

The Raspberry Pi has a Broadcom BCM2385 SoC in it, containing an extremely beefy (roughly set-top-box-grade) video, media and graphics processor called the VideoCore (somewhat akin to a display controller, GPU and DSP hybrid), and a … somewhat less beefy general-purpose ARMv61 CPU. The ARM side does everything you’d expect, whereas the VideoCore is a multi-functional beast, acting as the GPU for OpenGL ES, the display engine for outputs/overlays/etc, and also any general-purpose processing (e.g. accelerated JPEG decode).

In terms of how this looks from the ARM, the VideoCore exposes its display functionality through DispManX, an API for display control similar, in capability at least, to KMS. The DispManX exposes a number of output displays, each of which can have a number of planes (sometimes called overlays or sprites) which can each be in different colourspaces (think: video), scaled, alpha-blended, or variously stacked. No surprise there, as this is how most GPUs and display controllers look everywhere: from your phone, to your desktop, to your set-top box.

A recurring theme for us is how to properly use and expose these overlays. There’s a huge benefit in doing so over using GL: not only are they a lot faster, but they also have hugely better quality when doing colourspace conversion and scaling, and extra filters for much better image quality2. There’s also a pretty strong power argument to be made; at one stage, measuring on a phone, we found a 20% runtime difference — from 4 hours to a bit over 5 — when watching videos using the overlay, compared to pumping them through GL ES. And that was without the zerocopy support we enjoy nowadays!

The X Video extension (Xv) exposes overlays in a very limiting and frustrating way, meaning they’re only really suitable for video, and even then aren’t capable of zerocopy.  DRI2 video support was proposed to fix this, but so far TI’s OMAP is the only real deployment of this, and client support is very patchy.

Even then, this is only applicable to video. Under the X11 model, effectively the only way to do compositing is for an external process to render the entire screen as a single image, then pass that image to the X server to display. This is fine for GL, since that’s exactly what it’s built for, but it means you’re never going to get to use all your lovely 2D compositing hardware. Either that, or you do offload compositing inside the X server: something very difficult which almost no-one does, not only because it means no compositing. And no compositing means that your desktop is all back to 1995, with those attractive flickering backgrounds and jittery resizes. :(

 

i thought this was about rpi … ?

We’ve been working with the Raspberry Pi Foundation since last year, when we first brought up Weston on Raspberry Pi. At that stage, Weston was still very heavily GLES-based, but was able to opportunistically pull individual surfaces out into overlays if the conditions were right. This worked, and was all well and good, but was an awkward abuse of Weston’s internal model, and made RPi look rather unlike any other backend.

Fast forward to a couple of months ago, and Weston had come a long way along the road towards 1.1. A pretty vital piece for us was the renderer infrastructure: whereas Weston previously only had pluggable backends controlling the final display output backend (think: KMS, fbdev, RDP), it now gained a similar split for the renderers.

The original split was between the original GLES renderer and a purely-software Pixman renderer (which was still capable of everything the GLES renderer was!), but it was also a perfect fit for DispManX. So, the first thing Pekka did, and the base of all our work since, was to split the RPi backend into a backend and a renderer, allowing us to guarantee that we’d never fall back to GLES. This lets us feed the entire set of windows into the hardware, complete with stacking order, alpha blending, and 2D transforms, and have the VideoCore take care of everything, all fully synchronised and tear-free. Without using GL!

Pekka’s blog has more of the gory details on both the Weston internals, and how DispManX works.

 

shiny demos

Seemingly no-one can talk about open source graphics without getting all misty-eyed over wobbly windows; what good is straight tech with nothing to show for it? So, while Pekka worked on the renderer, Louis-Francis and myself knocked up a couple of demos to show off what we could do with 2D compositing alone.

The first, and most compelling, demo is in our case study,  in which Louis-Francis drags some windows around under both X11 and Weston for the camera. X11 struggles badly, whereas Weston with its VideoCore backend keeps up like a champ.

Louis-Francis then added an optional fade layer, where all the background windows were dimmed, complete with a nice fading animation between foreground and background. This is done internally with one or two solid-colour surfaces, with varying alpha.

Last but not least, I added a reimplementation of GNOME3′s window overview mode. It is a little on the rudimentary side, and does certainly suffer from not having an established layout/packing framework to use, but does work, and I think provides a pretty good demonstration of the kinds of smooth and fluid animations that are totally possible without ever touching GLES. And the best part is that windows zoom around, scaled and alpha-blended, at 60fps, whereas X11 struggles to get to 10fps just moving an unscaled, opaque, window. Yeesh.

And then some of the details were just that: details. Pekka add a new background scaling mode which preserves aspect ratio, Louis-Francis and Pekka worked to make sure the memory usage was always as low as humanly possible, including an optional mode where we trade strict visual correctness for performance and memory usage, we fixed some bugs in the XWayland emulation, and some bugfixes.

 

sounds great; how do i get it?

The source is already winging its way upstream; currently, the renderer has been merged, but some of the effects are still oustanding. In the meantime, you can clone Pekka’s repository:

$ git clone git://git.collabora.co.uk/git/user/pq/weston
$ cd weston
$ git checkout origin/raspberrypi-dispmanx-wip

Or we’ve also got Raspbian packages, based on the stable 1.0.x rather than unreleased git:

# echo deb http://raspberrypi.collabora.com wheezy rpi >> /etc/apt/sources.list
# apt-get update
# apt-get install weston

 

tl;dr

A lot of hardware — particularly in the media/embedded/mobile space — ships with hugely powerful special-purpose graphics hardware, aside from the usual OpenGL ES. Up until now, this special-purpose hardware has gone unused, but for equally special-purpose hacks. The work we’ve done with Weston and Raspberry Pi, using only its dedicated 2D compositing hardware, is a fantastic example of what we can do with Wayland and these kinds of platforms in general, without using GL ES.

 

now convince your boss

Would you love us to shut up and take your money, but just need that little bit extra to persuade those humourless lot up in purchasing? Fear not: we have an entire case study for the work we’ve done on the Raspberry Pi, as well as a general graphics page. Raspberry Pi have a writeup themselves too. Or maybe you’re more impressed (ha) by press releases? Either way, our trained operators are standing by to take your call.

ARMv6 is the sixth iteration of the ARM architecture; the chip family is ARM11, which was the generation immediately pre-Cortex. Various ARM11s were used in, e.g., the Nokia N810, the iPhone 3G, and the Nintendo 3DS. If you’re confused by the ARM nomenclature, Wikipedia has a really good table.Fun side note: if you want zero-copy video through GL, thanks to the unbelievably harsh wording of GL_OES_EGL_image_external, then you’re only allowed to use linear or nearest filtering. Not even bilinear, and definitely nothing near what overlays can do. [Less]
Nagappan Alagappan: [Ann]: Cobra 3.5 - Windows GUI test automation tool
Posted 3 days ago
New features:
* ooldtp python client
* Support setting text on combo box
* Added simple command line options
* Support state.editable in hasstate
* Handle valuepattern in click API
* Support ToolBar type on click
* Write ... [More] to log file if environment variable is set (set LDTP_LOG_FILE=c:\ldtp.log)
* Support control type Table, DataItem in Tree implementation
* Added scrollbar as supported type

New API:
* MouseMove
* setcellvalue
* guitimeout
* oneup
* onedown
* oneleft
* oneright
* scrollup
* scrolldown
* scrollright
* scrollleft

Bugs fixed:
* Fix to support taskbar with consistent index
* istextstateenabled API
* Fallback to object state enabled if value pattern is not available
* Fix to support InvokePattern on Open button
* Use width, height if provided while capturing screenshot
* Work around for copying text to clip board
* QT 5.0.2 specific changes
* Check errno attribute to support cygwin environment
* Fix keyboard APIs with new supported key controls (+, -, :, ;, ~, `, arrow up, down, right, left)
* Don't grab focus if type is tab item

Java client:
* Fixed selectRow arguments
* Fixed compilation issues
Python client:
* Fix optional argument issue in doesrowexist
C# client:
* Added new APIs (scrollup, scrolldown, scrollleft, scrollright, oneup, onedown, oneleft, oneright)
Ruby/Perl client: No changes

Credit:

Nagappan Alagappan, John Yingjun Li, Helen Wu, Eyas Kopty, VMware colleagues

Please spread the word and also share your feedback with us (email me).

About LDTP:

Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM.

* Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution.
* Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version.
* Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it.

Download source / binary (Windows XP / Vista / 7 / 8)
System requirement: .NET 3.5, refer README.txt after installation

Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org

LDTP API doc / Java doc
Report bugs [Less]
Aleksander Morgado: libmbim 1.0.0 released!
Posted 4 days ago
Just tagged a 1.0.0 release for libmbim, a library which helps you talk to MBIM-capable modems. You can read more about the MBIM protocol in the libmbim introduction blogpost I wrote some months ago. The 1.0.0 tarball is ready for download from ... [More] freedesktop.org:
 
http://www.freedesktop.org/software/libmbim/libmbim-1.0.0.tar.xz

If you want to easily talk to a MBIM device from a GLib-based application, you may want to check the libmbim API documentation.

libmbim is currently used by ModemManager (git master), but you can also now use it in standalone mode with either mbimcli (the command line utility) or mbim-network (a helper script to launch a connection):

# echo "APN=Internet" > /etc/mbim-network.conf
 
# mbim-network /dev/cdc-wdm0 start
Loading profile...
    APN: Internet
Starting network with 'mbimcli -d /dev/cdc-wdm0 --connect=Internet --no-close'...
Network started successfully
 
# mbim-network /dev/cdc-wdm0 status
Loading profile...
    APN: Internet
Getting status with 'mbimcli -d /dev/cdc-wdm0 --query-connection-state --no-close'...
Status: activated
 
# mbim-network /dev/cdc-wdm0 stop
Loading profile...
    APN: Internet
Stopping network with 'mbimcli -d /dev/cdc-wdm0 --disconnect'...
Network stopped successfully

As with libqmi’s qmi-network script, you’ll still need to run a DHCP client on the wwan interface after getting connected through MBIM. Note that your modem may not support DHCP… if that’s your case then patches are welcome to update the script to dump the IP configuration Or just use ModemManager, which works nicely with the static IP setup.

Enjoy!

Filed under: Development, FreeDesktop Planet, GNOME Planet, Lanedo Planet, Planets Tagged: libmbim, MBIM, ModemManager [Less]
Keith Packard: Altos1.2.1
Posted 4 days ago
AltOS 1.2.1 — TeleBT support, bug fixes and new AltosUI features

Bdale and I are pleased to announce the release of
AltOS version 1.2.1.

AltOS is the core of the software
for all of the Altus Metrum products. ... [More] It
consists of cc1111-based micro-controller firmware and Java-based
ground station software.

The biggest new feature for AltOS is the addition of support for
TeleBT, our ground station designed to operate with Android phones and
tablets. In addition, there’s a change in the TeleDongle radio
configuration that should improve range, some other minor bug fixes
and new features in AltosUI

AltOS Firmware — Features and fixes

There are bug fixes in both ground station and flight software, so you
should plan on re-flashing both units at some point. However, there aren’t
any incompatible changes, so you don’t have to do it all at once.

New features:

TeleBT support.

Improved radio sensitivity. The TeleDongle receiver parameters have
been tweaked to provide better reception.

TeleMini now completely resets all radio parameters in recovery
mode (with the two outer debug pins connected) — 434.550MHz,
N0CALL, factory radio cal.

Bug fixes:

USB device fixes. This improves operation with Windows, avoiding
hangs and errors in many cases.

Correct the Kalman filter error covariance matrix; the old
parameters were built assuming continuous measurements.

AltosUI — Easier to use

AltosUI has also seen quite a bit of work for the 1.2.1 release. It’s
got several fun new features and a few bug fixes.

New Graph UI features:

Show tool-tips with the value near the cursor.

Make the set of displayed values configurable. Add all of the
available data values just in case you want to see them.

Added a Map tab showing the ground track of the whole flight.

The flight summary tab now includes the final GPS position. This
lets you figure out where your rocket landed without replaying the
whole flight.

Other new AltosUI features:

TeleBT support, including Bluetooth connections (Linux-only, at
present).

Shows the callsign in the Monitor Idle and other command-mode
windows so that you can tell what callsign is being used.

Show the block number when downloading flight data. This lets
you see something happen even for longer flights.

Make the initial position of the AltosUI configurable so that you
can position it out of the way of the rest of you desktop.

Distribute Mac OS X in .dmg format (Mac OS Disk Image); this means
you don’t need to explicitly unpack the bits.

Bug fixes:

Deal with broken networking while downloading map tiles. Tiles
are now always downloaded asynchronously so that the UI doesn’t
freeze when the network is slow. [Less]
Rob Clark: gallium a3xx es2gears
Posted 6 days ago
So, I've been working on the freedreno gallium support for adreno a3xx  for the past few weeks or so, and now it is starting to take shape:

  The full video here.

The code is on the a3xx branch on github.. still has a ways got go ... [More] before I'm ready to go upstream with it, but now we're getting into the fun bits :-)

Special thanks to Benjamin Tissoires for getting the touchscreen going for me on the nexus4. [Less]
Nagappan Alagappan: Announce: LDTP 3.5 - Linux GUI test automation tool
Posted 10 days ago
Highlights:
New API:
* inserttext, objtimeout, guitimeout, getcellsize, getcellvalue,
getobjectnameatcoords, getcombovalue, getaccesskey in Python client
* doubleClick, doubleClickRow, onWindowCreate, getCellSize ... [More] , getComboValue,
appUnderTest, getAccessKey in Java client
* getcellsize, getcellvalue in Ruby client
* GetCellSize, GetComboValue, AppUnderTest, GetAccessKey, MouseRightClick,
DoubleClick, DoubleClickRow, RightClick in C# client

New control type:
* POPUP MENU for Ubuntu environment

Bugs fixed:
Ruby client:
* Fixed optional arguments to imagecapture
* Check window_name parameter, if empty then use @window_name passed in
constructor

Python client:
* Fixed optional argument APIs to work on both Windows and Linux
* imagecapture x, y offset, height and width parameters are disregarded if
window parameter is provided - Bug#685548
* Return unicode string all the time on gettextvalue
* Fix partial match argument in selectrow, compatible with Windows
* Patch by ebass to support Python 2.6
* Added Errno 101 as we see in ebass Ubuntu 10.04 environment

Core LDTP2
* Include label type on gettextvalue
* Don't include separators in the list

Perl client:
* Added perl client

Credit:
* Sawyer X for the Perl interface
* ebass (IRC nick name)
* Marek Rosa
* Thanks to all others who have reported bugs through forum / email /
in-person / IRC

About LDTP:
Cross Platform GUI Automation tool Linux version is LDTP, Windows version
is Cobra and Mac version is PyATOM.

* Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing /
LibreOffice / Mozilla application on all major Linux distribution.
* Windows version is known to work on application written in .NET / C++ /
Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version.
* Mac GUI testing is known to work on OS X Snow Leopard/Lion/Mountain Lion.
Where ever PyATOM runs, LDTP should work on it.

Download source / binary (RPM/DEB)

Documentation references: API / JavaDoc

For detailed information on LDTP framework and latest updates visit
http://ldtp.freedesktop.org

Report bugs

To subscribe to LDTP mailing lists

IRC Channel - #ldtp on irc.freenode.net

How can you help: Spread the news and send back your feedback to us [Less]
Ben Widawsky: i915.ko authors, by the numbers
Posted 13 days ago
Because of some event I cannot remember, I was curious to see which developers had how many lines of code. It turned out to be more of a challenge than I thought (mostly because of Unicode). Here is the top 10 from the very latest ... [More] drm-intel-nightly.

>./count_i915.py drivers/gpu/drm/i915/

total lines counted: 67417 (compare with git ls-files — ./drivers/gpu/drm/i915/ | xargs wc -l)
[('Jesse Barnes', 16255),
('Chris Wilson', 13174),
('Daniel Vetter', 11066),
('Eugeni Dodonov', 3636),
('Paulo Zanoni', 3434),
('Ben Widawsky', 2935),
('Eric Anholt', 2176),
('Keith Packard', 1773),
('Zhenyu Wang', 1703),
('Ville Syrjälä', 1130)]

 

And here is the slightly better than one-off script I used:

#!/usr/bin/env python3
import sys
import os
import subprocess
import re
import collections
import pprint

count = collections.Counter()
p = re.compile(r'.+ \(([\w\W]+) [0-9]{4}-[0-9]{2}-[0-9]{2}.*', re.UNICODE)

path=sys.argv[1]
git_path=os.path.dirname(sys.argv[0]) + "/" + path
os.chdir(git_path)
for file in os.listdir(os.getcwd()):
blame = subprocess.check_output(["git", "blame", "-w", "--abbrev=10", file],
stderr=subprocess.STDOUT)
for line in blame.splitlines():
m = p.match(str(line, 'utf-8'))
name = str(m.group(1))
name = name.rstrip()
count[name] += 1

print("total lines counted: " + str(sum(count.values())) + " (compare with git ls-files -- " + git_path + " | xargs wc -l)")
pprint.pprint(count.most_common(10))
EDIT: The code pretty printer doesn’t like ‘\’ and therefore 3 instances were missing in the first post. I’ve actually copy/pasted the version from the blog now and run it. [Less]
Matthias Klumpp: PackageKit, AppStream and Listaller – A status report
Posted 14 days ago
I was asked by some people to write a status report about the whole PK/AS/LI stuff – sorry guys that it took so much time to write it .

PackageKit
(PackageKit is an abstraction layer for package-management systems, allowing ... [More] applications to access the package-manager using simple DBus calls)

PackageKit is an incredibly successful project. With the 0.8.x series, it received many performance improvements, and has now the same speed on my computer than the distribution’s native tools. PackageKit is used in almost all major Linux distributions, except for Ubuntu[1]. But even Ubuntu has written some compatibility layer, so most calls to PackageKit will work.

The only major distro where PackageKit is currently not available, seems to be Gentoo (and I am not sure about the shape of the Gentoo PackageKit backend too).

Debian Wheezy includes PackageKit by default, and in Jessy we are going to replace some distribution-specific tools with PackageKit frontends (mostly the old and unmaintained update-notifier and Software-Updater – no worries, we are not going for a Synaptic replacement (currently this won’t be possible with PK anyway))

Unfortunately, some PackageKit backends are still not adjusted for the 0.8.x API and are only running on 0.7.x. This is bad, since 0.8.x is a huge step forward for PackageKit. But the situation is slowly improving, with the latest OpenSUSE release, the Zypper backend is now available on 0.8.x too.

Being able to run a PackageKit from the 0.8.x series is a requirement for both AppStream and Listaller.

AppStream
(AppStream is a cross-distro effort for building Software-Center-like applications. It contains stuff like a screenshot-service, ratings&reviews etc. The most important component is a Xapian database, storing information about all available applications in the distribution’s repositories. The Xapian DB is distro-agnostik, but distributors need to provide data to fill it. AppStream offers an application-centric way to look at a package database)

The AppStream side doesn’t look incredibly great, but the situation is improving. As far as I know, OpenSUSE is shipping AppStream XML to generate the database. Ubuntu ships the desktop-files, and I am working on AppStream support in Debian’s Archive Kit. On the Fedora side, negotiations with the infrastructure-team are still going on. I haven’t heard anything from Mageia and other AppStream participants yet.

Unfortunately, at least for OpenSUSE, the AppStream efforts seem to be stalled, due to people having moved to different tasks. But efforts to add the remaining missing things exist.

On the software side, Apper (KDE PackageKit frontend) has full support for AppStream. Apper just needs to be compiled with some extra flags to make it use the AppStream database.

On the GNOME-side, GNOME-Software is being developed. The tool will make use of the AppStream database, on distributions where it is available.

Also, a Software-Center for Elementary and other GTK+-based desktops is being developed, which is based on AppStream (already quite usable!).

Using the Ubuntu Software Center on not-Ubuntu-based distributions ist still not much fun, but with the AppStream database available and a working PackageKit 0.8.x with a backend which supports parallel transactions, it is possible to use it.

On the infrastructure side: I recently landed some patches in AppStream-Core, which will improve the search function a lot. AppStream-Core contains all tools necessary to generate the AppStream database. It also contains libappstream, a GObject-based library which can be used to access the AppStream database.

Also, we discuss dropping PackageKit’s internal desktop-file-cache in favour of using the AppStream database. If we do that, we will also add software descriptions to the AppStream db, to improve search results and to speed up search for applications. Because we have to deprecate API for that, I expect this change to happen with PackageKit 0.9.x.

As soon as the Freedesktop-Wiki is alive again and my account is re-enabled, I will create compatibility-list, showing which distribution implements what of the PK/AS/LI stuff, especially focusing on components needed for AppStream.

Only a few distributions package AppStream-Core so far. Although it is beta-software, creating packages for it and shipping the required data to generate the AppStream database would be a very huge step forward.

Listaller
(Listaller is a cross-distro 3rd-party software installer, which integrates into PackageKit and AppStream. It allows installing 3rd-party applications, which are not part of the distributor’s repositories, using standard tools used also for native-package handling. Everything which uses PackageKit can make use of Listaller packages too. Listaller also allows sandboxing of new applications, and uses an AppDir-like approach for installing software.)

Listaller is currently undergoing it’s last transition before a release with stable API and specifications can be made. Dependency solving will be improved a lot during the current release-cycle, making it less powerful, but working on all distributions instead. (Fedora always had an advantage in dependency-solving, due to RPM providing more package metadata for Listaller to use) This change was delayed due to discussing a possible use of ZeroInstall-feeds to provide missing dependencies with the ZeroInstall team. We did not come to a conclusion about extending the XML, so Listaller will contain an own format to define a dependency, which can reference a ZeroInstall feed. That should be a good solution for everyone.

All these changes will result in IPK1.2, a new version of the IPK spec with small changes in the pkoptions file syntax and huge changes in dependency-handling. The new code is slowly stabilizing in a separate branch, and will soon be merged into master.

The next Listaller release will be the last one of the 0.5.x series, we will start 0.6.x then. KDE currently has support for Listaller through Apper, which is enabled on a few distributions. In GNOME, optional Listaller support is being developed and will be available in one of the upcoming releases.

Currently, to my knowledge, only a few distributions package Listaller. This should improve, so it is easier for application developers to deploy IPK packages.

The upcoming changes in KDE and GNOME to build stable developer platforms will help Listaller a lot in finding matching dependencies, and for stuff which only depends on one software frameworks, installations should be a matter of seconds.

As you can see, lots of things are happening, and there is improvement in all components related to installing and presenting software on Linux machines. However, all these projects have a severe lack of manpower, especially AppStream and Listaller have the lowest number of developers working on the tools (at time, only two active developers). This is the main reason for the slow development. But I am confident that we will have something shipped in the next distribution releases. At least AppStream should be ready then.

[1]: I don’t blame Ubuntu for that – during the time they wrote an own solution, PackageKit did not have all the required features. (This situation has changed now, fortunately.)

NOTE: I might extend this post with feedback from the different distributions, as soon as I get it. [Less]
 

 
 

Project Summary

Code Data

SCM Data

Community Data

 

Creative Commons License Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.