If you are interested in MPX and want to shape what's coming read this:
http://lists.freedesktop.org/archives/xorg/2007-September/028322.html

If you have/need a special setup that would not work with this proposal, speak up now!
I won't be able to start implementing for a while anyway, so now is the ideal time to sort out the specs.

XDS 2007 is over. And it was great, X hackers are a cool bunch.

I gave a talk about MPX (including demo, woohey!) which was very well recieved. And there is a preliminary timeframe: XGE should be in the next release, MPX in the one after that. So about 12 months from now if I'm correct. Let's see how that goes.

Keithp pointed out some semantic issues that need to be fixed before that, which right now means we need to introduce a device hierarchy. I'll keep you posted once I got it solved.

I did get to do some hacking, the event list for frozen events should work with Generic Events now, which might fix the sync bug I experienced before I left. But since my testbox is on the other side of the planet right now, these patches are untested and won't be up until the 26th.

That's it for now, I need to get some sleep.

The bug is now officially "Not My Problem".

I use two different config files for testing master and mpx, and mpx had depth 16, master 24. And as it happens, the segfault only happens at 16. So switching mpx to 24 "fixed" it. And switching master to depth 16 shows it also happens in master. Good thing, considering it happens in some code I never touched, and I don't even know what the code does.

Gotta file a bugreport tomorrow, but for now it's going home time.

After long hours of git-bisecting, I finally found the commit. Not the bug yet, unfortunately.

I can so far only reproduce it by starting windowmaker and then xeyes or gnome-calculator. Some other apps, inlcuding xterm, gnome-terminal or even firefox don't trigger it.

Tracked it down to [0] (Mar 8), but most likely it wasn't visible until [1] (Mar 27), when Composite was enabled by default.

Anyway, if you check out [0], cherry-pick [1] and [2] and then link in efence, you get a SIGSEGV in fb24_32BltDown(), fb24_32.c:123.

0xb60c35f0 in fb24_32BltDown (
    srcLine=0xa6dc8aa4 "[shortened]"..., srcStride=608, srcX=1, 
    dstLine=0xa6e06000 "", dstStride=300, dstX=0, width=150, 
    height=0, alu=3, pm=4294967295) at fb24_32.c:123
123                     WRITE((CARD32 *)dst, (s0 & 0xffffff) | (s1 << 24));

This isn't my code, but since the whole problem doesn't happen in master, I must be corrupting memory somewhere, somehow.

But anyway, when I tried resetting to a version before that (after git-bisect reset), it keeps crashing there too. I could swear this bug is running around...

Joy. Joy. Joy.

[0] ceca5670fee99b5feceaa2453f1ac32d1bfe7dcd
[1] 1af2ef0b25fd8017a3271e624a5f1548f02b09f9
[2] 72b243caead62d2ee5a073f4d9b03fcc92da937d

git bisect sucks when you got a large range to bisect and a recompilation takes 20 minutes.

Some touch-tables can recognise objects. Some can do it on arbitrary objects through optical recognition (e.g. MS Surface). Others can do detection of a set of objects, but can do it in the device directly (e.g. through RFID). Now this is fundamentally different. The first method is recognition, the second method is detection of already known objects.

Let's ignore the first case, as this generally isn't done in the device, but rather in the client. The second is more interesting, as all the detection is done in the device, the client just gets the information. Two examples: metaDESK and reactable.

So I sat down and started thinking about how these objects could be supported.

And after some heated discussions with my lab mates, I found everything is already there, as part of XInput.

Let's summarise the common properties of such an object:

• known to the system and thus can be given a name
• unique
• position information in 2D (or optionally 3D)
• rotation information optionally

That's pretty much it. It is simply something we know of, that exists in space. So how can you get this into the system?

Simple - create a new device. Does your detection system support 3D position? Give it three valuators. Does it support 3D rotational information? Give it another three valuators. All done. You now have a device that gives your client 6DOF.
Now the only thing you need is to be able to mark the device as a Named Object. The result of today's main coding session:

