[RFC] Multi-Touch (MT) support - arbitration or not

Dmitry Torokhov dmitry.torokhov at gmail.com
Thu Nov 11 11:55:40 PST 2010


On Thu, Nov 11, 2010 at 08:41:25PM +0100, Henrik Rydberg wrote:
> >>
> 
> >> But, I think ABS_X/Y arbitration should be considered in the kernel to
> >> reduce the overhead in userland.
> > 
> > With option 1 you have natural ST arbitration - the first touch gets to
> > report (ABS_X, ABS_Y), the rest will have to report ABS_MT_* till the
> > first touch is lifted, right?
> 
> 
> Right. Perhaps this is a good time to discuss some additional helper functions
> Chris and myself are playing with right now.
> 
> /**
>  * input_mt_report_state() - report contact state
>  * @dev: input device with allocated MT slots
>  * @active: true if contact is active, false otherwise
>  *
>  * Reports an active touch via ABS_MT_TRACKING_ID. If active is
>  * true and the slot is currently inactive, a new tracking id is
>  * assigned to the slot.
>  */
> void input_mt_report_state(struct input_dev *dev, bool active);
> 
> Since all tracking-capable drivers we have seen so far have a contact id with
> the same semantics as the slot id, it makes sense to have the above function to
> remove the need for individual drivers to assign tracking ids.
> 
> With the input core (or input-mt.c) controlling the tracking id, it is easy to
> add more goodness, such as
> 
> /**
>  * input_mt_report_pointer_emulation() - common pointer emulation
>  * @dev: input device with allocated MT slots
>  *
>  * Performs legacy pointer emulation via BTN_TOUCH, etc.
>  */
> void input_mt_report_pointer_emulation(struct input_dev *dev);
> 
> Since the input device knows the MT state and what buttons and abs axes are in
> use, it can provide the right set of data to emit to emulate pointer and touch
> events. The track-oldest-contact logic can be readily implemented.
> 
> From what I can see, this would remove two complications from each MT slots
> driver, removing both code and headaches.
> 
> What do you think?
> 

input-mt.c seems like a good idea for keeping a common library of
goodies for MT drivers.

-- 
Dmitry


More information about the xorg-devel mailing list