On Wed, Aug 28, 2013 at 04:09:32PM +0800, Huang Rui wrote: > On Wed, Aug 28, 2013 at 11:38:28AM +0800, Greg Kroah-Hartman wrote: > > On Wed, Aug 28, 2013 at 11:13:12AM +0800, Huang Rui wrote: > > > This patch add a routine to judge if the usb device is a mouse or not. > > > The is_usb_mouse only has one input parameter of usb_device. The > > > return value is bool type, and true means this device is mouse and > > > vice-versa. > > > > No, sorry, this isn't ok for a number of reasons. > > > > You got "lucky" in that you can duplicate this with a mouse, the fact > > that it is a mouse that caused your problems should never mean that the > > os only triggers on a mouse device. I can create a "keyboard" device > > that has the exact same USB characteristics that a mouse does, that > > should also be able to trigger your problem. Or a vendor specific > > device. > > > > Yes, you're right. This issue is specific to the devices that use > Pixart controller, and the Pixart controller is only used by mouse. > That's why I filtered for usb mouse. So, to "fix" one specific controller, you drag in hundreds of thousands of other devices as well? That's not ok. > Below answer is our HW guys' feedback. In cover letter, you would see > more details. cover letters don't get applied to the kernel changelog, so they don't count for much :) > [Q] Why the special devices are only mice? Would high speed devices > such as 3G modem or USB Bluetooth adapter trigger this issue? > - Current this sensitivity is only confined to devices that use Pixart > controllers. This controller is designed for use with LS mouse > devices only. We have not observed any other devices failing. There > may be a small risk for other devices also but this patch (reset > device in resume phase) will cover the cases if required. Then just do this "quirk" for Pixart controller devices. Don't penalize everyone else. And have you worked with the Pixart company to "fix" this issue so that future devices they create don't have this issue in it? > > That's why the USB core doesn't care about the device type, they are all > > just "pipes". So please deal with it on that level, never do something > > only depending on the "type" of device plugged into the system. > > > > I got it. Do you mean if I want do filter usb devices by usb mouse, I > should do it at hid or usbhid level? Neither, you could "miss" a mouse at those levels as well. Think about userspace control of USB devices, as well as mice that don't use the HID layer (rare, but I've seen it happen.) Again, don't filter for a "mouse", filter for the controller that you need to fix. > > Hint, I bet you didn't fix this bug in Windows this way, right? :) > > > > Actually, this issue is found in Windows firstly, and we set a > registry to force the driver to reset the device on S3 resume to work > around it. Then I reproduce it in Linux OS, and make a same solution. :) So on Windows you do this for all mice devices? Or just Pixart devices? If all mice devices, the Windows developers accepted such a change? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
