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

[Henrik Rydberg <rydberg@euromail.se>]

>>

>> 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?

Henrik