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 :)

Some important changes pushed again. Let me explain (get yourself a beverage of your choice, this may take a while).

Historically, devices generate two input events: one core event, one XI event. The latter was ignored by pretty much everything but the GIMP, the former is basically what is used by every app out there. These two events came from two different devices, the core event always came from the core pointer, the XI event from the device directly.

With MPX, this doesn't work. XI is required to actually differ between devices, but core events are required as well if we want to actually use anything.

So one of the changes in MPX that was introduced many moons ago is that both core and XI events come from the same device. Likewise, if an app grabs the pointer, it would grab the device (search for ClientPointer in the archives), allowing for multiple pointer grabs on multiple device. But to ensure apps work correctly, only a single grab per device. Sounds good in theory, doesn't it?

Fast forward until last week. We* ran into the following problem: If an app would listen for DeviceButtonPress under a window manager that puts a passive core grab onto the button, the XI events never get through. Metacity with focus-follows mouse falls under that category. Turns out that the event freezing semantics caused the XI event to "disappear". So step one was to figure out WTF can be done.

Each device has an event queue for when event processing is frozen (during synchronous grabs). And with the code, the event that caused the freeze would be stored in the EQ. In our case, this was the core event. When that happend, the XI event was lost, and when the device was unfrozen, the XI event surprisingly did not arise like phoenix from the ashes but stayed lost. Probably in a pub, drinking beer, laughing at me.

After a bit of hacking, I changed the code that the XI event would get stored as well, after the core event. When the device is unfrozen, the server first resends the initial event (the core press, remember?) and then subsequent events. So my theory was that it would try to send the core event to the app, fail and then try the XI event and we can live happily ever after.

Wrong. Turns out metacity listens for button presses on the container window. And X traverses the window hierarch upwards for each event until it can be delivered. So the unfrozen core event actually got sent to metacity. This in turn caused an implicit passive grab to activate inside the X server (I think I wrote about that ages ago). And when it was time to process the XI event, the grab would discard the XI event. After all, metacity doesn't do XI.

The solution one was reasonably simple: fix up the passive grab event processing and frozen event queue to emulate core events on demand, but actually only ever deal with XI events. So even thought the core event is send to the client, we store the XI event in the device's EQ. And when thawing the device, the XI event is delivered first, and if not, a core event is generated and then sent.

Then we** found something else. If an app would listen for DeviceButtonPress and the window manager for ButtonPress on a parent window, trouble would pop in for a quick hello. The ButtonPress event, delivered to the WM would cause an implicit passive grab on the device. Then, the XI event would cause another implicit passive grab to activate. And it would overwrite the previous core implicit passive grab.

The result? Metacity never got a release event, so the window was following each and every mouse move. And while this behaviour is appropriate for, say, cat, a window manager has more important things to do. Like managing windows.

The solution to this is to support two grabs on a device. While at the same time only supporting a single grab on the device.

And up to now you thought you had it hard...

This is when I changed how input devices are perceived in the server. Instead of two separate events being processed, a single input event is pumped through two different APIs (core and XI). Sounds like esoterical BS but it helps to understand the whole problem better.

Each event can only be sent to a single application. First we try to send it as core, then as XI event. If an app receives either, processing stops. Otherwise, we try again on the parent window, until we reach the root window or time stops. Whichever is sooner.

The significant change with all this is that an event can only be sent to a single client. If the button press was sent to a core client, no XI client will receive the same press as an XI event. Which makes sense, as this means that an input event can only cause a single action, and not two actions in two different apps.

Ok. Not that exciting, I admit. But writing this gave me a perfect excuse to procrastinate from writing my thesis. After all, that's the main goal in life. Thank you for your attention.

*curtain falls. thunderous applause*

* by "we" I mean Baljinder, one of the lab's summer interns, who's writing a multi-device diagram editor.
* by "we" I mean my colleague Ben who's adopting FLTK to work with MPX.

Pushed a little fix to MPX yesterday that stops segfaults when a new output is enabled with xrandr.

Pushed another fix to master (has been in mpx for a while now) that stops the server to abort when a device has more than 6 axes. It is a bug in the server, with it the wiimote should work nicely now. Also mailed the cherry-pick request to daniels, so it might make it into 1.4.1.

Wiimote users: If you're not using git master, then disable some axes of the wiimote. Any configuration with more than 6 axes will bring down the server. This arguably does not improve the user experience.

Also fixed another issue with the wiimote that segfaulted the server when the bluetooth connection was cut with hcitool.

And all that gave me an excuse to hack instead of type. Life is ${FRUIT}y.

I finally managed to commit the merge from master I started just after christmas. A whopping 488 commits merge, 93000 line of diff, and a lot of conflicts.

Eamon Walsh merged his xace-selinux branch into master since I merged last and his work overlapped to some extent with what I did. Thanks to him, the devPrivates system is actually quite nice to use now.

I didn't fix everything yet, I got 13 immediate items on my TODO lists that are results from the merge. At least two memory leaks, but both gnome and MPWM worked (gnome-terminal crashed twice though). Will work towards fixing it.

My MPX commitment is unfortunately low, I get on average less than an hour/day to work on it and until I submit my thesis that's probably not going to change much. So if you want to help out, go for it. Pull and send me patches.

xf86-input-wiimote 0.0.1 is out. And it might just work on your machine (server 1.4 at minimum).

IR is supported now, nunchuk works too. The classic controller doesn't yet, I don't have one.
Tried it yesterday with two controllers under MPX and found the ability to juggle windows to be suffiently entertaining for 30 seconds.

Thanks to the X Input Extension specs I had to cheat a bit. Turns out that you can't have a device that reports both relative and absolute coordinates. So if you activate IR on the wiimote, you'll get two motion events - one containing just the two IR coordinates, one containing all axes (including IR). Also this means that IR - if enabled - must have the first two axes. All other axes can be mapped around though.

If you disable IR, x/y tilt will move the system cursor. Mostly useless, but fun.

Example section in your config.

Section "InputDevice"
        Identifier "wii"
        Driver "wiimote"
        Option "Device" "00:19:1D:12:34:56"
        Option "IR"     "yes" # default enabled
        Option "Accelerometer" "no" #default disabled
        Option "Tilt" "yes"
        Option "Nunchuk" "no" # default disabled

        # switch leds 2 and 3 on 
        Option "LED3" "yes"
        Option "LED2" "yes"
EndSection