multi-touch-dev team mailing list archive

[Henrik Rydberg <rydberg@xxxxxxxxxxx>]

Hi Martin,


> The changes I made in the Xorg evdev driver mainly follow along the line that 
> Stephane and his team already did (I even copied parts of their code). 
> Because I had a special target device in mind that also runs "legacy" X 
> applications (i.e. w/o multitouch support of any kind), I also cared about 
> not breaking things with these apps, ending up in only sending button events
> for the primary finger on the screen as well as always sending the
> coordinates of the primary finger in the "non-MT" Abs fields.


This is actually standard procedure in the kernel, although there were problems
initially with the 72a1 device.

> I also added a little convenience in the kernel's input.h which basically is a 
> bitfield that keeps track of the fingers on the screen by setting the bits of 
> the corresponding tracking IDs to 1 during touchdown. This is exported as 
> just another button in the event device. As I avoided button events for all 
> non-primary fingers, this bitfield makes it easy to keep track 
> of "non-primary" touches and releases and also comes in handy when doing 
> event compression (see the Qt patches for that).


I see. Nowadays, with mtdev and full kernel support for the 72a1, you should be
able to do well without the bitfield, I take it?

> It turns out that 
> multitouch-aware Qt applications work like a charm and even the legacy 
> applications do (no jumping or locking "mouse-pointer" when (accidentally) 
> hitting the screen with the second finger).

>

> Another useful thing when using the actual Xorg driver to relay the multitouch 
> events (instead of directly working on /dev/input/eventXX from within the 
> application layer) is the fact that software can very easily be tested on the 
> actual multitouch device (in our case a slate) without even compiling on the 
> device, just forward the X screen to the target device. With that you can do 
> funny things like running the test application on your (fast-compiling) 
> 64-bit workstation while having the output and the input on your 32-bit 
> slate.

> 
> Anyway, here is a URL to the patches as well as a small description:
> http://www.digitalmedics.de/projects/wetab
> Note that these patches currently only work for a certain (hid-egalax.c) 
> device, as they were targeted at a special hardware platform. However, the 
> code is written in a quite general way, so that adaptions to other hardware 
> should be easy, in fact it suffices to work on the kernel HID layer.
> As the manufacturer of the slate device is already in the process of 
> incorporating these patches into their system, I will take down the page in a 
> couple of weeks. I felt that before I take it down, maybe those patches are 
> of use to someone else, if not I apologize for wasting your time :)


Thanks for sharing!

Henrik