[PATCH inputproto] Add touch classes and events, bump to 2.1

[Peter Hutterer]

On Fri, Jan 07, 2011 at 04:02:09PM +0000, Daniel Stone wrote:
> > > +∙  Driver DRV provides touch support from tracked device D:
> > > +    ⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for
> > > +      each axis available on the device.
> > > +    ⊳ DRV parses D's device protocol and selects one touch sequence to be
> > > +      emulated as pointer event.
> > > +    ⊳ DRV calls the respective input driver API with the touch sequence
> > > +      data. The touch sequence emulating a pointer has the respective flag
> > > +      set. DRV does not submit pointer data for any touchpoint.
> > 
> > I was under the impression that the driver would be handling pointer
> > events and touch events separately. This wording sounds like the server
> > handles pointer emulation internally based on touch data.
> > 
> > The current MT code in evdev has separate processing, so which way are
> > we going with this?
> 
> Honestly? I don't know.  I'd be inclined to say that it'd be more robust
> to do it in the server, so we can get a better association between the
> touch and related pointer events, but certainly the trend in the kernel
> has been to post ABS_[XY] events as well as the MT events, so I'm not
> really sure.

do pointer emulation for touch events in the server. be that through calling
GPE from GetTouchEvents or other means.

kernel-specifics such as ABS_X being posted in parallel with
ABS_MT_POSITION_X should be filtered in the driver.

Cheers,
  Peter