On Sun, 2010-05-23 at 00:30 +0200, Henrik Rydberg wrote: > With the rapidly increasing number of intelligent multi-contact and > multi-user devices, the need to send digested, filtered information > from a set of different sources within the same device is imminent. > This patch adds the concept of slots to the MT protocol. The slots > enumerate a set of identified sources, such that all MT events > can be passed independently and selectively per identified source. > > The protocol works like this: Instead of sending a SYN_MT_REPORT > event immediately after the contact data, one sends an ABS_MT_SLOT > event immediately before the contact data. The input core will only > emit events for slots with modified MT events. It is assumed that > the same slot is used for the duration of an initiated contact. > > Signed-off-by: Henrik Rydberg <rydberg@xxxxxxxxxxx> > --- > Revision 5 incorporates the following changes: > - Rename the slot event to ABS_MT_SLOT to keep all MT-related events > in the same namespace. > - Move the MT slot event list to input.h so that it can be read > by userspace. > > drivers/input/input.c | 105 +++++++++++++++++++++++++++++++++++++------------ > include/linux/input.h | 44 ++++++++++++++++++++ > 2 files changed, 123 insertions(+), 26 deletions(-) I was wondering what the status of this patch was. I reviewed it and I think it's a good improvement of the protocol. I think it will help simplify things in userspace event handling, and should reduce the noise in evdev. I also like the incremental approach in that it doesn't force drivers into the new protocol, but makes it available for them when they can use it. Acked-by: Chase Douglas <chase.douglas@xxxxxxxxxxxxx> Long term, I think it makes the most sense to have a layer inside the kernel to do software touch tracking and expose all MT data through the slots protocol instead of it being determined by the capabilities of the device/driver. -- Chase -- 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
