setting keyboard led error

[qingliyu]

Operating System

Windows 7

Board

nrf52840

Firmware

\tinyusb\examples\device\hid_boot_interface\src\main.c

What happened ?

Execution fails forever on \tinyusb\examples\device\hid_boot_interface\src\main.c：line 216. report_type is always equal to 0

How to reproduce ?

empty

Debug Log

No response

Screenshots

No response

[hathach]

could you provide

• how you test and steps to reproduce the issue
• the debug log with LOG=3 around the time the incident occur.

[qingliyu]

I made the above changes. The source code cannot set the led correctly

[qingliyu]

@hathach

[dhalbert]

@hathach I myself was a bit confused elsewhere by HID_REPORT_TYPE_INVALID sometimes meaning: "there's a report id a at the front, remove it and try again."

[hathach]

@qingliyu you didn't provide answer to my 2 questions above, especially how do you reproduce the issue.

@dhalbert yeah, it is what it means at current state of the device stack when receiving report via OUT interrupt endpoint. device stack doesn't attempt to parse the report descriptor, and have no idea if report ID is present or not. Therefore, it will present the SET report as it is with report id as 1st byte. When receiving report via control endpoints, the report id and type is explicitly specified by host in the setup packet and can be presented to the app. I will do more testing with OUT interrupt endpoint later on and see if I could fit a simple parser to detect report id to device stack later on.

[qingliyu]

@hathach 新建文件夹.zip reproduce ：Press num after USB is connected normally。 “report_type == HID_REPORT_TYPE_OUTPUT”(tusb_main.c：221) never succeed。 Use “report_type == HID_REPORT_TYPE_INVALID”(tusb_main.c：222) ."kbd_leds = %02X\n" can be output normally.

[hathach]

@qingliyu I see you didn't use the hid_boot_interface as it is, but a custom firmware. It is what confuse me, please make sure you specify it exactly as it is in the bug report. The reason for HID_REPORT_TYPE_INVALID, is lacking of hid parser as mentioned above. For now when encounter this, you need to process the data as how you specify it in the report descriptor i.e read the first byte as report ID if you use report ID for output report. I will try to implement an simple hid parser later on to resolve this.

it is what it means at current state of the device stack when receiving report via OUT interrupt endpoint. device stack doesn't attempt to parse the report descriptor, and have no idea if report ID is present or not. Therefore, it will present the SET report as it is with report id as 1st byte. When receiving report via control endpoints, the report id and type is explicitly specified by host in the setup packet and can be presented to the app. I will do more testing with OUT interrupt endpoint later on and see if I could fit a simple parser to detect report id to device stack later on.

[qingliyu]

@hathach I seem to understand what you mean．Using TUD_HID_DESCRIPTOR, the ｐｃ will use the control endpoint to transmit. Using TUD_HID_INOUT_DESCRIPTOR, the ｐｃ will use the ＯＵＴ interrupt　endpoint for transmission．

[hathach]

@hathach I seem to understand what you mean．Using TUD_HID_DESCRIPTOR, the ｐｃ will use the control endpoint to transmit. Using TUD_HID_INOUT_DESCRIPTOR, the ｐｃ will use the ＯＵＴ interrupt　endpoint for transmission．

Yeah, it is the case, the device stack does not include an hid parser for now. I will reopen this as reminder to write the parser later on.

[dhalbert]

An alternative to parsing the HID report descriptor is to ask the caller to pass the information that would be retrieved from the parsing. We do this in CircuitPython, passing in the report IDs and the report lengths: https://docs.circuitpython.org/en/latest/shared-bindings/usb_hid/index.html#usb_hid.Device.

An HID report descriptor parser is useful for other things too, especially host support, so this may not be the best choice in the long run. But it saved writing a parser, especially because we didn't have the code space for it on the smallest CircuitPython builds.