[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