From: Bryce Harrington <bryce@xxxxxxxxxxxxx>
Date: March 13, 2010 3:08:07 PM MST
To: Rafi Rubin <rafi@xxxxxxxxxxxxxx>
Cc: Rick Spencer <rick.spencer@xxxxxxxxxxxxx>, Robbie Williamson <robbie.williamson@xxxxxxxxxxxxx
>, Mark Shuttleworth <mark@xxxxxxxxxx>, Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx
>, Christian Reis <kiko@xxxxxxxxxxxxx>, Pete Graner <pgraner@xxxxxxxxxxxxx
>, St?phane Chatty <chatty@xxxxxxx>, Hugh Blemings
<hugh@xxxxxxxxxxxxx>, Scott James Remnant <scott.james.remnant@xxxxxxxxxxxxx
>
Subject: Re: Touch and Multi-touch with N-Trig and others, for 10.04
Adding Duncan to the CC. He's the project manager for this project
and
will be tracking the work.
Duncan, Rafi has identified a lot of tasks, I'm going to pepper this
email with action items can you gather them up to an appropriate place
and ensure they get assigned/scheduled/prioritized?
The CC list is getting unweildy, and different threads have different
people listed. I imagine some people aren't getting emails they
should,
and others are getting more than they need. I suggest moving this
to a
mailing list.
* Identify official mailing list for the multitouch effort
On Sat, Mar 13, 2010 at 01:02:16AM -0500, Rafi Rubin wrote:
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.
* Redo (or update) the -evdev multitouch backport patch, using this
git tree
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'm assuming the time frame > 1 month, so for lucid this is orthogonal
to what we're going to do.
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.
* Need a QA test plan for verifying non-MT input devices are ok
* Need a QA test plan for verifying MT input device functionality
Duncan, the above two plans will need to be written up in some detail,
maybe you and Brian can put your heads together? I started a test
plan
some time ago but it's unfinished:
https://wiki.ubuntu.com/X/Testing/Touchscreen
Can you and Brian please expand that test plan especially with steps
to
do for each gesture we expect to have supported?
Use the 'proprietary driver testcase' as a good model for the level of
detail we need:
https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers
http://testcases.qa.ubuntu.com/Hardware/X/ProprietaryDrivers
Oh also:
* Identify data and files (dmesg, etc.) needed for MT debugging
* Ensure apport scripts (kernel and xorg) capture needed MT debug data
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.
* Need to ensure test plan covers above described situation
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.
Well, I'm concerned about how short of time we have on all of this.
If
we can make multitouchd functional *now*, then it will enable other
people to move forward with testing and so on in parallel with the
development work.
Also, I'm thinking that if multitouchd is buggy, well it's going to be
easy enough to shut off or uninstall. But if we are carrying the
functionality in -evdev itself, if *it* is buggy it's not so easy to
shut off - the user would have to find and install an older -evdev.
So while I agree adding this stuff to -evdev makes sense
developmentally, it greatly increases the level of risk we deal with.
So Duncan, I think this is an area where you need to make a call which
direction we take - either shim up multitouchd and finish the
packaging
work around it, or stoke the fires for getting -evdev development
going
further. (I don't have a strong opinion one way or the other, but
we're
short on time and need a solid plan of attack so we don't waste
effort).
And then we need the tasks outlined for whichever path we take.
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.
* Need to document xinput use for multitouch enablement
* Need to craft udev hook and rules for enabling multitouch
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 the rest 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.
* Need to review -wacom's mt code
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.
From what you've described, it sort of sounds like -wacom is the lower
hanging fruit. It sounds like it would give us a wider range of
functionality and has been more heavily tested.
Duncan - I think you need to help guide us with some strategy here,
whether we're aiming to: A. Push -evdev development with multitouch,
or
B. Deliver maximum functionality for tablets. If our objective looks
more like B, then maybe we need to consider focusing efforts on -
wacom.
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.
* Examine status of gesture support in -wacom
-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.
Well, presumably some people are finding it has worked for their
hardware (we've got a fair number of bug reports on it). But I agree
it's not worth putting any further effort into ourselves.
I think once we're certain that -evdev (or -wacom) supports all the
hardware that -evtouch did, we can drop it.
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
Bryce
