5" panel unresponsive on Linux despite byte-identical HELLO to working Windows capture

[jepp3103]

Describe the bug

The 5" panel (as used in the Lian Li O11D EVO RGB Lamborghini Edition) stops responding to any serial commands on Linux — both of its known USB identities enumerate correctly and consistently, but the handshake (HELLO) never gets a response, even when sending byte-identical protocol data confirmed via a Wireshark/USBPcap capture of the official Windows driver successfully talking to the same physical device.

This isn't a "never worked" report — it worked correctly for several hours using this exact library before failing, and hasn't recovered since, despite the panel being confirmed fully functional via the official Windows driver in the meantime.

I ran into this while building lambo-dashboard, an independent host-streamed (not on-device-storage) implementation targeting this same panel via LcdCommRevC, in case a second working (until it wasn't) implementation against this exact hardware is useful corroboration.

To Reproduce

1. Connect the panel, confirm clean USB enumeration (see below).
2. Attempt InitializeComm() / raw HELLO handshake.
3. Handshake loop retries indefinitely with Display returned invalid or unsupported ID and never receives a valid chs_... response.

Expected behavior

Handshake should succeed and return chs_5inch.dev1_rom1.89 (confirmed this is the correct/expected response — see below).

Environment:

• Smart screen model: Turing/Turzx 5" (Lian Li O11D EVO RGB Lamborghini Edition rear panel, appears to be OEM Turing 5" hardware)
• Revision of this project: main branch, LcdCommRevC
• OS with version: Nobara Linux 44, kernel 7.1.3-200.nobara.fc44.x86_64
• Python version: Python 3.14.6
• Hardware: AMD Ryzen 9 7950X3D / Radeon 9070 XT

USB identity details

This panel presents as two separate USB devices on the same internal hub, both consistent and reproducible across many reconnects/reboots:

idVendor=1a86, idProduct=ca50, Manufacturer=Turing, Product=UsbMonitor, SerialNumber=CT50INCH
idVendor=1d6b, idProduct=0106, Manufacturer=Android, Product=Android,   SerialNumber=20080411

The second identity (1d6b:0106, serial 20080411) exactly matches what LcdCommRevC._get_awake_com_port() already checks for by VID/PID and serial number — so this isn't an unrelated device, it's a known "awake" identity for this panel family, just not currently documented as applying to the 5" model specifically.

What was tested and ruled out

• Wrong port/identity: raw protocol tests were run directly against both known identities, cross-verified against correct VID:PID, not relying on serial-number matching alone.
• Infinite retry in _hello(): confirmed and worked around locally (original loop has no retry limit at all — worth fixing upstream regardless of this specific bug, as it can hang a caller indefinitely on any transient failure).
• Missing write timeout: added write_timeout to the serial.Serial() connection; didn't change this specific symptom.
• Missing wake sequence: replicated _wake_up_device()'s exact repeated open/close pattern (15x) manually before attempting HELLO — no change.
• Insufficient boot time: waited 35 seconds after a cold USB replug, doing nothing else, before sending HELLO — no change.
• Physical/power issues: full system power cycle (not just USB replug) — no change. Reverted to a known-good build of the calling code from several hours earlier (before the issue started) — same failure, ruling out anything in the calling application.
• Protocol correctness: captured the official Windows driver's traffic via Wireshark + USBPcap. The HELLO command bytes sent are byte-for-byte identical to what this library sends (01 ef 69 00 00 00 01 00 00 00 c5 d3). The official driver's successful handshake response, decoded from the capture, is chs_5inch.dev1_rom1.89.

Key finding from the packet capture

The official driver's actual working HELLO exchange happens over bulk endpoints (0x01 OUT / 0x81 IN) on the 1d6b:0106 ("Android") identity, not the 1a86:ca50 ("Turing"/CT50INCH) identity. Both identities complete standard USB/CDC-ACM enumeration quickly, then the official driver deliberately waits roughly 23-30 seconds before sending any real commands (matched independently in our own 35s-wait test, which still failed on Linux — so this delay alone isn't sufficient by itself, but is present in genuine working sessions).

Despite replicating the exact same bytes, target identity, and generous timing, the device does not respond at all when the same sequence is attempted from Linux (tested against both identities), while the identical byte sequence works correctly moments later/before via the official Windows driver on the same physical hardware, same USB port, same session.

Additional context

This suggests a difference at the USB/kernel driver level between how Windows' USB stack initializes this specific device versus Linux's generic cdc_acm class driver — possibly a vendor-specific SELECT_INTERFACE/pipe-configuration step Windows performs that has no direct Linux equivalent being sent. Happy to provide the full .pcapng capture and/or test further changes against the real hardware if useful — this is a limited-edition case panel so testing turnaround may be slow, but the hardware is available.

Repo for the independent implementation mentioned above, in case the code/README is useful context: https://github.com/jepp3103/lambo-dashboard

[jepp3103]

Found it — this was a bug in my own application code, not this library. Wanted to close the loop for anyone who finds this issue later with a similar symptom.

My code was explicitly targeting the panel's 1a86:ca50 ("sleeping"/CT50INCH) USB identity for the handshake, never the 1d6b:0106 ("awake"/20080411) one. Running main.py from this repo directly against the same hardware was actually what cracked it — auto-detect correctly landed on /dev/ttyACM2 (the 1d6b:0106 identity) and worked immediately, while my own port-selection logic never considered that identity at all. Once I fixed my code to target the same identity _get_awake_com_port() already checks for, everything started working again.

So: no bug here, LcdCommRevC/_get_awake_com_port() was already correctly handling this the whole time — I just hadn't noticed my own code was bypassing it. Sorry for the noise, and thanks for maintaining this — the reverse-engineering work here is what made the whole project possible in the first place.

One thing that might be worth a small documentation note, if useful: _get_awake_com_port()'s check for serial 20080411 / VID:PID 1d6b:0106 applies to the 5" (CT50INCH/chs_5inch) panel too, not just the models auto_detect_com_port()'s wake-trigger logic explicitly names (USB7INCH, CT21INCH). Wasn't obvious going in that the 5" panel used this same "awake identity" mechanism until I traced it through a packet capture — a one-line comment might save someone else the same few hours I spent on it.

Closing this out on my end — feel free to close, or let me know if any of the diagnostic detail above is worth keeping for reference.