Drive a TURZX USB display yourself

What this is about

The TURZX displays (identical to "Turing Smart Screen", USB vendor ID 0x1CBE) are slim IPS screens that get power and picture over USB-C and are meant as PC status displays. The vendor software is Windows-only. If you want to hang the display off a Raspberry Pi, a Linux server or a Mac, you have to speak the protocol yourself. It is simple: a 500-byte command header, DES-encrypted with a fixed key, followed by a JPEG. The details are below, including the five things that are guaranteed to go wrong on the first attempt.

All of this is verified on the 9.2" model (1920×462, product ID 0x0092), which has been running as a dashboard on a Pi 5 for months. For the sibling models (4.6", 5.2", 8", 8.8", 12.3") the turing-smart-screen-python library uses the same protocol; only the resolution differs.

Quick start on Linux / Raspberry Pi

# 1. Check that the display is detected
lsusb | grep 1cbe
#   Bus 002 Device 002: ID 1cbe:0092 Luminary Micro Inc. TURZX1.0

# 2. Access without root: udev rule, then re-plug the cable
sudo curl -o /etc/udev/rules.d/99-turzx.rules https://bergclimber.de/turzx/dl/99-turzx.rules
sudo udevadm control --reload-rules && sudo udevadm trigger

# 3. Dependencies and script
pip3 install pyusb pillow pycryptodome          # Debian/RPi OS may need --break-system-packages
curl -o turzx.py https://bergclimber.de/turzx/dl/turzx.py

# 4. Test pattern
python3 turzx.py --brightness 40 test
python3 turzx.py image photo.jpg
python3 turzx.py text "Hello\nWorld"

On a Mac, brew install libusb before the pip step is enough; there is no udev there. On Windows, pyusb needs a WinUSB driver for the device (Zadig), but that is not the path this page is written for.

The five traps

If it still looks odd

• Factory background shows through: init sequence missing or PNG instead of JPEG. Restart the service, unplug the cable if needed.
• Image stacked four times: command 41 was sent with parameters (e.g. MADCTL). 41 must go out without parameters.
• "Resource busy": another process holds the USB interface. Stop the old instance, wait a moment.
• Nothing at all: try another cable or port; some USB-C cables carry power only. The display draws up to 1.6 W.

The Python script

turzx.py is a single script with no configuration: it detects the model via the product ID, pads and rotates the image accordingly and speaks only the five init commands, brightness and JPEG upload. Dependencies: pyusb, pillow, pycryptodome. Playwright only for the web page mode.

turzx.py test                           test pattern
turzx.py image photo.jpg [--fit contain] image (default: fill and crop)
turzx.py text "line 1\nline 2"           text card
turzx.py clear                          black
turzx.py brightness 40                  brightness 0–100
turzx.py url http://localhost:3000/     web page as screenshot loop, --interval 2
                                        (pip3 install playwright && playwright install chromium)

As a service (dashboard use)

For a dashboard, the url mode renders any web page in headless Chromium and pushes a screenshot to the display every two seconds. A Pi 5 is practically idle doing this (screenshot ~0.3 s, USB ~0.2 s, ~30 MB RAM). Example unit: turzx.service, udev rule: 99-turzx.rules.

sudo mkdir -p /opt/turzx && sudo cp turzx.py /opt/turzx/
sudo curl -o /etc/systemd/system/turzx.service https://bergclimber.de/turzx/dl/turzx.service
sudo nano /etc/systemd/system/turzx.service      # adjust User= and URL
sudo systemctl daemon-reload && sudo systemctl enable --now turzx
journalctl -u turzx -f

Two lessons from continuous operation: do not load the page with wait_until="networkidle" if the page polls on its own (the loop then hangs in timeouts; we had a display frozen for twelve hours). And do not reload per frame, only take screenshots; a reload every few minutes as hygiene is enough. For full robustness, give the service a systemd watchdog.

Protocol reference

Plain USB bulk on interface 0, one OUT and one IN endpoint. Every command is a 512-byte packet; for images the JPEG payload follows in the same transfer. The display answers with 512 bytes, byte 1 or byte 8 = 0xC8 (200) means OK; you can read and discard the reply.

Packet layout

Plaintext header, 500 bytes, zero-filled:
  [0]      command ID
  [2..3]   magic 0x1A 0x6D
  [4..7]   timestamp: milliseconds since local midnight, little-endian
  [8..11]  only for 101/102: payload size, big-endian
  [8]      only for 14: brightness 0–102

→ DES-CBC encrypt, key = IV = "slv3tuzx" (zero padding to 504 bytes)
→ place in 512 bytes, bytes 510/511 = 0xA1 0x1A
→ then for 101: append the raw JPEG bytes

Commands

Init sequence and image pipeline

Connect:  10 → 111 → 112 → 13 → 14 (brightness) → 41 → black JPEG

Image (9.2"): landscape 1920×462
  → pad to 1920×464 (1 px black top and bottom)
  → rotate 90° clockwise (PIL ROTATE_270) → 464×1920
  → JPEG, quality 90, typically 70–150 KB
  → header 101 with size + JPEG in one bulk write

Models (vendor ID 0x1CBE)

Source of the protocol knowledge: my own captures plus the library turing-smart-screen-python (GPL-3.0), which now supports these models as "Turing USB" and additionally does H.264 video, file storage and the factory theme. If you want the full monitoring program, use the library. If you just want an image or a web page on the display, the eight commands above are all you need.

Frequently asked questions