HID keyboard/mouse that only supports boot protocol?

[vvuk]

I have a device (random no-name 2.4ghz keyboard/mouse combo receiver) which seems to only support the BOOT protocol. The initial protocol shows up as BOOT. If I try to switch to HID_REPORT_PROTOCOL, the usb stack hangs somewhere. Turning on debugging, I get assertion failures on the tuh_control_xfer call.

This is with somewhat hacked logging (I'm running both device and host; device on rp2040 main usb, and host on Pico-PIO-USB port on core 2); so I attempted to enable logging for the host-side stack only.

(usb:1) HID device address = 1, instance = 0 is mounted
(usb:1) HID has 1 reports
(usb:1)   Report 0: id=0, usage_page=0x1, usage=0x6
(usb:1) HID using boot protocol, sub-protocol = Keyboard (1)
(usb:1) Switching to HID_REPORT_PROTOCOL  [I call set_protocol right after this]
[1:1] Class Request:
  Queue EP 81 with 8 bytes ... OK
HID set config: itf = 1
_hidh_set_idle 244: ASSERT FAILED
on EP 00 with 8 bytes
on EP 80 with 0 bytes

(usb:1) HID Set Protocol Complete 1:0 1    [this is from my set protocol complete callback func]

Note that if I don't try to set_protocol, I get device instance 1 right after this (my log below). I need to set up a picoprobe/SWD debugger to see what's actually happening above. At the very least I don't get another tuh_hid_mount_cb.

(usb:1) HID device address = 1, instance = 0 is mounted
(usb:1) HID has 1 reports
(usb:1)   Report 0: id=0, usage_page=0x1, usage=0x6
(usb:1) HID using boot protocol, sub-protocol = Keyboard (1)
(usb:1) HID device address = 1, instance = 1 is mounted
(usb:1) HID has 4 reports
(usb:1)   Report 0: id=1, usage_page=0x1, usage=0x2
(usb:1)   Report 1: id=3, usage_page=0xc, usage=0x1
(usb:1)   Report 2: id=2, usage_page=0x1, usage=0x80
(usb:1)   Report 3: id=5, usage_page=0xf1f2, usage=0xf2
(usb:1) HID using boot protocol, sub-protocol = Mouse (2)

Is there some way of detecting that the device doesn't support the report protocol, if that's what's actually happening here?

[vvuk]

Hm maybe that's not it. I just tried a logitech unifying receiver with a paired keyboard; I have to believe this supports the report protocol. Same error with the assertion failure in _hidh_set_idle, at the tu_control_xfer. (Also typo in hid_host.c: CONFG_SET_IDLE)

[vvuk]

Ah. I should not be calling tuh_hid_set_protocol from inside the mount_cb.

[bstrobel]

I came across the same issue recently. So where/when do you call tuh_hid_set_protocol? To me the mount_cb would be the natural place...

[vvuk]

Somewhere outside of a TinyUSB callback. Within the mount_cb you're still in the middle of the device being enumerated (I believe, or something similar). From outside of a callback you can actually initiate a usb transaction, such as asking a device to change the protocol. (I think, again; someone correct me if I'm wrong :) )

[bstrobel]

Thanks for the answer. I investigated this in the meantime and found out how to supposedly do it. Just initialize tinyusb like this:

tuh_hid_set_default_protocol(HID_PROTOCOL_REPORT);
tusb_init();

I could confirm that this works using a LA. Unfortunately it didn't help me with my buggy keyboard problem. Still I think this should be documented somewhere...