diff --git a/XI.h b/XI.h
index 05eb2b4..689e0a8 100644
--- a/XI.h
+++ b/XI.h
@@ -152,6 +152,7 @@ SOFTWARE.
 #define XI_EYETRACKER  "EYETRACKER"
 #define XI_CURSORKEYS  "CURSORKEYS"
 #define XI_FOOTMOUSE   "FOOTMOUSE"
+#define XI_NOBJECT     "NAMED OBJECT"
 
 #define Dont_Check                     0
 #define XInput_Initial_Release         1

How to use this? (client side)

We have hotplugging now, so create the device as it appears, and remove it as it disappears again. Or create it once, and just send events when it actually does change it's position.

The client will see that there is a device, and if it checks for the type (which it should), it will see that it's a Named Object, and can thus behave like whatever you need it to do.

And if you don't set it up to send core events, it won't even interfere with your apps on the screen.

ahh, it feels good when one line of code fixes the problem.

I got the ok from MERL to put the X driver for the DiamondTouch table online.

Download

Git repository: git://people.freedesktop.org/~whot/xf86-input-diamondtouch
Latest releases: http://people.freedesktop.org/~whot/diamondtouch/

The second folder also contains the kernel driver for the DiamondTouch. The kernel driver was written by MERL and is released under the GPL.

The X driver is released under the X11 license.

BlobSupport

Unless you're running the experimental blob branch, you might want to disable blob support (highly recommended).
Mind you, this way the DT is basically a very big mouse.

user@host:~/xf86-input-diamondtouch $> ./configure --disable-blobs

Features

from the diamondtouch.c.

 * Touch is interpreted as button press, moves as drag motions. If no value
 * above the given threshold is found, a release event is sent.
 *
 *   - supports hotplugging. 
 *   - allows configurable hotspot search functions.
 *   - signal threshold configurable per user.
 *   - blob delivery 
 *
 * TODO:
 *   - only works for single screen
 *   - device-to-screen coordinate mapping is crude (_dt_scale_to_screen)
 *   - the signal isn't reported as valuator yet.
 *

Configuring multiple X devices for the same device file (e.g. /dev/DiamondTouch) will result in a device per DT pad. Read the man page for more details.

This is the driver I used for the multitouch demo video.

I just pushed the change to allow flexible devices for passive core grabs. Problem: when a client requests a passive grab to be put on a key/button, it doesn't specify the device (for core grabs only, that is).
What MPX did before was create the grab with the ClientPointer, and then go from there. This is ok, but makes the desktop virtually unusable unless you have MPX-aware window manager that obediently sets the ClientPointer all the time. In short, it sucks.

This latest push simply means that when a passive grab is activated, the device is swapped to the one that caused the grab to activate. The grab then stays active on this device, even when the client then explicitly gets an active grab. So in short, the passive grabs pick their device on demand, and release it later.

Since a core grab has to imply exclusive client access for the duration of the grab, this is much better solution than before.

In terms of interaction: no matter what the ClientPointer setting is, if you click on a menu, the pointer that clicked will get the grab and can use the menu. Whoopee. Something that seems obvious, but I only thought of it two days ago. Well.

This has implications for MPX-aware apps too. A passive device grab allows you to explicitly specify the modifier device (keyboard). MPX doesn't override this. So you may have to re-create all passive device grabs each time the pairing changes. Oh well. Tough luck.

I've started listing differences between X and MPX on the X.org wiki. Over time, this should explain what really changed.

http://wiki.x.org/wiki/Development/Documentation/MPX. This will only be useful if you know X programming.

I also started to write man pages for the new calls I added. Might be useful too.

I got a few emails from various people who battled with the MPX compilation process. Thanks for all your feedback.

• The download page lists now both git 1.4 and git 1.5.
• Thanks to patches initiated by packz (at) autistici.org the MPWM now compiles again (no XID->char conversion issues) and uses autoconf instead of a manual makefile.

I think I've answered all emails now, if you didn't get a reply, your email was either lost in my spam folder or my answer was lost in yours. Please try sending it again.

[edit]
Ah yeah, and I updated the X.org git_xorg.sh script to pull the pixman libraries from the correct path.

[edit2]
If you're building X, skip all input drivers except mouse, evdev and keyobard. Some of them won't build (not my fault though :)