The MPX merge has been announced.
http://lists.freedesktop.org/archives/xorg/2008-May/035225.html

After over two years of development, MPX will be merged into master in the
week following the 25th of May.

Any comments - please put them forward NOW before it is too late!

Pushed a simple but quite important fix yesterday.

As you may know, cursors are rendered in HW these days. One benefit of this is that the cursor doesn't flicker when it is moved around. Another one is that the cursor is responsive even when the computer is under load. (This has to do with the server implementation, not with the hardware. HW cursors are updated during SIGIO handling, not during event processing, hence the responsiveness)

Unfortunately, current hardware can't render arbitrary numbers of cursors, and although anholt claims that he has ideas of how to render two cursors in HW, I understand we'll be stuck with SW rendering for a while (cursors, DRI works nonetheless). SW cursors are bad, since they can be laggy. I've been using it for a while at home, and it can be quite annoying.

The solution: MPX now switches between HW and SW rendering. As long as we have only a single cursor, we use HW rendering. When the second cursor is created, the server switches to SW cursors, and then back again to HW when only one cursor is left.

The side-effect: I could now drop MPX onto your machine and you wouldn't even notice that it's there until you start creating new devices. Yay.

Well, that's just one of the changes, but the most visible one.

In the past, the GIMP didn't work. Simply because the new device semantics state that if you grab an attached slave device, it will be detached and set to floating automatically until you ungrab again. Now, the GIMP always grabbed all extension devices, leaving you with nothing to actually control the cursor.

So, one of the changes I did over the last weekend was to get some versioning support into XI. The previous one was weak, as it didn't allow the client to tell the server what it supported. A new XQueryInputVersion() call in libXi can do that now, unless this call is issued we assume that the client supports XI v1.x.

For those clients that only support 1.x, we don't return the full device list but rather only the virtual core pointer, the virtual core keyboard and finally all floating extension devices. This essentially resembles a XI setup pre-MPX. As a result, the GIMP only tries to open extension devices that are already floating, leaving you with the ability to control your cursor normally.

This isn't a perfect solution, as some other semantics change too but it works alright so far.

Other than that, it was mainly cleanup. Including the transition of libXi to docbook xml based manpages, which should make it easier to actually write manpages now.

To update, pull inputproto, libXi and xserver.

Had some fun over the weekend. Turns out the wireless desktop I bought the other day is ... well, special. The evdev driver doesn't just register a mouse, the multimedia keys on the keyboard are registered as key class on the mouse. When you press any of them, the X server thinks the mouse just pressed a key.

Now as it happens, MPX wasn't really set up to cater with devices that are both mice and keyboards simultaneously. Even worse, the class copying MPX needs to do each time you change devices was quite expensive. So I've implemented some workarounds for all that and MPX now works smoothly and stable on my home machine.

I think it's getting close to being merge-able now, so please give the current version a good testing.

I sat down on the weekend to look at jhbuild and found it to be easier to build MPX from scratch. So, for first-timers:

Go to and read http://www.x.org/wiki/JhBuildInstructions
Then

git clone git://people.freedesktop.org/~whot/mpx.git

This small repository contains one jhbuildrc file. Get mpx by running

$> jhbuild -f mpx.jhbuildrc build xserver xf86-input-evdev xf86-video-ati

Add or substititute drivers as needed.

Alternatively, "jhbuild -f mpx.jhbuildrc build xorg" should pull down everything.

I am back from my holidays, currently trying to get through the stack of email. One thing I keep telling people over email repeatedly:

The blob-branch of MPX (think touchscreen) is currently orphaned. I just haven't found the time over the last months to keep it up-to-date with the other branch so I'm not sure if it builds and I'm pretty sure it doesn't work too well.

Bear with me, need to get the standard MPX sorted out first, touchscreen is easy then.

In between writing I found some time to clean out some things. Amongst the things I pushed in the last week or so:

A little overview of the important changes

• RawDeviceEvents removed
• GrabAccessControl removed
• FakeDeviceData removed
• input event list initialisation and storage moved from DDX to DIX (gets rid of the SIGIO allocs)
• ExtendedUngrabDevice ungrab handling removed (UngrabDevice does it anyway)
• GetPairedPointer removed
• master devices return the paired device's ID in attached field of ListInputDevices.

This results in a smaller set of requests to be added for MPX, and they are posted for public review.

The request removals require you to pull inputproto and libXi (and recompile all your apps too).

I'm back. LCA was great, except that I needed a lot of sleep when I came back...

I think I also pushed more patches to master during this week than I did in the weeks and months before that. Somehow I ended up caring too much about the server's input and I even started fixing drivers that nobody seems to use anymore.

Now it's down to crunchtime for me, entering the (hopefully) last weeks of my PhD candidature, writing up, trying to find a job (offers welcome) and getting my visa sorted out. But anyway.

Just yesterday or so I pushed Matthieu Herrb's patch to master that fixes some of the SIGIO problems we experienced during event generation. I got a couple of patches lined up to be applied to the MPX branch to get rid of alloc during SIGIO handling completelty. Unfortunately I'm debugging a rather nasty segfault somewhere in the abyss that is called XKB. Looks like a dangling pointer, but XKB ain't the easiest thing to debug.
Once I sorted this out, I can go on to fixing sane stuff.

Aside from that, the presentation went great and if you have approx 45 minutes you can watch the video of the talk.

Just pushed another set of changes, but now I'm off to LCA in Melbourne.

"Redefining Input in X". Thursday, 2:30pm

After my last blog post I got some worried emails about the following statement:

"The significant change with all this is that an event can only be sent to a single client."

This statement was ambiguous. Here's the correct version:

"The significant change with all this is that an event can only be sent in one form -- XI or core."

If two clients listen for a key press on the same window, both will receive the event. If however a client has registered for an XI event on the same window, only the XI event will be sent, not the core events.

Mixing core and XI events in the same app is simply not supported. It's an utter nightmare to do so and so far I haven't come up with a decent use-case that would justify all this extra work. This of course is valid for input events only, mixing XI and non-input core events (ConfigureNotify, Expose) is supported.

Thanks to those that sent me the emails, it's good to see someone is listening :)