X.Org

After fixing a handful of bugs, and adding support (still in a slightly hacky way) for some desktop GL (1.4) features (namely, GL_QUADS), I've got gnome-shell working with freedreno:Full video hereI've also made a sort of fedora F18 installer for the ... [More] touchpad, for anyone out there who wants to give it a spin:    https://github.com/freedreno/touchpad-fedoraNote that gnome-shell itself is not installed by default in the arm fedora builds.. so, 'sudo yum install gnome-shell' [Less]

Let’s forget for a second about video drivers, whether it has acceleration or not, and all the related issues with hardware support on Wayland. This is all solved. Let’s talk about the user interface (UI) and ways to customize it all over ... [More] the computing continuum — from phones, tablets and TV box to desktop PCs, Invehicle Infotainment (IVI), aeroplane systems, among others. (I’ve made a cheat sheet here also — Creative Commons Legal Code Attribution 2.0. for both figures) On customization, the shell plugin comes first: changes in there will impact directly which UI paradigm will be used. Specifically, one implementing the plugin protocol will be defining whether the UI is meant for phones, IVI, desktops, etc. Probably the most important characteristic of the shell plugin is to give ”roles” for surfaces, i.e. define where and how they will be mapped on the screen. For example, if a client wants its surface mapped as a top-level window, or say to resize the dimensions of it, then it’s up to the shell to expose these different surfaces roles, all according the UI paradigm the shell itself is providing. Worth to note that the shell plugin doesn’t need to rely on any drawing library or graphics toolkit because it doesn’t tackle directly drawing aspects. Also, conceptually it’s mandatory to give roles for surfaces and therefore a shell plugin is a must (or at least a simple implementation of surface::configure). An special shell client through an special “private” protocol can be used for setting up basic UI elements that require special treatment. For example in the desktop UI, widget elements such as panel, dock, lockscreen and cursors will need special treatments for their positioning, grabbing semantics and so forth. On customization, different shell clients, exposing different UI elements can be implemented using *the* *same* shell plugin. Some architectures will rather be using one overlay simple client that will take care of spawning and controlling other UI basics applications also. The special client will probably want to rely on graphics toolkits. Wayland clients use the Wayland core protocol and the protocol that shell plugin has defined. The corollary is that one client will always know the UI paradigm (due shell plugin) and will *not* work across different paradigms. Though, that doesn’t mean applications will need to know their paradigm necessarily but only the middleware software is connecting to Wayland (like the graphics toolkits). A footnote about Canonical’s Mir Canonical announced their new display manager yesterday. There’s a section ”Why Not Wayland / Weston?” where they claim: “we consider the shell integration parts of the protocol as privileged and we’d rather avoid having any sort of shell behavior defined in the client facing protocol.” and something similar was written here also: ” Wayland .. exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol” so they would rather have: “An outer-shell together with a frontend-firewall that allow us to port our display server to arbitrary graphics stacks and bind it to multiple protocols.” First of all, there’s nothing privileged about the shell protocol Wayland is exposing. wl_shell and wl_shell_surface (the “shell protocols”) are part of the Wayland core protocol, yes, but as I’ve explained on this post, it’s all customizable for whatever UI needs. Nevertheless, their usage is completely optional and anyone can build a different shell and stack with the rest of Wayland, just like tablet-shell protocol for instance does. Still, this will be Wayland and use the shiny libwayland for IPC. Therefore I don’t think Canonical should justify their new project because Wayland “does not fulfill .. requirements completely”. There are no technical reasons Ubuntu cannot use Wayland in principle. What they wrote there is a very very mean excuse instead. [Less]

The Ceilometer team is pleased to announce that tomorrow Tuesday 5th March 2013 will be the second bug squash day for Ceilometer. We wrote an extensive page about how you can contribute to Ceilometer, from updating the documentation, to fixing bugs. ... [More] There's a lot you can do. We've good support for Ceilometer built into Devstack, so installing a development platform is really easy. The main goal for this bug day will be to put Ceilometer in the best possible shape before the grizzly-rc1 release arrives (14th March 2013). This version of Ceilometer should be the last one before the final Grizzly release, so it's a pretty important one. We'll be hanging out on the #openstack-metering IRC channel on Freenode, as usual, so feel free to come by and join us! [Less]

