Correct usage of tuh_hid_set_protocol()?

[borb]

(before I write: I love TinyUSB, thank you so much to all involved for the hard work going into this project)

I've been working on handling a mouse in report (not hid boot protocol) mode. I've had a lot of success, parsing the report descriptor block, and to an extent, getting to the point where I should be able to receive a non-boot proto report back to the RP2040 I'm running this on.

I should note: Using tuh_hid_set_default_protocol() with HID_PROTOCOL_REPORT works for me, but I do not want every device to be in report mode (indeed, keyboards I'd like to remain in boot proto until I've written sufficient handling routines to handle this).

I'd really appreciate any guidance on what I'm doing wrong since this is proving to stretch the limit of what I understand.

Problem 1: Cannot specifically put one instance into HID_PROTOCOL_REPORT

After tuh_hid_mount_cb() has finished, I run tuh_hid_set_protocol() on the device/instance pair with HID_PROTOCOL_REPORT. I should note at this point that the boolean response to tuh_hid_set_protocol() is false, so I assume a failure has occurred. If I run set protocol inside the mount callback, it returns true, so I assume it has succeeded (evidence proves otherwise, as below). I gather set protocol in the mount callback is unwise, so I'm trying to do it outside.

Indeed, with set protocol outside of mount callback, and response false, I'm still getting hid boot format responses. With set protocol inside mount callback and response true, the report response is invalid and fails to correctly parse.

I want to avoid, if possible, using tuh_hid_set_default_protocol() to HID_PROTOCOL_REPORT, especially since I haven't confirmed I can parse the report descriptor and, indeed, if the device is of a classification I want to switch into report mode (I do not currently want keyboards in report mode).

Problem 2: Additional instance appears after tuh_hid_set_protocol(), whether it succeeds or fails

Now, the next part is confusing me further.

I have a Dell mouse/keyboard combination (vid 413c, pid 301c), and when I plug it in the table of devices is as follows:

dev_addr	instance	protocol	description
1	0	1	keyboard
1	1	2	mouse

After running tuh_hid_set_protocol() on instance 1 (the mouse instance), a new device is processed by the mount callback, and address 1 instance 2 comes up with protocol 0 (HID_ITF_PROTOCOL_NONE). Hence the table now appears as:

dev_addr	instance	protocol	description
1	0	1	keyboard
1	1	2	mouse
1	2	0	none

I find this quite unusual. Furthermore, in spite of this new device appearing, the mouse reports are still coming from instance 1 (the mouse). This is obviously expected but what is the function of instance 2?

[braxlan]

Hi,

I am a beginner, and as such I might mess up all the terms.

Maybe you could try this for problem 1, at least for me it helped:

• Call tuh_hid_set_protocol() in tuh_mount_cb() and not in/after tuh_hid_mount_cb() (note the small difference!) because the device might still be busy and mounting the device has not finished yet
• Make a loop to check if tuh_hid_set_protocol() returned true and if not, try on next loop
• You can only be sure setting the mouse to report protocol has succeeded when tuh_hid_set_protocol_complete_cb() has been called by the stack

Problem 2 might arise because the device has not finished enumerating all the interfaces when you call tuh_hid_set_protocol() (see above). To me it looks like instance 2 is for special keys like media keys etc. Maybe take a look at the HID host examples (esp. /examples/host/cdc_msc_hid/src/hid_app.c) to find out more about this kind of instances. Most keyboards have two instances instead of one, and if is a keyboard/mouse combo, this seems to apply too for the keyboard part.

Hope that helps.