On Wed, 23 Jul 2014, James Michels wrote: > I must disagree, the device driver most certainly does guess. See the > code snipet below. Particularly the part about "guessed" and "try to > fix". FWIW, it's the "try to fix" part that doesn't catch this > scenario. You didn't read what I wrote in context. You said: "the driver tries to guess if the bInterval is reported in exponent or frames". The code does not try to guess this. Rather, it tries to guess at a reasonable value for bInterval if the reported value is invalid. > The keyboard in question is USB 2.0. I thought LOW and FULL speed only > applied to 1.0 devices. That's a common mistake. Consider, for example, what happens if you plug your USB-2.0 keyboard into a USB-1.1 hub. > Also, I don't know why someone would go out of > their way to quirk a 1.0 keyboard with a 2.0+ quirk. Not trying to be > a smart a** here, but I am under the, possibly mistaken impression, > that picking the right quirks is the responsibility of whoever picks > them. Certainly. I never said that your quirk would be used incorrectly; I said that it was too non-specific -- meaning that it might not be usable for other devices very well. Also... A USB-1.1 device theoretically could have a descriptor for an isochronous endpoint that incorrectly used non-exponential coding. Wouldn't you want to fix that with your quirk flag? > The device malfunctions with the unmodified driver. Keys presses are > missed and key release are held until additional keys are pressed. > Treating the bInterval as being reported in microframes and applying > the appropriate corrections resolves the issue. I thought, perhaps > incorrectly, that using a QUIRK was the preferred way to handle this > situation. It's not clear. For example, it might be better to fix this in the usbhid driver instead of in usbcore. I'm not sure which is preferable. > So.... > 1) Should I treat this as a quirk? > 2) Should I limit my patch to this hardware only? Or something beyond that? > 3) What is the least offensive name you can suggest for the quirk? > (assuming that you think there should be one) > > This is your party, I am just an uninvited guest trying to get a > keyboard fix in. Tell me what you want and I will gladly comply. Okay. For the time being, name the quirk USB_QUIRK_NON_EXPONENTIAL_INTR_BINTERVAL, or if you prefer, USB_QUIRK_LINEAR_INTR_BINTERVAL. Do the fixup inside the part of the code that handles interrupt endpoints for Super- and high-speed connections. We'll see how that looks. Alan Stern -- 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
