I put the blob (multi-touch) stuff online. If you're insane enough, you can build it yourself.

It lies on the "blob" branch on:
git://people.freedesktop.org/~whot/xserver.git
git://people.freedesktop.org/~whot/libXi.git
git://people.freedesktop.org/~whot/inputproto.git

An example driver is on
git://people.freedesktop.org/~whot/xf6-input-blob.git

All available via fdo gitweb too.

The driver listens to events on the network. Which means you can hook up an external machine that does the tracking for you, or a simple test program (see xf86-input-blob/test/). Nothing special, but enough to test the events.

I need to go back to Austria on very short notice. I'm flying out tomorrow and won't be able to do much coding for at least two weeks. I spent a lot of time this weekend to get things ready, but didn't get everything done I wanted to do. So I'm just dumping what I have now online. This gives you a chance to have a think about it and tell me if I've forgotten something crucial.

XBlobEvents

XBlobEvents are the new type of events.

typeef struct {
    int           type;         /* GenericEvent */
    unsigned long serial;       /* # of last request processed by server */
    Bool          send_event;   /* true if this came from a SendEvent request */
    Display       *display;     /* Display the event was read from */
    int           extension;    /* XI extension offset */
    int           evtype;       /* XI_BlobEvent */
    XID           deviceid;
    Time          time;
    Window        root;
    Window        event;
    int           hot_x;
    int           hot_y;
    int           hot_x_root;
    int           hot_y_root;
    int           bb_x1;
    int           bb_y1;
    int           bb_x2;
    int           bb_y2;
    int           bb_x1_root;
    int           bb_y1_root;
    int           bb_x2_root;
    int           bb_y2_root;
    XBlobEventLongData* ldata;
} XBlobEvent;

typedef struct {
    XID           subdevice;
    XID           blobid;
    int           format;
    int           bits_per_pixel;
    char*         data;
} XBlobEventLongData;

(Xlib internals are the reason that the event is split up into two parts).

The important fields are:
blobid ... blob id. (see below)
hot_* ... hotspot coordinates. These coordinates are used for mouse emulation.
bb_* ... bounding box coordinates.
format ... BlobFormatMonochrome, BlobFormatRGB, BlobFormatRGBA
subdevice ... subdevice of the blob (see below).
data ... the actual data the touchscreen can provide.

The blobid needs to be assigned by the driver. As a blob appears on the touch table, the driver assigns it a 30 bit id. When the blob moves, the id stays the same, but is flagged with BlobContinue. The client can thus keep track of multiple blobs simultaneously, and link them to gestures. Once a blob disappears, the id has to be flagged with BlobStop. The client knows that the blob disappeared. From this point on, you can re-use the blob-id.
The BlobContinue and BlobStop flags are crucial! Without them a client will think each blob sent by the device is a new touch. And it will likely lock up mouse emulation, as you're effectively sending lots of button presses, but no releases.

Hotspot and bounding box should be self-explanatory. Subdevice may need more explanation. Right now, none of my tests use it, but it is passed to the client as detected by the device. So eventually we'll have a set of flags in the form of SubdevRH_Index, for index finger right hand. If your device is good enough, you can supply the client with a lot of information here.
If not, SubdevUnknown will do. These defines don't exist yet, I need to think about a reasonable naming scheme.

The actual data should be a bitmap as good as the device supports it. So if you have a video-based FTIR table or an iPhone, you could send BlobFormatMonochrome and send the outline of the finger.If you have a MS surface table, you can send full RGBA data. The client could then even do fingerprint detection.

All the smart things will still have to be done by the client. MPX just provides the layers to abstract the device-dependent stuff away.

A very simple example client can be viewed here . This should give you a clue how to use them.

(btw. there is a bug in the server that causes stack corruption. I spent 6 hours debugging it today and came to the conclusion that it's probably not my fault. I think it's in pixman. If you find it, I'd appreciate if you tell me)