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, 16 Mar 2015 15:27:33 -0400
From:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:	Jason Gerecke <killertofu@...il.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 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
--
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