I'm using a lot of branches. Almost one per feature or bug, and they add up quickly. Why I'm doing this doesn't matter for this post, but I found it to be a good workflow. The problem with that is of course that after a while I forget which branch ... [More] was for what, or what branch I worked on three weeks ago. So I started hacking up some git helpers. I pushed them to https://github.com/whot/git-branch-tools today, feel free to use them or improve on them. Archiving branches Some branches are not actively developed anymore but should still be preserved for posterity. These branches are clogging up the branch view. git archive-branch mybranch moves mybranch to archive/2013/mybranch and tags the current top commit with a message about the branch history. An example git branch output would look like this now: ... archive/2013/touch-test-libtool-linker-issues archive/2013/two-screen-coordinates archive/2013/wrong-signal-logging-merge archive/2013/xi2-protocol-tests archive/2013/xi21-confine-to archive/2013/xorg-conf-init-cleanup attic bugfix/xts-segfault devel fedora-17-branch fedora-rawhide-branch for-keith high-keycodes master memleak * next ... Showing recent branches Working on many branches can mean you forget which branch you worked on last week, or the week before. git recent-branches lists the various branches checked out over the history, including the date and last commit date on that branch. Example: next 4 hours ago last commit 6 days ago server-1.13-branch 4 hours ago last commit 2 weeks ago touch-grab-race-condition-56578-v2 3 days ago last commit 3 days ago touch-grab-race-condition-56578 4 days ago last commit 6 days ago † bug/xts-segfaults 6 days ago last commit 6 days ago † master 6 days ago last commit 3 weeks ago for-keith 10 days ago last commit 2 weeks ago memleak 13 days ago last commit 2 weeks ago The output above shows the branch name, last time that branch was checked out, last commit time and a marker that shows up if this branch doesn't exist anymore. There are a few more flags you can pass in too, including git log flags, so play around with it. Better branch descriptions Can't remember what branch "fix-race-condition" was? Me neither. That's what git branch-description [branchname] [upstream] will tell you. If upstream is given, it'll also show you what has been merged into upstream already (by patch, not by commit). Example again: :: whot@yabbi:~/xorg/xserver (next)> git-branch-description touch-grab-race-condition-56578-v2 Branch touch-grab-race-condition-56578-v2 Branched: Thu Feb 14 11:05:48 2013 -0800 Last commit: Fri Mar 1 16:37:49 2013 +1000 Fixes for https://bugs.freedesktop.org/show_bug.cgi?id=56578, second attempt ============================ Unmerged commits ============================= Commits on touch-grab-race-condition-56578-v2 not in next: 68b937046f278d53de14b586dbf7fd5aa7367f59 Xi: return !Success from DeliverTouchEmulatedEvent if we didn't deliver f8baab8ac32e5abb31bcd1bb4f74e82d40208221 Xi: use a temp variable for the new listener 9cbb956765c7b4f1572ab2100f46504bf6313330 dix: don't set non-exisiting flags on touch events 2a5b3f2f2293f4a428142fffdb1b6e8ffbbb5db0 dix: fix a comment 76e8756545951d7f13ca84a4bd24fe5f367c5de2 Xi: compress two if statements with the same body 61b06226a43839ed75126f9c54d47bc440285e21 dix: update coords for touch events in PlayReleasedEvents bd1a5423bbb02a349991a52f4997e830a0dc1992 Xi: add a comment to make a condition a bit clearer 78b26498085a7589e1f4d9ac3c21b69dc3227f87 Xi: not having an ownership mask does not mean automatic acceptance c7271c7e05cdbeb35a3558223f9c2d6544504c4c dix: don't prepend an activated passive grab to the listeners 71ee72c97e459ef76984e6da64e5dab0ce6e4465 Xi: if we delivered a TouchEnd to a passive grab, end it 9b6966187fd0e6fb7ad3c2c1073456d96e3adab0 Xi: if a pointer grabbing listener gets the touch end, the touch is over 5afef18196ce70faec3e94379c3e6d3767660c4a FIXME: Xi: fix lookup in ActivateEarlyAccept 3784283be1f482a0f039f2eb790c0c8c2cc4bedb Xi: update the core listener state if we delivered the event 3570ef1244c87aef92db97df6e2b921529ffb75a Xi: if a passive async grab is activated from an emulated touch, accept 9bef901d8e28d48f43da3167219b02ad1dba27d8 Xi: save state for early acceptance 7d51022becd5af124896817030a10eedf7f1783a Xi: when punting to a new owner, always create TouchEnd events 4775cdb0d9a2513edcf27a9c4c1916e8213c397b Xi: use public.processInputProc to replay the touch history 431b128b9138af7a208b63d4eb5b917d94c08129 Xi: Don't emit a TouchEnd event to a frozen device 4126d64f6a40d5568b2d1412d519325c02786c9a dix: AllowSome is equivalent to TouchAccept 33421e91a52be91d7121c7c2146ff7bb53bea638 dix: move EmitTouchEnd to touch.c 54f8884aef275b15f2c42e3350e2b4968124af01 dix: XAllowEvents() on a touch event means accepting it Commits on touch-grab-race-condition-56578-v2 already merged to next: ================================= Activity ================================= e7b4b83 HEAD@{5 hours ago}: checkout: moving from touch-grab-race-condition-56578-v2 to server-1.13-branch 9cbb956 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 9cbb956 d58ddeb HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to d58ddeb 7c3968b HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 7c3968b a354dd8 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to a354dd8 fdf4869 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to fdf4869 82be6b2 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 82be6b2 82be6b2 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 82be6b2 68b9370 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 68b9370 151eff1 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 151eff1 57fa0b9 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 57fa0b9 b43e866 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to b43e866 ef6a120 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to ef6a120 9064294 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 90642948cc78834d95f7a3bddaac7ff77b68ed7e 9064294 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 90642948cc78834d95f7a3bddaac7ff77b68ed7e 6513e0e HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 6513e0e 0d60ba6 HEAD@{3 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 0d60ba6 dd23302 HEAD@{4 days ago}: checkout: moving from f21354da571dcd39ae1423388298d5c61d3e736d to touch-grab-race-condition-56578-v2 f21354d HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to f21354da571dcd39ae1423388298d5c61d3e736d 0d60ba6 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 0d60ba6 ae2cac9 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to ae2cac99a75917d6c4d34b8aa4aeaec0b5d32da7 c2b3d37 HEAD@{4 days ago}: checkout: moving from d75925b9fb8b24c8134b5082294e82abf83294af to touch-grab-race-condition-56578-v2 0d60ba6 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 0d60ba683e7e95049c01ac5dba48a2f5fd80d9b9 c2b3d37 HEAD@{4 days ago}: checkout: moving from 0d60ba683e7e95049c01ac5dba48a2f5fd80d9b9 to touch-grab-race-condition-56578-v2 0d60ba6 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 0d60ba683e7e95049c01ac5dba48a2f5fd80d9b9 0d60ba6 HEAD@{4 days ago}: checkout: moving from 90642948cc78834d95f7a3bddaac7ff77b68ed7e to touch-grab-race-condition-56578-v2 9064294 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 90642948cc78834d95f7a3bddaac7ff77b68ed7e 8e5adb4 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578-v2 to 8e5adb4ef8bafa2a3188e69409e2908f80288311 033b932 HEAD@{4 days ago}: checkout: moving from touch-grab-race-condition-56578 to touch-grab-race-condition-56578-v2 And install the git-post-checkout-nagging-hook as your .git/hooks/post-checkout to make sure you get reminded to set the branch description. [Less]

