linux-kernel - Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

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: <55074239.4070407@gmail.com>
Date:	Mon, 16 Mar 2015 13:51:05 -0700
From:	Jason Gerecke <killertofu@...il.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
CC:	Jiri Kosina <jkosina@...e.cz>, Ping Cheng <pinglinux@...il.com>,
	Linux Input <linux-input@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 12:27 PM, Benjamin Tissoires wrote:
> On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
>> On 3/16/2015 7:50 AM, Jiri Kosina wrote:
>>> On Thu, 5 Mar 2015, Benjamin Tissoires wrote:
>>>
>>>> If noone listens to the input device when a tool comes in proximity,
>>>> the tablet does not send the in-prox event when a client becomes available.
>>>> That means that no events will be sent until the tool is taken out of
>>>> proximity.
>>>>
>>>> In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
>>>> read the corresponding feature and generate an in-prox event.
>>>> To make some generation of hardware working, we need to unset the
>>>> quirk NO_GET set by hid-core because the interfaces are seen as "boot
>>>> mouse".
>>>>
>>>> We don't schedule this read in a worker while we are in an IO interrupt.
>>>> We know that usbhid will do it asynchronously. If this is triggered by
>>>> uhid, then this is obviously a client side bug :)
>>>>
>>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
>>>
>>> Ping, Jason, I'd like to get your Ack on this before pushing this through
>>> if possible.
>>>
>>> Thanks.
>>>
>>
>> This update seems to have solved the issue I was having earlier. I do
>> still see some weird behavior with the Intuos3 though. For whatever
>> reason, if a tool is in prox and no client is connected, the device
>> will repeatedly connect and disconnect from the bus. For example,
>> while sitting at a VT after connecting the device:
>>
>> [  209.890431] usb 2-1.5.4: new full-speed USB device number 10 using ehci-pci
>> [  209.992189] input: Wacom Intuos3 6x8 as
>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.0009/input/input26
>> [  209.992475] input: Wacom Intuos3 6x8 Pad as
>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.0009/input/input27
>> [  209.992846] wacom 0003:056A:00B1.0009: hidraw4: USB HID v1.00 Mouse
>> [Tablet PTZ-630] on usb-0000:00:1d.0-1.5.4/input0
>> [  213.022545] usb 2-1.5.4: USB disconnect, device number 10
>> [  213.344055] usb 2-1.5.4: new full-speed USB device number 11 using ehci-pci
>> [  213.445779] input: Wacom Intuos3 6x8 as
>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.000A/input/input28
>> [  213.446185] input: Wacom Intuos3 6x8 Pad as
>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.000A/input/input29
>> [  213.446703] wacom 0003:056A:00B1.000A: hidraw4: USB HID v1.00 Mouse
>> [Tablet PTZ-630] on usb-0000:00:1d.0-1.5.4/input0
>> [  214.815925] usb 2-1.5.4: USB disconnect, device number 11
>> [  215.246142] usb 2-1.5.4: new full-speed USB device number 12 using ehci-pci
>>
>> [ ... and so on ...]
>>
>> It makes using the device from a VT difficult (e.g. for debugging),
>> but in the typical case where X is started shortly after boot and
>> hotplugs devices as soon as they're available it shouldn't pose a
>> problem. If Benjamin has any ideas I'd like to hear them, but in the
>> meantime I'm comfortable seeing this go upstream:
>
> HID_QUIRK_ALWAYS_POLL :)
>
> Some usb devices do not like to not be polled and keep
> disconnecting/reconnecting. Looks like the Intuos 3 is one of them.
> The only cons are that the device won't save power when no one is reading
> the inputs. Not sure if that is a requirement for Wacom tablets though.
>
> Note that HID_QUIRK_ALWAYS_POLL should make this patch useless in these
> cases, the kernel will keep track of the current device because it will
> receive the events.
>
>>
>> Acked-by: Jason Gerecke <killertofu@...il.com>
>
> Thanks!
>
> Cheers,
> Benjamin
>

That does indeed seem to solve the Intuos3 weirdness :)

Saving power is a big deal for ISDv4/5 sensors where it has a direct 
impact on runtime. If setting HID_QURIK_ALWAYS_POLL e.g. disables USB 
selective suspend then that'd be an issue. However, if it simply causes 
the kernel to respond to events even if nobody is listening then it'd 
probably be similar to the situation when we were under drivers/input.

I'm inclined to say we should target that quirk at only those devices 
that need it since I know tablet PC manufacturers go to quite some 
lengths to minimize every mA of unnecessary current draw from the batteries.

-- 
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
--
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/