Ubuntu Wiki

Initial Analysis

Email below from Rafi details Rafi's initial impressions of the work involved.

----- Forwarded message from Rafi Rubin <rafi@seas.upenn.edu> -----

Date: Sat, 13 Mar 2010 01:02:16 -0500
From: Rafi Rubin <rafi@seas.upenn.edu>
To: Bryce Harrington <bryce@canonical.com>
CC: Rick Spencer <rick.spencer@canonical.com>,
        Robbie Williamson <robbie.williamson@canonical.com>,
        Mark Shuttleworth <mark@ubuntu.com>,
        Christian Reis <kiko@canonical.com>,
        Pete Graner <pgraner@canonical.com>,
        St?phane Chatty <chatty@enac.fr>,
        Hugh Blemings <hugh@canonical.com>,
        Scott James Remnant <scott.james.remnant@canonical.com>
Subject: Re: Touch and Multi-touch with N-Trig and others, for 10.04

On 03/12/2010 09:59 PM, Bryce Harrington wrote:
> Hi Rafi,
> 
> I've packaged the multitouchd and the -evdev patch, and established a
> PPA for testing of it:
> 
>    https://edge.launchpad.net/~xorg-edgers/+archive/multitouch/
> 
> This is still preliminary.  The multitouchd gets installed ok but I
> still need to do the packaging goo to make the daemon start up.  We will
> also be adding a kernel in there, so that's also pending.  If you notice
> anything out of place please let me know.

Ok, packaging them is a good start, but don't expect either evdev or
multitouchd to be in good shape yet.

I found a flaw in version of evdev from Stephane's website and
contacted Benjamin Tissoires, who wrote the mt mods.  There is a newer
version at
http://gitorious.org/lanedo/xf86-input-evdev
which I've been using today.  So far so good.

Benjamin is working on moving his mods to the upstream at freedesktop,
but has no time frame for when mt will be part of the standard evdev.


I've been reading pieces of the code, and so far it looks like the
execution for non-multitouch devices should not be affected, aside
from the conditions that check for multitouch.  So hopefully that will
approach the goal of not breaking things that work.

For multitouch, the old version broke the single touch events sent by
the multitouch device.  I still need to compare the code to see what
else was changed in addition to that particular bug fix.


As for multitouchd, its not actually functional.  Also it actually
doesn't seem particularly important.  The button events could easily
be handled by the -evdev driver.  Most of the other more tangible
functions could also be moved or dropped for now (we don't actually
need to show the cursor sprites for touch anyway).

In its current state it can't be used at all (actually crashes X for
me on the second invocation).  I've narrowed down the crashing bug to
either an out of bounds or uninitialized pointer write, and will work
them out when I have some spare time to work on it.

If we put the TOUCH pressed/released events in -evdev, I suspect we'll
be better off without the daemon for now.  Don't spend too much time
on it until we at least get it working and see if it actually improves
the user experience.


Summary of the current level of functionality:
Pen + single touch fully functional

Multitouch has to be turned on by setting a property with
        xinput set-prop '"N-Trig MultiTouch"' "Evdev MultiTouch" 4
And then I get four input devices that do actually track my fingers.
But with no "pressed" events applications don't really do anything
useful.

> If this is referring to the xf86-input-wacom_ntrig_2010_02_03.patch
> patch, I've uploaded this to -wacom in lucid this week.  It looked
> easy.  So if I understand now, this enables N-Trig hardware to be
> used with the -wacom driver in a tablet/stylus/eraser configuration, as
> well as using touch via `xsetwacom set touch touch on` and the like?
> Will it do multitouch?

Wacom is now manufacturing multitouch devices and I've seen
discussions of it on the linuxwacom mailing list (casually glance at
it occasionally).  But I don't know if they've moved past basic
gestures to actually presenting multiple positions.  From what I've
heard, there are some differences in the way wacom mt works, and I
don't know how compatible the driver will be with other vendors
hardware and the other kernel drivers.  Most of therest of the mt
drivers in the kernel are aiming for a single protocol.  I really need
to take a look at the mt portion of the code, its all new since the
last time I actually read through to see how it works.

> Does the N-Trig hardware do stylus/eraser in addition to multitouch?
> If so, will the mt-patched -evdev support this along with multitouch, or
> would -wacom need to be used in this case?

Short answer: yes, and both evdev and wacom work (or can trivially be
made to work with the pen).

The pen (stylus/eraser) looks like a separate sensor (though I don't
know for sure).  Very standard events, and the -wacom driver works
really nicely with it.  The sensors emit through different dev nodes
(finally) and so the choice of drivers are completely independent.


Wacom offers position denoising and nicer button mapping (previously
mentioned, I remap eraser clicks to "ctrl-u" on the fly for certain
applications).  Also I have not made rotation work with -evdev, yet
(shouldn't take much time).

I don't remember off the top of my head how noise the two sensors are
on the n-trig (I'll add drawing sample lines to my todo list).

At the moment, almost everyone I've heard from is using -wacom.  The
multi-touch and general long term planing has been driving me to take
more interest in -evdev.

While most my drivers in the kernel are written to conform to a single
protocol, I think there some issue with wacom being different (and if
that N-Trig fellow gets his way, they will also diverge) and the X
driver working somewhat differently.  Last I looked they were just
starting to look at rudimentary gestures, and not actually presenting
multiple positions.  That was some time ago, I will have to take
another look.

>>> -evtouch and -wacom provide more advanced feature support than -evdev,
>>> and do a lot more on the X side but they only support a subset of
>>> available devices.  I'm not certain that -wacom provides "touch", it may
>>> be specifically focused on pen-based devices.  -evtouch seems to be
>>> weakly supported upstream, perhaps it will eventually go away and be
>>> subsumed into the other two drivers?
>> 
>> -evtouch sort of worked for me when I tried it, but as you say it
>> was poorly supported and didn't look like it was going anywhere.  I
>> wouldn't suggest spending much effort on it.
> 
> I noticed -evtouch wasn't even building in lucid anymore!  In looking
> into it, the issue was already fixed in Debian, so we just need to sync
> the package from them.  It looks like all the changes we had in ubuntu
> are no longer relevant (old HAL config files and such) so can be
> dropped.  But other than that, yeah no plans to spend effort on it.
> 
> Ultimately, maybe as soon as Lucid+1, I'd like to see -evtouch get
> completely deprecated in favor of -evdev and/or -wacom.

Just grabbed the tarball.  Newest files from the latest release are
from 2008.  I think it was abandoned in favor of evdev touch support
long ago.  If it the debian patches make it compile, I'd be willing to
try it out one last time to see if it has any redeeming features to
justify including it at all with lucid.  But I'd argue in favor of
dropping it soon, since its already a long dead project.

> I understand that -evtouch is basically like -evdev but with touch
> events.  Does it use the same kernel bits as -evdev under the hood?
> Is there really much that it can do that -evdev can't these days?

There isn't a lot that goes into the touch support of evdev.  I should
be able to compare the source pretty quickly.  Touch really isn't that
complex: x,y, touching/not touching.  Sure there's a little more
handling, such as the axis transformations (scale/shift/rotate), but
its pretty simple code.

Rafi

----- End forwarded message -----