After giving a talk at FOSDEM last month on this topic, I finally finished my work on GLX_MESA_query_renderer... at least finished enough to send out for review by a wider audience. The extension is modeled after Apple's CGLDescribeRenderer ... [More] interface. Before even embarking on this project, several ISVs told me that they really liked that interface. There are some small changes, but it's still pretty similar. The glXQueryRendererIntegerMESA and glXQueryRendererStringMESA functions allow applications query a bunch of aspects about the driver and hardware before creating a context: Driver version Driver vendor Hardware vendor (may be different from driver vendor!) Hardware chipset (PCI ID) Available memory UMA vs. non-UMA Supported and prefered (by the driver) GL profiles The last one is really important to know before creating a context because it may influence what sort of context that app creates. The initial branch, with the extension spec, is available at: http://cgit.freedesktop.org/~idr/mesa/log/?h=query-renderer [Less]

x-on-resize: a simple display configuration daemon I like things to be automated as much as possible, and having abandoned Gnome to their own fate and switched to xfce, I missed the automatic display reconfiguration stuff. I decided to write ... [More] something as simple as possible that did just what I needed. I did this a few months ago, and when Carl Worth asked what I was using, I decided to pack it up and make it available. Automatic configuration with a shell script I’ve had a shell script around that I used to bind to a key press which I’d hit when I plugged or unplugged a monitor. So, all I really need to do is get this script run when something happens. The missing tool here was something to wait for a change to happen and automatically invoke the script I’d already written. Resize vs Configure The first version of x-on-resize just listened for ConfigureNotify events on the root window. These get sent every time anything happens with the screen configuration, from hot-plug to notification when someone runs xrandr. That was as simple as possible; the application was a few lines of code to select for ConfigureNotify events, and invoke a program provided on the command line. However, it was a bit too simple as it would also respond to manual invocations of xrandr and call the script then as well. So, as long as I was content to accept whatever the script did, things were fine. And, with a laptop that had a DisplayPort connector for my external desktop monitor, and a separate VGA connector for projectors at conferences, the script always did something useful. Then I got this silly laptop that has only DisplayPort, and for which a dongle is required to get to VGA for projectors. I probably could write something fancy to figure out the difference between a desktop DisplayPort monitor and DisplayPort to VGA dongle, but I decided that solving the simpler problem of only invoking the script on actual hotplug events would be better. So, I left the current invoke-on-resize behavior intact and added new code that watched the list of available outputs and invoked a new ‘config’ script when that set changed. The final program, x-on-resize, is available via git at git://people.freedesktop.org/~keithp/x-on-resize I even wrote a manual page. Enjoy! [Less]

