fyi
日期: 2026/10/17 11:02
发件人: willowswaving@tutamail.com
发送至: linux-input@vger.kernel.org
主题: [RFC] HID: uclogic: Add support for Xencelabs Pen Display (28bd:520d) and request for switch-to-vendor-mode sequence


> 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
>
> --
>  > https://tuta.com/free-email
>