On Fri, Mar 27, 2015 at 11:59 AM, Jean Delvare <jdelvare@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
