linux-kernel - Re: [PATCH 2/3] hid-multitouch: Filter collections by application usage.

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:	Mon, 25 Jul 2011 15:48:24 +0200
From:	Stéphane Chatty <chatty@...c.fr>
To:	benjamin.tissoires@...il.com
Cc:	jeffbrown@...roid.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
	rydberg@...omail.se, Jeff Brown <jeffbrown@...gle.com>
Subject: Re: [PATCH 2/3] hid-multitouch: Filter collections by application  usage.


Le 25 juil. 2011 à 11:29, benjamin.tissoires@...il.com a écrit :

> Hi Jeff,
> 
> I like the patch as it partially solves the problems left by
> b84bd27fe70206f9253c395958134e4e4b7e55f0 (fix broken egalax). The
> previous patch mapped buttons but now it should be ok.
> Though, we still have the problem of the distinction between stylus and finger.
> 
> It would worth the effort to know if reverting
> b84bd27fe70206f9253c395958134e4e4b7e55f0 and apply this one instead
> still works for eGalax 480d owners (and mosart too IIRC).
> 
> 
> On Mon, Jul 25, 2011 at 11:16, Stéphane Chatty <chatty@...c.fr> wrote:
>> 
>> Le 25 juil. 2011 à 00:07, jeffbrown@...roid.com a écrit :
>> 
>>> From: Jeff Brown <jeffbrown@...gle.com>
>>> 
>>> This change fixes two problems.
>>> 
>>> First, it ensures that the hid-multitouch driver does not incorrectly
>>> map GenericDesktop usages that are intended for other applications,
>>> such as a Mouse.
>>> 
>>> Second, it sets the appropriate input properties so that user-space
>>> can distinguish TouchScreen devices (INPUT_PROP_DIRECT) from
>>> TouchPad devices (INPUT_PROP_POINTER) and configure them accordingly.
>>> 
>>> Signed-off-by: jeffbrown@...roid.com
>>> ---
>>> drivers/hid/hid-multitouch.c |   10 ++++++++++
>>> 1 files changed, 10 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>> index 58d0e7a..4ee21ac 100644
>>> --- a/drivers/hid/hid-multitouch.c
>>> +++ b/drivers/hid/hid-multitouch.c
>>> @@ -213,6 +213,16 @@ static int mt_input_mapping(struct hid_device *hdev, struct hid_input *hi,
>>>       struct mt_class *cls = td->mtclass;
>>>       __s32 quirks = cls->quirks;
>>> 
>>> +     /* Only map fields from TouchScreen or TouchPad collections.
>>> +         * We need to ignore fields that belong to other collections
>>> +         * such as Mouse that might have the same GenericDesktop usages. */
>>> +     if (field->application == HID_DG_TOUCHSCREEN)
>>> +             set_bit(INPUT_PROP_DIRECT, hi->input->propbit);
>>> +     else if (field->application == HID_DG_TOUCHPAD)
>>> +             set_bit(INPUT_PROP_POINTER, hi->input->propbit);
>>> +     else
>>> +             return 0;
> 
> Maybe I'm wrong, but 0 means that hid-input will decide what to do.
> Maybe we should return -1 instead, to be sure not handling this part.
> 
>>> +
>>>       switch (usage->hid & HID_USAGE_PAGE) {
>>> 
>>>       case HID_UP_GENDESK:
>>> --
>>> 1.7.0.4
>>> 
>> 
>> 
>> Looks clever to me. Still, in principle we should check that all (or at least most) known devices fill the application field properly. I'll try to have a look at the report descriptors we have here.
> 
> I checked (with some greps) the reports we have, and it seems that all
> the device we know provide this application. So it should be safe, but
> I'm not able to test it.
> Stéphane, if you have the time to test it on our lab's devices that
> would be great.

So far it works fine on our Cypress panel. I'll keep you posted about Lumio and Stantum as soon as we have finished compiling Linux 3.0.

St.

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