I make devices with multiple class compliant interfaces USB MIDI / RAWHID / KEYBOARD. These devices are often plugged into the USB Host ports of 3rd party hardware.
I've noticed that some USB host ports have an issue with the keyboard interface. One in particular was with gear from Expert Sleepers. I talked with the developed and we managed to determine that the source of the issue was a message sent by the USB Host that wasn't being acknowledged. We aren't sure if the bug is with the Teensy code, or the code provided by MicroChip. Hopefully we can get to the bottom of this.
The message being sent by the USB Host is SET_PROTOCOL, which is 0x0B. This message requests that the keyboard use its boot protocol. The teensy always uses the boot protocol, so it doesn't need to change it's configuration, but does it need to acknowledge the message? The MicroChip code seemed to think some sort of acknowledgment is necessary, as it returns an error and fails. If we modify the MicroChip code to ignore the error, the interface enumerates properly.
Here's some info on the SET_PROTOCOL message:
"SetProtocol" request
Assuming a USB HID device supports the boot protocol, as explained in the section above, where is has a class value of 3 and a sub-class value of 1, the driver software can select the protocol to use. It uses the "SetProtocol" request to tell the device whether it wants to use the report protocol or the boot protocol. For simplicity's sake, this article will describe the boot protocol only, for now. To send the "SetProtocol" request, software sends a regular SETUP transaction to the device's control endpoint zero. The SETUP packet's request type would contain 0x21, the request code for "SetProtocol" is 0x0B, and the value field of the SETUP packet should contain 0 to indicate boot protocol, or 1 to indicate report protocol. The index and length fields both must be zero, as the index is unused and this request has no data stages. This command is only supported on device that support the boot protocol at all. After this command has been used, all reports sent from the device to the host will be either boot reports or regular reports, depending on the type the software requests.
https://wiki.osdev.org/USB_Human_Interface_Devices#.22SetProtocol.22_request
And here is the relevant code inside usb_dev.c. You can see that the message seems to be ignored all together. In response to that comment in the code, maybe the other messages fail because 0x0B isn't being handled properly?
I've noticed that some USB host ports have an issue with the keyboard interface. One in particular was with gear from Expert Sleepers. I talked with the developed and we managed to determine that the source of the issue was a message sent by the USB Host that wasn't being acknowledged. We aren't sure if the bug is with the Teensy code, or the code provided by MicroChip. Hopefully we can get to the bottom of this.
The message being sent by the USB Host is SET_PROTOCOL, which is 0x0B. This message requests that the keyboard use its boot protocol. The teensy always uses the boot protocol, so it doesn't need to change it's configuration, but does it need to acknowledge the message? The MicroChip code seemed to think some sort of acknowledgment is necessary, as it returns an error and fails. If we modify the MicroChip code to ignore the error, the interface enumerates properly.
Here's some info on the SET_PROTOCOL message:
"SetProtocol" request
Assuming a USB HID device supports the boot protocol, as explained in the section above, where is has a class value of 3 and a sub-class value of 1, the driver software can select the protocol to use. It uses the "SetProtocol" request to tell the device whether it wants to use the report protocol or the boot protocol. For simplicity's sake, this article will describe the boot protocol only, for now. To send the "SetProtocol" request, software sends a regular SETUP transaction to the device's control endpoint zero. The SETUP packet's request type would contain 0x21, the request code for "SetProtocol" is 0x0B, and the value field of the SETUP packet should contain 0 to indicate boot protocol, or 1 to indicate report protocol. The index and length fields both must be zero, as the index is unused and this request has no data stages. This command is only supported on device that support the boot protocol at all. After this command has been used, all reports sent from the device to the host will be either boot reports or regular reports, depending on the type the software requests.
https://wiki.osdev.org/USB_Human_Interface_Devices#.22SetProtocol.22_request
And here is the relevant code inside usb_dev.c. You can see that the message seems to be ignored all together. In response to that comment in the code, maybe the other messages fail because 0x0B isn't being handled properly?
Code:
// TODO: this does not work... why?
#if defined(SEREMU_INTERFACE) || defined(KEYBOARD_INTERFACE)
case 0x0921: // HID SET_REPORT
//serial_print(":)\n");
return;
case 0x0A21: // HID SET_IDLE
break;
// case 0xC940:
#endif