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

2015-03-17 Thread Benjamin Tissoires 
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
> On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:
> >On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
> >>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 
> >
> >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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 
> >>>
> >>>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.
> >>
> >
> >Just a thought, but it looks like the problematic generation have the
> >QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
> >ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
> >only if

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

2015-03-17 Thread Benjamin Tissoires 
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
 On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:
 On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
 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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.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.
 
 
 Just a thought, but it looks like the problematic generation have the
 QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
 ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
 only if HID_QUIRK_NO_GET was set?
 
 IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
 maybe that trick would be enough.
 
 Cheers,
 Benjamin
 
 
 
 I'm not sure that'll be enough. Most of our devices use a boot mouse
 interface, even some that work fine using the default quirks (e.g. Cintiq
 24HDT). On the tablet PC side of the world, it looks like its a crapshoot
 whether the sensor will have a boot mouse collection or

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

2015-03-16 Thread Jason Gerecke 

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:

On Mar 16 2015 or thereabouts, Jason Gerecke wrote:

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 


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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 


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.



Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin




I'm not sure that'll be enough. Most of our devices use a boot mouse 
interface, even some that work fine using the default quirks (e.g. 
Cintiq 24HDT). On the tablet PC side of the world, it looks like its a 
crapshoot whether the sensor will have a boot mouse collection or 
something else (though I haven't yet checked to see how they react to 
having a pen in prox without a client).


--
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /

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

2015-03-16 Thread Jason Gerecke 

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:

On Mar 16 2015 or thereabouts, Jason Gerecke wrote:

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 


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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 


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.



Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin




I'm not sure that'll be enough. Most of our devices use a boot mouse 
interface, even some that work fine using the default quirks (e.g. 
Cintiq 24HDT). On the tablet PC side of the world, it looks like its a 
crapshoot whether the sensor will have a boot mouse collection or 
something else (though I haven't yet checked to see how they react to 
having a pen in prox without a client).


--
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /

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

2015-03-16 Thread Benjamin Tissoires 
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
> 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 
> >>>
> >>>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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 
> >
> >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.
> 

Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at

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

2015-03-16 Thread Jason Gerecke 

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 


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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 


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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Benjamin Tissoires 
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 
> >
> > 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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 

Thanks!

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jiri Kosina 
On Mon, 16 Mar 2015, Jason Gerecke wrote:

> 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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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:
> 
> Acked-by: Jason Gerecke 

Applied to for-4.1/wacom, thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jason Gerecke 
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 
>
> 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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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:

Acked-by: Jason Gerecke 

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jiri Kosina 
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 

Ping, Jason, I'd like to get your Ack on this before pushing this through 
if possible.

Thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jiri Kosina 
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.tissoi...@redhat.com

Ping, Jason, I'd like to get your Ack on this before pushing this through 
if possible.

Thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jason Gerecke 

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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jason Gerecke 

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:

On Mar 16 2015 or thereabouts, Jason Gerecke wrote:

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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.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.



Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin




I'm not sure that'll be enough. Most of our devices use a boot mouse 
interface, even some that work fine using the default quirks (e.g. 
Cintiq 24HDT). On the tablet PC side of the world, it looks like its a 
crapshoot whether the sensor will have a boot mouse collection or 
something else (though I haven't yet checked to see how they react to 
having a pen in prox without a client).


--
Jason
---
Now instead of four in the eights

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

2015-03-16 Thread Jason Gerecke 

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:

On Mar 16 2015 or thereabouts, Jason Gerecke wrote:

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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.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.



Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin




I'm not sure that'll be enough. Most of our devices use a boot mouse 
interface, even some that work fine using the default quirks (e.g. 
Cintiq 24HDT). On the tablet PC side of the world, it looks like its a 
crapshoot whether the sensor will have a boot mouse collection or 
something else (though I haven't yet checked to see how they react to 
having a pen in prox without a client).


--
Jason
---
Now instead of four in the eights

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

2015-03-16 Thread Benjamin Tissoires 
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
 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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.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.
 

Just a thought, but it looks like the problematic generation have the
QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I
ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET
only if HID_QUIRK_NO_GET was set?

