2.8" round USB screen (rebranded by SAMA) not detected: different VID/PID (1a86:ca21)

[javierarendsve-cloud]

Title

2.8" round USB screen (rebranded by SAMA) not detected: different VID/PID (1a86:ca21) than the one hardcoded for this model (1cbe:0028)

Description

I have a SAMA AIO liquid cooler with an integrated 2.8" round LCD screen. The device identifies itself to the OS as "Turing" / "UsbMonitor", so I assumed it matched the recently added "2.8" round (V1.X new HW rev.)" support from PR #995.

However, after selecting this screen size in configure.py and running main.py, I always get:

Import error: USB device not found

Investigation

I checked library/lcd/lcd_comm_turing_usb.py and found:

VENDOR_ID = 0x1cbe
PRODUCT_ID = {0x0028: (480, 480),  # Turing 2.8" round (USB)

But my actual device, confirmed via lsusb -v, reports:

Bus 001 Device 007: ID 1a86:ca21 QinHeng Electronics UsbMonitor
  idVendor           0x1a86 QinHeng Electronics
  idProduct          0xca21 UsbMonitor
  iManufacturer      1 Turing
  iProduct           2 UsbMonitor
  iSerial            3 CT21INCH
  bDeviceClass       2 Communications
  bNumConfigurations 1
  bNumInterfaces     2
  MaxPower           500mA

So it seems there are (at least) two different hardware variants of the "2.8" round" screen circulating, using different USB controller chips:

• 1cbe:0028 — currently supported by this project
• 1a86:ca21 (QinHeng) — my device, reported by SAMA AIO coolers, NOT currently supported

Environment

• OS: Fedora Linux 44 (KDE Plasma)
• Kernel: 6.19.10-300.fc44.x86_64
• Python: 3.14
• turing-smart-screen-python version: commit a3a375d (main, includes PR Add support for 2.8" round TURZX USB display (PID 0x0028) #995)
• Hardware: SAMA AIO liquid cooler with integrated 2.8" round LCD (sold under SAMA branding, screen itself reports manufacturer "Turing", serial "CT21INCH")

Additional note

I also found and fixed a small unrelated bug while testing: in configure.py, SIZE_2_8_INCH_NEWREV is defined on line 80, but the code further down referenced it as SIZE_2_8_ROUND_USB (an apparent leftover from a rename), causing a NameError on startup. I fixed this locally with sed -i 's/SIZE_2_8_ROUND_USB/SIZE_2_8_INCH_NEWREV/g' configure.py to get past that step. Happy to confirm if this needs a separate issue.

Windows confirmation

The screen works perfectly on Windows using TURZX v3.1.0 (the official Windows software for this type of screen). This confirms that:

1. The hardware is fully functional and genuine Turing/TURZX compatible hardware
2. A working communication protocol with chip 1a86:ca21 exists — it is implemented in TURZX v3.1.0 for Windows
3. This is purely a missing implementation on the Linux side, not a hardware limitation

This also means that if someone wanted to add support, capturing USB traffic with Wireshark + USBPcap on Windows while TURZX v3.1.0 communicates with the screen would be a viable path to reverse-engineer the protocol for the QinHeng chip.

Further testing — manually adding VID/PID

To go further, I manually patched lcd_comm_turing_usb.py to add my device:

VENDOR_ID = 0x1a86
PRODUCT_ID = {0xca21: (480, 480),  # SAMA/Turing 2.8" round (QinHeng USB)
    0x0028: (480, 480),  # Turing 2.8" round (USB)

After this change, running sudo python3 main.py produced a different result — the device was now found, but failed with:

Warning: set_configuration() failed: [Errno 16] Resource busy
AssertionError: Could not find USB endpoints

The kernel also confirms the device is detected correctly:

[ 7.805627] usb 1-10.2: New USB device found, idVendor=1a86, idProduct=ca21, bcdDevice=1.00
[ 7.805639] usb 1-10.2: Product: UsbMonitor

This confirms that:

1. The device IS detected by Linux and by the program when the correct VID/PID is added
2. The failure is at the USB endpoint level — the QinHeng chip (1a86:ca21) has a different internal USB structure than the 1cbe:0028 chip currently supported
3. A specific protocol implementation for the QinHeng chip is needed — not just a VID/PID addition

Request

Could support for VID 0x1a86 / PID 0xca21 be added with its own protocol implementation? The device is detected by Linux, works perfectly on Windows with TURZX v3.1.0, and has a 480x480 resolution. I'm happy to capture USB traffic with Wireshark + USBPcap on Windows while TURZX v3.1.0 is running, run any test scripts, or provide any other debug info needed to implement support for this QinHeng variant.