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.
/* Fix up bInterval values outside the legal range. Use 32 ms if no
* proper value can be guessed. */
i = 0; /* i = min, j = max, n = default */
j = 255;
if (usb_endpoint_xfer_int(d)) {
i = 1;
switch (to_usb_device(ddev)->speed) {
case USB_SPEED_SUPER:
case USB_SPEED_HIGH:
/* Many device manufacturers are using full-speed
* bInterval values in high-speed interrupt endpoint
* descriptors. Try to fix those and fall back to a
* 32 ms default value otherwise. */
n = fls(d->bInterval*8);
if (n == 0)
n = 9; /* 32 ms = 2^(9-1) uframes */
j = 16;
break;
default: /* USB_SPEED_FULL or _LOW */
/* For low-speed, 10 ms is the official minimum.
* But some "overclocked" devices might want faster
* polling so we'll allow it. */
n = 32;
break;
}
} else if (usb_endpoint_xfer_isoc(d)) {
i = 1;
j = 16;
switch (to_usb_device(ddev)->speed) {
case USB_SPEED_HIGH:
n = 9; /* 32 ms = 2^(9-1) uframes */
break;
default: /* USB_SPEED_FULL */
n = 6; /* 32 ms = 2^(6-1) frames */
break;
}
}
if (d->bInterval < i || d->bInterval > j) {
dev_warn(ddev, "config %d interface %d altsetting %d "
"endpoint 0x%X has an invalid bInterval %d, "
"changing to %d\n",
cfgno, inum, asnum,
d->bEndpointAddress, d->bInterval, n);
endpoint->desc.bInterval = n;
}
The keyboard in question is USB 2.0. I thought LOW and FULL speed only
applied to 1.0 devices. 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.
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.
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.
Regards
Jim Michels
--
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
