linux-kernel - Re: [PATCH] input: mt: Add an envelope tool type

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: <4CFFDB35.2020506@euromail.se>
Date:	Wed, 08 Dec 2010 20:23:33 +0100
From:	Henrik Rydberg <rydberg@...omail.se>
To:	Chase Douglas <chase.douglas@...onical.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: mt: Add an envelope tool type

>>> I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.

> 
> This is really the main point I wanted to make, even though it was
> hidden among other things :). Do you have thoughts here?


I think envelope works fine - it is easier to associate with a single point that
the notion of a rectangle.

>>> 2. We could provide for multiple simultaneous rects by using the value
>>> of the MT_TOOL_RECT property. The first rect would have value 0, the
>>> second would have value 1, etc. I don't know if this will ever be used
>>> since most devices will have real MT soon enough, but it wouldn't hurt
>>> to define this.
>>
>> I do think this is an unnecessary complication.
> 
> It's not really any complication. I think we should define what the
> valid values are for MT_TOOL_{RECT,ENVELOPE} even if only one envelope
> is supported. Thus, I don't see why we shouldn't allow for multiple
> values for multiple rects.

> 
> Hardware manufacturers always seem to surprise us with what they come up
> with too :).


Yes, which is exciting per se. However, hardware seems to be moving towards more
individual (and tracked) contacts, and more granularity per contact. The idea of
supporting complex, non-connected boundaries (implication of your proposal),
which by construction contains less information that the individual contacts,
seems to be going against that trend. Since there are no current need for it,
and the indications point in a different direction, I suggest we put that in the
bag of possible "I told you so", and leave it open for now. ;-)

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