Skip to content

Conversation

@dinsfire64
Copy link

Describe the PR
Remove assumption that HID Report descriptor is before HID Endpoint.

Additional context
I have been using tinyusb's HID Host stack in my project and came across a game controller that has an...odd configuration.

Most HID Devices have the HID Report Descriptor preceding the endpoint, however I came across a device that has it following the endpoint.

you can see it in this lsusb call where it tails the endpoint with DEVICE CLASS which is actually the Report type that we need to parse.

[dinsfire@hyrule ~]$ lsusb -d 1ccf:1020 -v

Bus 001 Device 055: ID 1ccf:1020 Konami Amusement DDR MAT controller
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x1ccf Konami Amusement
  idProduct          0x1020 DDR MAT controller
  bcdDevice            4.10
  iManufacturer           1 Konami Amusement
  iProduct                2 DDR MAT controller
  iSerial                 3 BF010
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 [unknown]
      bInterfaceProtocol      0 
      iInterface              1 Konami Amusement
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               4
        DEVICE CLASS:  09 21 11 01 21 01 22 32 00
Device Status:     0x0000
  (Bus Powered)

I noticed that tinyusb's hidh_open has this order hard coded, so I added a small function to seek the descriptor for the HID_DTYPE_HID that we want to parse.

This successfully has the device attached to the hidh stack and I can continue to poll it.

If you are interested the project in question I'm using this in is a gamepad adapter for retro consoles. It's been a fun project!

https://github.com/dinsfire64/snekbox_firmware

Thank you as always for your work and effort, tinyusb has been a blast to implement.

@hathach
Copy link
Owner

hathach commented Nov 19, 2025

seems like lsusb also got confused by the device as well, this device is clearly out of specs. I am ok to add support for it. But the change seems to be more complicated than it should be. Let keep most the code intact, and only change to allow the hid descriptor to either before (as current) or after endpoint descriptor

@dinsfire64
Copy link
Author

So are you imagining changing the original assert into a check TU_ASSERT(HID_DESC_TYPE_HID == desc_hid->bDescriptorType);

if it fails, attempt to flip the order and parse it that way?

Then assert if that fails?

support rare case where hid descriptor is after endpoint descriptor
@hathach
Copy link
Owner

hathach commented Nov 20, 2025

@dinsfire64 I push the update, please try to see if that works for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants