Re: FWD: [RFC] HID: uclogic: Add support for Xencelabs Pen Display (28bd:520d) and request for switch-to-vendor-mode sequence

[willowswaving@tutamail.com]

> Subject: Re: [RFC] HID: uclogic: Add support for Xencelabs Pen Display (28bd:520d) and request for switch-to-vendor-mode sequence
>
> Hello,
>
>
> I am writing to send a friendly ping regarding the support for the Xencelabs Pen Display (28bd:520d). I understand you are very busy, and I just wanted to check if there is any update or if there is any additional information I can provide to help move this forward.
>
>
> The device is still available for testing. I would be happy to try any patches or collect further USB traces if needed.
>
>
> Thank you for your time.
>
>
> Best regards,
>
> Willows
>
> 2026/10/18 17:13 来自 willowswaving@tutamail.com:
>
>>> Hello,
>>>
>>> I would like to report a missing device support in the hid-uclogic
>>> driver, and ask for guidance on how to properly add it.
>>>
>>> Device information
>>> ------------------
>>>   Name:       Xencelabs Pen Display
>>>   Vendor ID:  0x28bd (Hanvon Ugee / XP-Pen)
>>>   Product ID: 0x520d
>>>   Firmware:   20250121(230322)
>>>   Model:      UG902_LPH2412_P10
>>>
>>> Problem
>>> -------
>>> The device is not handled by hid-uclogic. With hid-generic, the device
>>> is registered only as a mouse and no pen events (ABS_X, ABS_Y,
>>> ABS_PRESSURE, ABS_TILT) are reported to userspace.
>>>
>>> When I add the device ID to hid-uclogic-core.c, the driver binds, but
>>> the resulting interface is still a mouse. evtest shows no pen events.
>>> This suggests the device is still in "firmware mode" and never gets
>>> switched into the vendor reporting mode that exposes the pen interface.
>>>
>>> Key observations from testing
>>> -----------------------------
>>> 1. lsusb reports only one interface (bNumInterfaces = 1, interface 0,
>>>    HID class, mouse). It has only two interrupt endpoints:
>>>      - 0x81 (IN, 64 bytes)
>>>      - 0x01 (OUT, 64 bytes)
>>>    Note: There is NO endpoint 0x03, which is the endpoint used by
>>>    uclogic_ugee_v2_probe_endpoint in hid-uclogic-params.c. Any attempt
>>>    to send magic bytes to 0x03 fails with "Invalid endpoint address".
>>>
>>> 2. Reading the string descriptor at index 0x64 under LANGID 0x0409
>>>    successfully returns a 14-byte binary blob (13 bytes of content).
>>>    Raw HEX: 0e03289a78e60300ff1fd8130100
>>>    (Other indexes return normal strings like the serial number and
>>>    "hanvon ugee Tech"). Reading index 0x64 does NOT switch the device.
>>>
>>> 3. Sending the UGEE v2 magic bytes (02 b0 04 00 00 00 00 00 00 00)
>>>    via SET_REPORT (Feature 0x02, Output 0x02, Feature 0x03) returns
>>>    success, but the device never re-enumerates.
>>>
>>> 4. A vendor-specific control request (bRequest 0xb0, wValue 0x0402)
>>>    times out.
>>>
>>> 5. Note: Sending unexpected control transfers to this device can cause
>>>    the USB HID interface to hang. It requires a complete power cycle
>>>    (unplugging USB and power) to recover.
>>>
>>> Request
>>> -------
>>> Could someone with access to the Xencelabs USB documentation, or
>>> someone who has reverse-engineered the 520d, share the correct
>>> sequence to switch this device into vendor mode?
>>>
>>> Specifically:
>>>   - Is the 0x64 string descriptor read the right trigger, or is a
>>>     specific control transfer required?
>>>   - If a control transfer is needed, what is the correct bRequest,
>>>     wValue, wIndex, and endpoint?
>>>   - Are there known quirks for this device?
>>>
>>> If a capture from the Windows driver is needed, I can provide one.
>>> If you have any hints, I will be happy to prepare a proper patch
>>> with hid-uclogic-params.c changes and re-test.
>>>
>>> I am attaching the text files with:
>>>   - lsusb -v output for 28bd:520d
>>>   - the raw HID report descriptor (usbhid-dump)
>>>   - the string descriptor enumeration (showing 0x64)
>>>   - dmesg logs showing the binding behavior.
>>>
>>> Thank you very much for your time.
>>>
>>> Best regards,
>>> Willows
>>>