quirk ALWAYS_POLL needed with an unexpectedly high number of mice

quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Oliver Neukum]

Hi,

I am getting reports from a customer running an unintentional
stress test for this quirk. I would have to add a dozen mice
in the medium term. Is that desirable?
Should we make the quirk the default? Or add a module parameter
to let the pessimistic users with multiple desktop rodents
select the quirk as default? Or just carry on?
Comments?

	Regards
		Oliver

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Benjamin Tissoires]

On Fri, Mar 27, 2015 at 5:29 AM, Oliver Neukum <oneukum@suse.de> wrote:
> Hi,
>
> I am getting reports from a customer running an unintentional
> stress test for this quirk. I would have to add a dozen mice
> in the medium term. Is that desirable?
> Should we make the quirk the default? Or add a module parameter
> to let the pessimistic users with multiple desktop rodents
> select the quirk as default? Or just carry on?
> Comments?
>

usbhid/hid-core.c already sets HID_QUIRK_NOGET for regular mice/keyboards [1].
Maybe adding ALLWAYS_POLL to those would make sense and solve your problem?

BTW I am against having this quirk as the general default because we
rely on the usb autosuspend to shut off the touchscreens when no one
listen to them, and the touchscreens are draining a lot of power.

Cheers,
Benjamin

[1] https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/tree/drivers/hid/usbhid/hid-core.c#n988

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Oliver Neukum]

On Fri, 2015-03-27 at 09:18 -0400, Benjamin Tissoires wrote:
> On Fri, Mar 27, 2015 at 5:29 AM, Oliver Neukum <oneukum@suse.de> wrote:
> > Hi,
> >
> > I am getting reports from a customer running an unintentional
> > stress test for this quirk. I would have to add a dozen mice
> > in the medium term. Is that desirable?
> > Should we make the quirk the default? Or add a module parameter
> > to let the pessimistic users with multiple desktop rodents
> > select the quirk as default? Or just carry on?
> > Comments?
> >
> 
> usbhid/hid-core.c already sets HID_QUIRK_NOGET for regular mice/keyboards [1].
> Maybe adding ALLWAYS_POLL to those would make sense and solve your problem?

It would solve my problem, but it would do so at the expense of hurting
devices that operate correctly, but only by a small amount. 

> BTW I am against having this quirk as the general default because we
> rely on the usb autosuspend to shut off the touchscreens when no one
> listen to them, and the touchscreens are draining a lot of power.

I see. As long as they support remote wakeup, autosuspend will
still work. A source of remote wakeup, however, is allowed to
draw more power while suspended.

Keeping things as is is fine by me but then I will need to add a lot of
quirky devices.

	Regards
		Oliver

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Jiri Kosina]

On Fri, 27 Mar 2015, Oliver Neukum wrote:

> > usbhid/hid-core.c already sets HID_QUIRK_NOGET for regular mice/keyboards [1].
> > Maybe adding ALLWAYS_POLL to those would make sense and solve your problem?
> 
> It would solve my problem, but it would do so at the expense of hurting 
> devices that operate correctly, but only by a small amount.
> 
> > BTW I am against having this quirk as the general default because we
> > rely on the usb autosuspend to shut off the touchscreens when no one
> > listen to them, and the touchscreens are draining a lot of power.
> 
> I see. As long as they support remote wakeup, autosuspend will
> still work. A source of remote wakeup, however, is allowed to
> draw more power while suspended.
> 
> Keeping things as is is fine by me but then I will need to add a lot of 
> quirky devices.

I am still surprised that all of a sudden there is such a large flow of 
new devices that need it, and we didn't have a single one a few months 
ago.

Given the fact that this all is being reported by single entitty, is it a 
possibility that they have some other faulty HW instead? Such as the HUB 
suspending at random incorrect points in time?

-- 
Jiri Kosina
SUSE Labs

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Jean Delvare]

Le Friday 27 March 2015 à 16:10 +0100, Jiri Kosina a écrit :
> On Fri, 27 Mar 2015, Oliver Neukum wrote:
> > Keeping things as is is fine by me but then I will need to add a lot of 
> > quirky devices.
> 
> I am still surprised that all of a sudden there is such a large flow of 
> new devices that need it, and we didn't have a single one a few months 
> ago.
> 
> Given the fact that this all is being reported by single entitty, is it a 
> possibility that they have some other faulty HW instead? Such as the HUB 
> suspending at random incorrect points in time?

I agree, I start wondering if maybe we've been barking up the wrong tree
since the beginning. I very much would like to know if all these
"faulty" mouses would be so faulty when used on a different system.

-- 
Jean Delvare
SUSE L3 Support

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

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Benjamin Tissoires]

On Fri, Mar 27, 2015 at 11:59 AM, Jean Delvare <jdelvare@suse.de> wrote:
> Le Friday 27 March 2015 à 16:10 +0100, Jiri Kosina a écrit :
>> On Fri, 27 Mar 2015, Oliver Neukum wrote:
>> > Keeping things as is is fine by me but then I will need to add a lot of
>> > quirky devices.
>>
>> I am still surprised that all of a sudden there is such a large flow of
>> new devices that need it, and we didn't have a single one a few months
>> ago.
>>
>> Given the fact that this all is being reported by single entitty, is it a
>> possibility that they have some other faulty HW instead? Such as the HUB
>> suspending at random incorrect points in time?
>
> I agree, I start wondering if maybe we've been barking up the wrong tree
> since the beginning. I very much would like to know if all these
> "faulty" mouses would be so faulty when used on a different system.
>

Hmm... it looks like it's not host dependent unfortunately. We have a
(private) bug report for RHEL 6 where a customer wants to use the
following mouse:
http://www.compsource.com/pn/2MOUSEU1L/Keytronics-228/

I bought one and was able to reproduce the need for the quirk on
various systems.

Plus I noticed that if the mouse is raised over the surface (so the
sensor does not report anything), the bug does not appear.

So, to me, the USB output queue is full given that it is not polled by
the host and the chip within the USB mouse decides to
disconnect/reconnect to empty the queue. So nothing host specific.

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

Re: quirk ALWAYS_POLL needed with an unexpectedly high number of mice

[Jiri Kosina]

On Fri, 27 Mar 2015, Benjamin Tissoires wrote:

> Hmm... it looks like it's not host dependent unfortunately. We have a
> (private) bug report for RHEL 6 where a customer wants to use the
> following mouse:
> http://www.compsource.com/pn/2MOUSEU1L/Keytronics-228/
> 
> I bought one and was able to reproduce the need for the quirk on
> various systems.
> 
> Plus I noticed that if the mouse is raised over the surface (so the
> sensor does not report anything), the bug does not appear.
> 
> So, to me, the USB output queue is full given that it is not polled by
> the host and the chip within the USB mouse decides to
> disconnect/reconnect to empty the queue. So nothing host specific.

I am not questioning at all that it's needed for some devices.

But I am surprised by all-of-a-sudden flow for quirk addition for many 
distinct devices, all coming from the same source. I am afraid this might 
be false positive, and root-cause being somewhere else, causing us adding 
a lot of potentially unnecessary quirk entries.

-- 
Jiri Kosina
SUSE Labs