Email below from Rafi details Rafi's initial impressions of the work involved.
----- Forwarded message from Rafi Rubin <firstname.lastname@example.org> ----- Date: Sat, 13 Mar 2010 01:02:16 -0500 From: Rafi Rubin <email@example.com> To: Bryce Harrington <firstname.lastname@example.org> CC: Rick Spencer <email@example.com>, Robbie Williamson <firstname.lastname@example.org>, Mark Shuttleworth <email@example.com>, Christian Reis <firstname.lastname@example.org>, Pete Graner <email@example.com>, St?phane Chatty <firstname.lastname@example.org>, Hugh Blemings <email@example.com>, Scott James Remnant <firstname.lastname@example.org> 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 -----