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

[Ping Cheng]

On Thu, Nov 11, 2010 at 11:41 AM, Henrik Rydberg <rydberg at euromail.se> wrote:
>
> 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

I agree that centralizing the common code is a good way to go.


> /**
>  * 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.

Are we going to do the tocuh and pen aribtration in input-mt.c? I need
to understand this to make my patches.

Sounds a bit complicated if we do the aribtration here, considering
the differences between pen and tocuh. If not, we will need to tell
input_mt_report_pointer_emulation if another tool (such as pen) has
already sent pointer events. That is input_mt_report_pointer_emulation
is only called when needed.

Ping