I'm the guy who wrote multitouchd and the xf86-input-evdev patch for
multitouch. So I can give you some explanations.
Basically, the xorg patch just transfers the different events coming
from the different points to different slave devices. By default, it
does not do anything and act as a normal evdev driver (it uses the
emulation given by the kernel).
Multitouchd is a tool that simplify the process to set up the device for
multitouch. It tells it to create one or more subdevices that will
handle the different touches.
Then, multitouchd set up the xserver by adding one master device per
subdevice. Finally it attaches each subdevice to one master pointer.
However, all the multitouch devices I know do not send their button
press/release. So the result will be just the motion of the different
pointers. That's why multitouchd uses Xtest to send the press/release
events, according to the valuator "Tracking ID".
As for the Apple Magic Mouse, I also own one. I tested it against the
patched evdev driver (in X), and I got into some troubles: I think this
is the first time (besides the wacom that are a little bit different)
that I get a device that reports both absolute and relative valuators in
the same report.
However, the X server is not aware of a per axis mode (absolute or
relative). So this can not work, unless we make a sided driver to split
the two modes, or unless we patch the xserver to handle it correctly. I
started doing that, the patch of the xserver, but I don't have much time
to work on it.
So the Magic Mouse is too far for being including as a multitouch device
and that's why the scrolling has to be inside the kernel for now (which
is a very bad idea I think).
Le 04/03/2010 16:31, Stéphane Chatty a écrit :
> Début du message réexpédié :
>> De : Chase Douglas <firstname.lastname@example.org>
>> Date : 4 mars 2010 15:35:46 HNEC
>> À : Stéphane Chatty <email@example.com>
>> Cc : "Luis R. Rodriguez" <firstname.lastname@example.org>, Greg KH <email@example.com>,
>> List Ubuntu Kernel Team <firstname.lastname@example.org>, Jiri Kosina
>> <email@example.com>, firstname.lastname@example.org, Thomas Winteler
>> Objet : Rép : Upcoming Kernel - MultiTouchScreen Support
>> I'd like to share a few points from my experiences. I have an Apple
>> Magic Mouse (the entire surface is a big multitouch panel), so I saw the
>> ENAC work and Jiri's magicmouse driver. I got Jiri's driver working by
>> patching the lucid kernel, but I wasn't able to get the ENAC multitouchd
>> software to compile (or really to figure out what it was intended to do,
>> there's no documentation in the tarball). The one thing I really am
>> interested in is scrolling through the magic mouse touch panel, but the
>> current X input implementation for scrolling leaves much to be desired
>> in the end result because there's no smooth scrolling.
>> I didn't bother bringing this up before now because I figured support
>> just wasn't there in user space to make the effort worth while in the
>> kernel for Lucid. However, as noted, it would make things easier if
>> ubuntu shipped with the hid driver compiled as a module instead of
>> statically in the kernel. This is not only the case for ENAC's
>> multitouch work, but also for the magicmouse driver Jiri wrote. Perhaps
>> we should consider changing this?
kernel-team mailing list