linux-kernel - Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev3)

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]

Message-ID: <4BF782D6.5060305@euromail.se>
Date:	Sat, 22 May 2010 09:08:06 +0200
From:	Henrik Rydberg <rydberg@...omail.se>
To:	Ping Cheng <pinglinux@...il.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Peter Hutterer <peter.hutterer@...-t.net>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Rafi Rubin <rafi@...s.upenn.edu>,
	Michael Poole <mdpoole@...ilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev3)

Ping Cheng wrote:
> On Fri, May 21, 2010 at 10:49 AM, Henrik Rydberg <rydberg@...omail.se> wrote:
>> Dmitry Torokhov wrote:
>>> I guess this is where our disconnect lies as when I am looking at the
>>> event names I view all *_MT_* events as related to the multitouch
>>> protocol handling.
>>>
>> Yes. It is true that slot control is MT related, but I am looking at this from
>> the perspective of future expansions like KEY_MT,  KEY_REL, and such, finding a
>> way to signal to user space which events are handled via slots. If we had
>> ABS_MT_SLOT, we would most likely get applications which store ABS_MT_SLOT as an
>> attribute of the slot together with ABS_MT_POSITION_X, ABS_MT_TOUCH_MAJOR, etc,
>> which is just not right.
> 
> Why is it not right?  Do you mean ABS_SLOT can be used as a label for
> both _MT_ and non _MT_ events while ABS_MT_SLOT can not?
> 
>> So the proposal is ABS_SLOT.
> 
> I haven't convinced myself with this proposal yet. Can you explain the
> difference between ABS_SLOT and ABS_MT_SLOT with a concrete example?
> Fool always ignores Mark Twain's advice, you know :).

Ah. :-)

At this point, we seem to be discussing which solution is the least evil. To
recapitulate, the slot event should be neither an ABS event, nor an ABS_MT
event, but a SYN event as proposed earlier. In my view, the real solution is to
add the possibility to report usage and value range of SYN events to EVIO. To
move the slot event from SYN to ABS was an act of compromise, and we now face
this immaterial question.

In another thread regarding these patches, I have held a monologue regarding the
problem of knowing which events should be treated on a per-slot basis, and which
should be treated "the usual way". Currently, events matching *_MT_* are the
ones treated as slot events. One can imagine having better ways to deal with
this, but we do not, currently. And this is where the difference between
"ABS_SLOT" and "ABS_MT_SLOT" comes in.

Henrik

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