Thursday, March 26, 2009

Goodbye VCP/VCK?


:: whot@dingo:~/xorg/app/xinput/src> ./xinput --list --short
Default device id=2 [master device]
↳ Power Button (FF) id=3 [slave device (2)]
↳ Video Bus id=4 [slave device (2)]
↳ Sleep Button (CM) id=5 [slave device (2)]
↳ Video Bus id=6 [slave device (2)]
↳ Microsoft Microsoft? Digital Media Keyboard id=7 [slave device (2)]
↳ Microsoft Microsoft? Digital Media Keyboard id=8 [slave device (2)]
↳ ThinkPad Extra Buttons id=9 [slave device (2)]
↳ Macintosh mouse button emulation id=11 [slave device (2)]
↳ Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) id=13 [slave device (2)]
↳ SynPS/2 Synaptics TouchPad id=14 [slave device (2)]
foobar id=15 [master device]
↳ AT Translated Set 2 keyboard id=10 [slave device (15)]
↳ TPPS/2 IBM TrackPoint id=12 [slave device (15)]


So what does this mean?

xinput --list simply lists all the devices connected to the server. In current servers, these were the "Virtual Core Pointer", the "Virtual Core Keyboard" and a bunch of physical devices.

I simply got rid of the distinction between pointers and keyboards, because too many devices are both anyway. The distinction doesn't really make sense. Even worse, with MPX's event routing through the respective master devices it became a bit of a nightmare to do key events correctly. I'll spare you the details.

So anyway. The idea is to merge master pointers and master keyboards into a single master device. This device is both, thus all events from any attached slave device goes through this single master. Nice and clean, and once we need more capabilities (*cough*multitouch*cough*) we can easily tack it onto the MD.

Now, we do have the notion of pointer and keyboards in the core protocol and to break the core protocol requires a presidential pardon that I have yet to obtain. One of the tougher things here are core grabs. With a single master device, all we need to support is an async pointer grab that is overridden by a passive sync keyboard grab (affecting the same device, but other events) that may or may not get modified by an active pointer grab. So while freezing the device for keyboard events you may need to replay pointer events on the device that is frozen, if this device isn't still frozen for pointer events by some other grab. Surprisingly, there's nothing in the Genevan Convetion about this.

Anyhow. AFAICT, this works now, with core grabs passing the X Test Suite and I'm happily running my standard Fedora desktop without noticing anything different.

Some of the remaining issues:
- god, this code is ugly.
- lazy transfer of classes to the MD.
- handling of the focus if the MD loses the key class.
- there is not enough beer in the fridge.
- testing this through the XI2 API to make sure it isn't completely insane.
- spec out XI2 grabs.
- misc. details that will make me regret this attempt.

Oh, as a side-effect this also enables merged modifiers, i.e. pressing shift on one keyboard types capitals on another one (if both are attached to the same master).

[edit: this whole experiment is not upstream, not even on my people.freedesktop until I cleaned it up]

Monday, March 23, 2009

XI2 implementation, take 1

This weekend, I announced the first implementation of XI2 on the xorg-devel list.

You can get the repositories from

git://people.freedesktop.org/~whot/xserver.git
git://people.freedesktop.org/~whot/inputproto.git
git://people.freedesktop.org/~whot/libXi.git
git://people.freedesktop.org/~whot/xinput.git

Check out the xi2 branch on all four repositories.

XI2 is important for two reasons. One, it's the client-side API that enables applications to make use of MPX. For obvious reasons, I have some interest in getting this done.
The other part of XI2 (and why it is called XI2) is that it's a new version of the X Input Extension. One of the goals here is a cleaned up API that is less painful to use than the first, current, version.

Aside from some API cleanup, the new additions are subpixel precision in events, the ability to support devices that change capabilities at runtime and relative device events. And of course all the stuff required to access MPX' functionality.

So, if you're adventurous*, grab the repositories, compile them up and test them. You can write little test apps to play around with the new stuff, and if you find any problems or inconsistencies, please report them back. I'm trying really hard to get this right.
Note that because this is the first version, API changes are to be expected and there will be the odd bug in there.

* One of the main goals of MPX (and XI2) is that it must be invisible until used. So you can grab the repositories and run your everyday desktop off it and there should be no difference.