The OpenStack Technical Committee have voted these last weeks about graduation of Heat and Ceilometer, to change their status from incubation to integrated. The details of the discussion can be found in the TC IRC meetings logs for the brave. ... [More] The results are: Approve graduation of Heat (to be integrated in common Havana release)? yes: 10, abstain: 1, no: 1 Approve graduation of Ceilometer (to be integrated in common Havana release)? yes: 11, abstain: 1 Therefore both projects have been graduated from Incubation to Integrated status. That means that Heat and Ceilometer will be released as part as OpenStack for the next release cycle Havana, due in Autumn 2013. For people being curious, we the Ceilometer team put up a nice wiki page about our status and what we think we were ready to jump. For the curious, The OpenStack Technical Committee charter has some explanations about the incubation and integration process. What about Grizzly? Both projects will be released with Grizzly too, obviously, since they already follow the release process of OpenStack. What about core? The question that has been raised several times to me is if that means the projects are becoming Core projects. The answer is no, because how to become a Core project is still under discussion and is more a matter for the Board of Directors than the Technical Committee. But this is definitely a step in this direction. Anyway, from a technical point of view, this means both projects are now onboard with other OpenStack components so you can enjoy them! [Less]

DRI3000 — Even Better Direct Rendering This all started with the presentation that Eric Anholt and I did at the 2012 X developers conference, and subsequently wrote about in my DRI-Next posting. That discussion sketched out the goals of changing the ... [More] existing DRI2-based direct rendering infrastructure. Last month, I gave a more detailed presentation at Linux.conf.au 2013 (the best free software conference in the world). That presentation was recorded, so you can watch it online. Or, you can read Nathan Willis’ summary at lwn.net. That presentation contained a lot more details about the specific techniques that will be used to implement the new system, in particular it included some initial indications of what kind of performance benefits the overall system might be able to produce. I sat down today and wrote down an initial protocol definition for two new extensions (because two extensions are always better than one). Together, these are designed to provide complete support for direct rendering APIs like OpenGL and offer a better alternative to DRI2. The DRI3 extension Dave Airlie and Eric Anholt refused to let me call either actual extension DRI3000, so the new direct rendering extension is called DRI3. It uses POSIX file descriptor passing to share kernel objects between the X server and the application. DRI3 is a very small extension in three requests: Open. Returns a file descriptor for a direct rendering device along with the name of the driver for a particular API (OpenGL, Video, etc). PixmapFromBuffer. Takes a kernel buffer object (Linux uses DMA-BUF) and creates a pixmap that references it. Any place a Pixmap can be used in the X protocol, you can now talk about a DMA-BUF object. This allows an application to do direct rendering, and then pass a reference to those results directly to the X server. BufferFromPixmap. This takes an existing pixmap and returns a file descriptor for the underlying kernel buffer object. This is needed for the GL Texture from Pixmap extension. For OpenGL, the plan is to create all of the buffer objects on the client side, then pass the back buffer to the X server for display on the screen. By creating pixmaps, we avoid needing new object types in the X server and can use existing X apis that take pixmaps for these objects. The Swap extension Once you’ve got direct rendered content in a Pixmap, you’ll want to display it on the screen. You could simply use CopyArea from the pixmap to a window, but that isn’t synchronzied to the vertical retrace signal. And, the semantics of the CopyArea operation precludes us from swapping the underlying buffers around, making it more expensive than strictly necessary. The Swap extension fills those needs. Because the DRI3 extension provides an X pixmap reference to the direct rendered content, the Swap extension doesn’t need any new object types for its operation. Instead, it talks strictly about core X objects, using X pixmaps as the source of the new data and X drawables as the destination. The core of the Swap extension is one request — SwapRegion. This request moves pixels from a pixmap to a drawable. It uses an X fixes Region object to specify the area of the destination being painted, and an offset within the source pixmap to align the two areas. A bunch of data are included in the reply from the SwapRegion request. First, you get a 64-bit sequence number identifying the swap itself. Then, you get a suggested geometry for the next source pixmap. Using the suggested geometry may result in performance improvements from the techniques described in the LCA talk above. The last bit of data included in the SwapRegion reply is a list of pixmaps which were used as source operands to earlier SwapRegion requests to the same drawable. Each pixmap is listed along with the 64-bit sequence number associated with an earlier SwapRegion operation which resulted in the contents which the pixmap now contains. Ok, so that sounds really confusing. Some examples are probably necessary. If the SwapRegion operation was implemented by copying data out of the source pixmap into the destination drawable, then the idle swap count will be equal to the swap count from this SwapRegion operation. If the SwapRegion operation was implemented by swapping the destination contents with the source contents, then the idle swap count will be equal to the previous swap count on the destination drawable. I’m hoping you’ll be able to tell that in both cases, the idle swap count tries to name the swap sequence at which time the destination drawable contained the contents currently in the pixmap. Note that even if the SwapRegion is implemented as a Copy operation, the provided source pixmap may not be included in the idle list as the copy may be delayed to meet the synchronization requirements specfied by the client. Finally, if you want to throttle rendering based upon when frames appear on the screen, Swap offers an event that can be delivered to the drawable after the operation actually takes place. Because the Swap extension needs to supply all of the OpenGL SwapBuffers semantics (including a multiplicity of OpenGL extensions related to that), I’ve stolen a handful of DRI2 requests to provide the necessary bits for that: SwapGetMSC SwapWaitMSC SwapWaitSBC These work just like the DRI2 requests of the same names. Current State of the Extensions Both of these extensions have an initial protocol specification written down and stored in git: DRI3 protocol Swap protocol [Less]

