Messages in this thread | | | From | "Hennerich, Michael" <> | Date | Fri, 16 Apr 2010 08:40:37 +0100 | Subject | RE: [PATCH] input: mt: introduce MT event slots |
| |
Henrik Rydberg wrote on 2010-04-08: > Michael Poole wrote: > [...] >> >> For hardware with touch tracking support, what does a slot ID >> provide for user-space that the tracking ID doesn't? (TRACKING_ID >> is already supposed to be unique for the life of the touch.) > > The purpose of the slot is twofold. Firstly, it reintroduces the > ability for the kernel to filter ABS_MT events, which reduces the > number of events emitted from the input core by a large factor. > Secondly, it allows the driver to send partial information without > breaking the protocol. > > The current MT protocol is designed for anonymous contacts, which > dictates that all data for all fingers has to be sent between every > synchronization point. > Although this is fine for a handful of fingers, it does not play well > with a larger scenario. The slot concept allows for a minimum of > information to be emitted from the input core, without breaking > compatibility with the current MT protocol. If a single attribute of a > single finger of a single user is changed, the event sequence will > simply be: > > SYN_MT_SLOT <slot-in-use> > ABS_MT_ATTRIBUTE <some-value> > > If the contact gets destroyed and replaced by another one, there is > not even a need to send that information explicitly, but this sequence > would suffice: > > SYN_MT_SLOT <slot-in-use> > ABS_MT_USER_ID <replacing-user> > ABS_MT_TRACKING_ID <replacing-tracking-id> > ABS_MT_ATTRIBUTE1 <some-value> > ABS_MT_ATTRIBUTE2 <some-value> > ...
Sorry, I must have missed something - What is ABS_MT_USER_ID?
Regards, Michael
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
| |