On Wed, 23 Jul 2014, James Michels wrote: > The Razer reports a bInterval of 8 which the current driver ultimately > interprets as 16ms. The keyboard is an anti-ghosting gaming keyboard > and needs to be polled at 1ms. This corresponds to a corrected > bInterval of 4. Okay, that's reasonable. A high-performance gaming keyboard would naturally need a rapid polling interval. > I'm not sure why this doesn't make sense to you, Suppose the keyboard was connected at full speed instead of high speed. The full-speed endpoint descriptor most likely has bInterval set to 1, corresponding to 1 ms. But with your USB_QUIRK_INTERVAL_AS_MICROFRAMES flag set, the kernel would try to interpret the value as 1 microframe, which is completely meaningless for a full-speed connection. > but I do agree that > there is room for naming the quirk something better. As well, there is > room for the bInterval correction logic to be improved. This is your > area of expertise and I am glad to follow any guidelines that you give > me. On the one hand Greg is saying not to add quirks without a device > to apply the quirk to. On the other hand, you are saying to support > more scenarios than the device I am trying to support needs. IE > interupt vs isochronous. I didn't mean that you should support both. I was referring to the fact that this quirk flag is too non-specific. A device can have lots of interrupt and isochronous endpoint descriptors, and you're adding a single flag. This means you're assuming that either all the descriptors are correct or all of them are wrong in the same way. > Currently, the driver tries to guess if the bInterval is reported in > exponent or frames and simply can not get it right all the time. As in > this case, 8 looks like it's in exponent for, but it's not. The driver doesn't "guess". It follows the USB specification. The Razer Blade keyboard does not comply with the spec -- that's the cause of this problem. > As this is an opt-in quirks, you concerns about it's misapplication, > while valid, won't cause any regression. If you don't mind giving me > some guidance, I will be more than happy to go rewrite the patch to > comply with them and resubmit. The quirk flag computations need to be carried out before the code that tests for out-of-bounds values. Not after, as in your patch. Try rewriting the patch following the outline in my previous email. 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
