[PATCH inputproto] Add touch classes and events, bump to 2.1
peter.hutterer at who-t.net
Wed Jan 19 13:52:54 PST 2011
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.
More information about the xorg-devel