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