Re: [RFC] Multi-Touch (MT) support - arbitration or not
From: Ping Cheng <hidden>
Date: 2010-11-11 21:25:25
On Thu, Nov 11, 2010 at 11:41 AM, Henrik Rydberg [off-list ref] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html