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. I'm not sure why this doesn't make sense to you, 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. 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. 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. Regards Jim Michels On Wed, Jul 23, 2014 at 10:44 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 22 Jul 2014, James P Michels III wrote: > >> This patch adds usb quirks to improve support for devices >> with non standard bInterval values. Quirks are added to support devices with >> bInterval values expressed as microframes or frames. The quirks cause the >> parse endpoint function to modify the reported bInterval to the standards >> conforming value. > > Sorry, but this makes no sense. The quirk is a property of the device > as a whole, whereas whether to interpret interval values in frames or > microframes depends on the speed of the USB connection. What would > happen if a device had the USB_QUIRK_INTERVAL_AS_MICROFRAMES flag set > but it was connected at full speed? > > The quirk should instead be something like > USB_QUIRK_NON_EXPONENTIAL_BINTERVAL, and maybe there should be separate > flags for interrupt vs. isochronous endpoints. Then the fixup code > should vary its action depending on the connection speed. > > Even that might not work in all cases. It's conceivable that a device > could get the bInterval wrong for endpoints in one config and right for > endpoints in a different config. > > Anyway, is this even needed? What's wrong with the existing code? > What values does this Razer Blade device have in its descriptors? > > 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