A couple of weeks ago, Han-Wen Nienhuys, the author of go-mtpfs, pointed out to me that Android’s MTP implementation includes a set of methods that allow you to do normal read and write operations on files without having to do the whole ... [More] download/upload dance. With these extensions, you can expose files in the way that most people expect – you can just open a text file, picture, video etc, make changes and save it back. As a bonus, this functionality also allows you to do very useful operations like copy or move a file on the device. I’ve now had a chance to put together an initial implementation of support for these extensions, and my PPA is in the process of rebuilding packages, so people can try them out easily. I’ve not started the upstreaming process on the GVFS changes as I still need to get the libmtp changes approved and upstreamed, but the libmtp maintainer has been AWOL for a few weeks now. Obviously, it’s important to remember that these extensions are Android specific and won’t help you if you have a non-Android device, nor if your Android device doesn’t use Google’s MTP implementation (which, unfortunately, includes most Samsung devices). You can grab Ubuntu packages from my ppa and the source is available on my github page. [Less]

Hey, you, systemd hacker, Fedora hacker! Listen up! This Thu/Fri is the systemd Hackfest in Brno/Czech Rep, right before devconf.cz! On thursday we'll talk about (and hack on) all things systemd. And the hackfest friday is going to be a Fedora ... [More] Activity Day, so we'll have a focus on systemd integration into Fedora. You are invited! See you in Brno! [Less]