Multitouch

Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2010-03-08 18:49:05
Size: 844
Editor: pool-74-107-129-37
Comment:
Revision 3 as of 2010-03-10 10:20:52
Size: 2055
Editor: pool-74-107-129-37
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
we'd like to ensure that Lucid works with the current generation
of touch screens.
We'd like to ensure that Lucid works with the current generation of touch screens.
Line 4: Line 3:
=== Typical Touchscreen Hardware ===
 * N-Trig (major supplier to Dell and HP for tablet PCs).
   * Dell Latitude XT2 (sabdfl)
   * Dell Studio 17
 * Quanta: in Acer displays and laptops, HPs, PackardBells, etc
 * MosArt: in Asus notebooks and a few others
 * NextWindow (note: no mt driver yet): HP tx1, some large displays
 * Wacom (note: the wacom driver has its own incompatible mt support): new HP mt2, some Fujitsu tablets
 * 3M: a 3M display
The intended stack would be (upside down):
Line 14: Line 5:
See http://lii-enac.fr/en/projects/shareit/multitouch-devices.html for
exact product references.
 * kernel driver (mine or others)
 * /dev/input/eventX
 * X.org evdev driver (the one [[http://lii-enac.fr/en/projects/shareit/xorg-howto.html|patched by Benjamin]], for instance)
 * X.org MPX/XInput2 API
 * multitouchd daemon
 * Qt or GTK+ or other
Line 17: Line 12:
=== Target Hardware === The current status of the above stack is "multi-pointer only", that is multi-touch without any gesture recognition. There have been debates as to where to put gesture recognition in the stack. Very few people have worked on multitouch gestures.

Multitouch in X is currently limited by the lack of multitouch events in the protocol. Benjamin's patch is a way around it to get multitouch-like features through a multipointer system. Upstream (Peter Hutterer) has indicated a preference to seeing this done via a single-pointer, because then clients would need to deal with a single touch event, instead of one event for each finger. But there are pros and cons to each approach and it's not clear there is yet a consensus about this. See discussion on xorg-devel@ for more background.

Benjamin's patch makes some simplifying assumptions that may not address the full spectrum of possible multi-touch use cases. For instance, multi-user collaboration using inputs from multiple hands going to multiple windows that support both multi-pointer and multi-touch awareness. It is likely some significant API redesign beyond Benjamin's proposed patch would be needed to address all possible cases. Thus, clients which implement support on top of Benjamin's patch would likely need reimplementation for what eventually is officially adopted by upstream.
Line 20: Line 20:
 * [Rami] What set of devices should be targeted to cover for this blueprint?
 * [Rafi] Are Rafi's kernel patches dependent on changes from .32 to .33?
 * (DONE) Obtain an -evdev patch against upstream git: http://people.canonical.com/~bryce/evdev-multitouch.patch
 * Backport the multitouch patch to Lucid's -evdev, and post to a PPA
 * Decide whether the evdev multitouch patch is acceptable for including in Lucid, and if so upload it

We'd like to ensure that Lucid works with the current generation of touch screens.

The intended stack would be (upside down):

  • kernel driver (mine or others)
  • /dev/input/eventX
  • X.org evdev driver (the one patched by Benjamin, for instance)

  • X.org MPX/XInput2 API
  • multitouchd daemon
  • Qt or GTK+ or other

The current status of the above stack is "multi-pointer only", that is multi-touch without any gesture recognition. There have been debates as to where to put gesture recognition in the stack. Very few people have worked on multitouch gestures.

Multitouch in X is currently limited by the lack of multitouch events in the protocol. Benjamin's patch is a way around it to get multitouch-like features through a multipointer system. Upstream (Peter Hutterer) has indicated a preference to seeing this done via a single-pointer, because then clients would need to deal with a single touch event, instead of one event for each finger. But there are pros and cons to each approach and it's not clear there is yet a consensus about this. See discussion on xorg-devel@ for more background.

Benjamin's patch makes some simplifying assumptions that may not address the full spectrum of possible multi-touch use cases. For instance, multi-user collaboration using inputs from multiple hands going to multiple windows that support both multi-pointer and multi-touch awareness. It is likely some significant API redesign beyond Benjamin's proposed patch would be needed to address all possible cases. Thus, clients which implement support on top of Benjamin's patch would likely need reimplementation for what eventually is officially adopted by upstream.

Tasks

X/Blueprints/Multitouch (last edited 2010-03-22 23:54:32 by SEASNet-62-02)