IIRC, there was no problems on the Intuos 4+ with the USB suspend, so
maybe that trick would be enough.

Cheers,
Benjamin


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Benjamin Tissoires 
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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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 killert...@gmail.com

Thanks!

Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jason Gerecke 
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.tissoi...@redhat.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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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:

Acked-by: Jason Gerecke killert...@gmail.com

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-16 Thread Jiri Kosina 
On Mon, 16 Mar 2015, Jason Gerecke wrote:

 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/pci:00/: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/pci:00/: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-: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/pci:00/: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/pci:00/: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-: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:
 
 Acked-by: Jason Gerecke killert...@gmail.com

Applied to for-4.1/wacom, thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-05 Thread Benjamin Tissoires 
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 
---

Change in v2:
- commit message amended (a little)
- unset the flag HID_QUIRK_NO_GET to make the code compatible with Intuos 3 and
  4

 drivers/hid/wacom_sys.c |  3 +++
 drivers/hid/wacom_wac.c | 18 +-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 957699f..22cac9d 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1389,6 +1389,9 @@ static int wacom_probe(struct hid_device *hdev,
 
hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
 
+   /* hid-core sets this quirk for the boot interface */
+   hdev->quirks &= ~HID_QUIRK_NOGET;
+
wacom = kzalloc(sizeof(struct wacom), GFP_KERNEL);
if (!wacom)
return -ENOMEM;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9ec4545..ff9a7ab 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -430,6 +430,19 @@ exit:
return retval;
 }
 
+static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
+{
+   struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+   struct hid_report *r;
+   struct hid_report_enum *re;
+
+   re = &(wacom->hdev->report_enum[HID_FEATURE_REPORT]);
+   r = re->report_id_hash[WACOM_REPORT_INTUOSREAD];
+   if (r) {
+   hid_hw_request(wacom->hdev, r, HID_REQ_GET_REPORT);
+   }
+}
+
 static int wacom_intuos_inout(struct wacom_wac *wacom)
 {
struct wacom_features *features = >features;
@@ -609,8 +622,11 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
}
 
/* don't report other events if we don't know the ID */
-   if (!wacom->id[idx])
+   if (!wacom->id[idx]) {
+   /* but reschedule a read of the current tool */
+   wacom_intuos_schedule_prox_event(wacom);
return 1;
+   }
 
return 0;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2015-03-05 Thread Benjamin Tissoires 
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.tissoi...@redhat.com
---

Change in v2:
- commit message amended (a little)
- unset the flag HID_QUIRK_NO_GET to make the code compatible with Intuos 3 and
  4

 drivers/hid/wacom_sys.c |  3 +++
 drivers/hid/wacom_wac.c | 18 +-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 957699f..22cac9d 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1389,6 +1389,9 @@ static int wacom_probe(struct hid_device *hdev,
 
hdev-quirks |= HID_QUIRK_NO_INIT_REPORTS;
 
+   /* hid-core sets this quirk for the boot interface */
+   hdev-quirks = ~HID_QUIRK_NOGET;
+
wacom = kzalloc(sizeof(struct wacom), GFP_KERNEL);
if (!wacom)
return -ENOMEM;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9ec4545..ff9a7ab 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -430,6 +430,19 @@ exit:
return retval;
 }
 
+static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
+{
+   struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+   struct hid_report *r;
+   struct hid_report_enum *re;
+
+   re = (wacom-hdev-report_enum[HID_FEATURE_REPORT]);
+   r = re-report_id_hash[WACOM_REPORT_INTUOSREAD];
+   if (r) {
+   hid_hw_request(wacom-hdev, r, HID_REQ_GET_REPORT);
+   }
+}
+
 static int wacom_intuos_inout(struct wacom_wac *wacom)
 {
struct wacom_features *features = wacom-features;
@@ -609,8 +622,11 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
}
 
/* don't report other events if we don't know the ID */
-   if (!wacom-id[idx])
+   if (!wacom-id[idx]) {
+   /* but reschedule a read of the current tool */
+   wacom_intuos_schedule_prox_event(wacom);
return 1;
+   }
 
return 0;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/