>> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
