http://lists.freedesktop.org/archives/xorg/2008-May/035641.html

For those of you watching xorg-commits, you may have noticed that MPX has been
merged into master [1].
The client-side libraries and protocol headers have been merged quietly last
week already, this time is just the xserver itself.

A change in the previously proposed schedule [2]: the XKB rework didn't make
it. With the recent SSL issue and other workloads, Daniel wasn't able to get
it ready in time. We agreed on merging MPX without it, as it should not affect
XKB much anyway.

A number of changes went in since the announce, the most important being the
return of input device cordinate scaling. Tablets can thus be used. Thanks to
Magnus Vigerloef for his help on this matter.

The input ABI has been bumped and all the input drivers on fdo have been
updated to compile with the new API. You will need to get the latest version
however. I don't think the ABI will remain stable until the next release, but
I figured input modules not loading encourages people to fetch the latest
release rather than complaining about them not compiling anymore.

The video ABI has not been bumped yet, but you _must recompile_ your video
driver. No API changes, a recompile is enough.

As previously mentioned, existing setups should not be affected and anything
that changes is most likely a bug. Unless you create additional cursors/foci,
in which case the border between bug and broken UI paradigm is somewhat
blurry.

For the impatient, run the following commands:
Update xorg/app/xinput to the most recent version.

xinput --list --short
xinput --create-master "foobar"
xinput --reattach "MyMouse" "foobar pointer"
xinput --reattach "MyKeyboard" "foobar keyboard"

It is at this point you have a second set of devices that work independently.
It is at this point that you may realise that neither GNOME, KDE, nor any
other environment actually works decently with multiple devices. So start
fixing them right now.

To go back to a standard setup:

xinput --reattach "MyMouse" "Virtual core pointer"
xinput --reattach "MyKeyboard" "Virtual core keyboard"
xinput --remove-master "foobar pointer"

Have fun. Input bugs that result from the MPX merge can be assigned to me.
So long, and thanks for all the mice.

Cheers,
Peter

[1] http://lists.freedesktop.org/archives/xorg-commit/2008-May/016662.html
[2] http://lists.freedesktop.org/archives/xorg/2008-May/035225.html

With the great help of Magnus Vigerlof, plenty of emails back and forth to understand it, and finally Pippa and Ben Avery who lent me their wacom tablet over the weekend I'm happy to announce that tablet support (i.e. scaling of input coordinates) is back. This was the last big chunk missing.

The coordinate handling to the client is:
rootx/y and eventx/y of a DeviceXXXEvent are now always in screen coordinates. This eases the development of XI clients that don't really care about device coordinates.

valuators0...32 are always in device coordinates, and the coordinates depend on the device mode. If the device is mode relative, the valuators are relative, if the device is mode absolute, the coordinates are absolute.

One thing that we need to think about is whether we introduce a ReportingMode in addition to the device mode. ATM, it is not possible to have a device report relative coordinates if it is in absolute mode.

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.

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

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.