linux-kernel - RE: [PATCH] input: mt: introduce MT event slots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Apr 2010 08:40:37 +0100
From:	"Hennerich, Michael" <Michael.Hennerich@...log.com>
To:	Henrik Rydberg <rydberg@...omail.se>,
	Michael Poole <mdpoole@...ilus.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/