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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
