D200: HID keyboard interface stops responding to LED Output Reports

highlow

I am reporting a reproducible firmware-level issue with my D200 on macOS.
I have spent several hours isolating this problem with macOS kernel logs, ioreg, and hidutil, and I have strong evidence that the root cause is inside the device firmware.
I would like this escalated to your firmware engineering team.

Environment

- Host OS: macOS 26.4.1 Apple Silicon
- USB port: Connected to Mac Studio front USB-C port
- Ulanzi Studio version: v3.0.16
- D200 firmware: 2.0.3

Device identification (from ioreg -p IOUSB)

- USB Vendor ID: 0x2207 (rockchip)
- USB Product ID: 0x0019 (25)
- USB Serial Number: b05ce5483a5058bf
- USB Product Name string: empty (iProduct index is set but string descriptor returns nothing)
- bcdDevice: 0x0310 (784)
- Exposes a Boot Keyboard HID interface (UsagePage 0x01 / Usage 0x06) with standard LED Output Report (Caps Lock / Num Lock / Scroll Lock) plus a vendor-specific interface maybe used by the Ulanzi Studio.

Symptom

The HID keyboard interface occasionally freezes for ~5 seconds at random intervals (several times per hour). During the freeze, input through the Deck is unresponsive.
Other USB devices on the same bus (including USB mass storage) remain fully operational, which indicates the USB bus itself is healthy and the problem is confined to this device's HID endpoint.

Root cause

The device's Boot Keyboard interface does not acknowledge HID LED Output Reports (Report ID 0 with 1-byte payload for keyboard LEDs). macOS sends this report every time any keyboard LED state changes on the system (e.g., CapsLock toggled on any keyboard) as well as periodically for LED re-synchronization.
Because the device never returns an acknowledgement or a STALL, each request blocks the HID driver's command pipeline for the full IOKit timeout window (5 seconds) before failing with kIOReturnTimeout (0xe00002d6).
The device's internal counters confirm this is not a rare edge case but the normal behavior of the firmware:


  ioreg -rn AppleUserUSBHostHIDDevice:
    SetReportCount        = 55
    SetReportTimeoutCount = 52      ← 52 of 55 SetReports timed out (~95%)

Representative log entries from log show (macOS unified log):


  02:28:06.115  kernel: [AppleUserHIDEventDriver] Set LED 0x2: 0 0x0     (other keyboards — success)
  02:28:06.119  kernel: [IOUserUSBHostHIDDevice][0x1000012f0] Add element to action array: 52        ← D200: LED Output Report queued here, 02:28:06
  02:28:11.120  kernel: (IOHIDFamily) AppleUserUSBHostHIDDevice:0x1000012f0 ProcessReport: 0xe00002d6   1 0
  02:28:11.120  kernel: (IOHIDFamily) updateElementValues failed: 0xe00002d6
  02:28:11.120  kernel: (IOHIDFamily) postElementValues: 0xe00002d6
  02:28:11.120  kernel: [IOHIDInterface:0x100001348] SetElementValues failed: 0xe00002d6
  02:28:11.120  kernel: [IOHIDElementPrivate.cpp:1718] commit failed (244 1): 0xe00002d6
  02:28:11.120  kernel: [AppleUserHIDEventDriver] Set LED 0x2: 0 0xe00002d6      ← exactly 5 seconds after submission → kIOReturnTimeout

The 5-second gap between the request (02:28:06.119) and the failure (02:28:11.120) is precisely the IOKit default transaction timeout, which confirms the device simply never answers the SetReport.
This pattern repeats on its own without user interaction. Example (LED resync events over 1 hour):

- 05:13:25 → 05:13:30
- 05:37:14 → 05:37:19
- 05:56:04 → 05:56:09
- 06:15:44 → 06:15:49

Why other USB devices are unaffected:
Only this HID interface is stuck. While the firmware holds the 5-second timeout window, the HID driver's serial command queue for this device is blocked, which is why keyboard-side input appears frozen. Other USB devices are completely unrelated and continue working.

Reproduction (trivial)

1. Plug in the D200 on macOS.
2. Toggle CapsLock on any connected keyboard, or simply leave the machine running.
3. Watch ioreg -rn AppleUserUSBHostHIDDevice | grep SetReportTimeoutCount — the counter increments continuously.
4. Also visible in the macOS unified log with the predicate:
  eventMessage contains "0xe00002d6" or eventMessage contains "AppleUserUSBHostHIDDevice"

Requested firmware fixes

1. The keyboard interface must acknowledge SetReport (Output Report) on endpoint 0 — even if the device does not physically have LEDs, the firmware must complete the USB control/interrupt transfer (either ACK the write or return STALL) so that the host driver does not block for 5 seconds per request.
2. D200 has no LEDs, please consider removing the LED Output Report entry from the HID Report Descriptor. This would prevent macOS from attempting LED synchronization to this device at all.

Ulanzi

Hello, thank you for your detailed feedback and the troubleshooting steps you provided. We have forwarded this to our R&D team, and we are confident that improvements will be made in the future.