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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 27 Jul 2012 18:40:02 +0800
From:	Daniel Kurtz <djkurtz@...omium.org>
To:	Chase Douglas <chase.douglas@...onical.com>
Cc:	Henrik Rydberg <rydberg@...omail.se>,
	"Chung-Yih Wang (王崇懿)" 
	<cywang@...gle.com>, Dmitry Torokhov <dmitry.torokhov@...il.com>,
	JJ Ding <dgdunix@...il.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

On Sat, Jul 21, 2012 at 2:31 AM, Chase Douglas
<chase.douglas@...onical.com> wrote:
>
> On 07/20/2012 02:03 AM, Daniel Kurtz wrote:
>>>>>>
>>>>>> * Leave the device as SEMI_MT, but provide the real locations, and
>>>>>> allow userspace to determine the device vendor/model/etc. If
>>>>>> userspace knows that a specific device behaves in a specific way, it
>>>>>> can do its own quirking handling. Given the specificity of this
>>>>>> behavior to only some devices of one brand, this would be my
>>>>>> suggested resolution to the issue.
>>
>>
>> This is essentially what this patch does.  It sets the SEMI_MT flag to
>> indicate that the kernel data cannot be totally trusted, and then
>> provides real MT-B (including per-finger pressures), instead of a
>> fixed bounding box.  It leaves it to userspace to treat the two slots
>> worth of coordinates as a bounding box or as actual fingers using its
>> own heuristics.  By limiting to only one hardware type (using DMI),
>> any breakage caused by this alternative use of the SEMI_MT flag is
>> limited.
>
>
> So I was worried that you were trying to remove the SEMI_MT flag, and I apologise for not looking closely enough to notice that wasn't the case. The documentation for the flag says:
>
> """
> Some touchpads, most common between 2008 and 2011, can detect the presence of multiple contacts without resolving the individual positions; only the number of contacts and a rectangular shape is known. For such touchpads, the semi-mt property should be set.
>
> Depending on the device, the rectangle may enclose all touches, like a bounding box, or just some of them, for instance the two most recent touches. The diversity makes the rectangle of limited use, but some gestures can normally be extracted from it.
> """
>
> Since the documentation doesn't say the data must be provided as min/max values, this patch actually appears to be perfectly fine as is.
>
> My next question is: how are you going to tell from userspace if the hardware actually provides correct data? IIRC, it was decided that we wouldn't provide sysfs nodes for the device IDs.
>

Excellent question.  We haven't solved this in any elegant way.  When
building images for this particular hardware platform, we set a flag
in our user-space touchpad driver.  It then knows to process this
device's data as "non-bounding box semi-mt".

-Daniel

> -- Chase
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