D92 (upHere D92 / MiraBox D92)

A 9.2-inch 1920x462 bar display, sold as the upHere D92 and the MiraBox D92. Driver: crates/drivers/d92, driver id d92.

The facts below were found by experiments with hidapi on macOS and by capturing the vendor app (“MiraBox Craft”, Windows) with the VMware Fusion USB analyzer. Items marked unverified are assumptions.

USB


Vendor:Product	`2100:0006`
Product string	`HOTSPOTEKUSB HID DEMO`
Interface	HID, usage page `0xFFA0`
Endpoints	Interrupt IN `0x82` (512 bytes), Interrupt OUT `0x01` (1024 bytes)
Version	`GET_REPORT` (input, report 0) returns e.g. `V25.upHere_gamingD92.02.014`

It is not a TURZX device: the TURZX protocol (USB 1CBE:0092) does not work on it.

No root or driver installation is needed on macOS and Windows (the built-in HID driver is used). On Linux, install the udev rule from contrib/linux to use the display without root.

Reports

Every output report is 1024 bytes (report ID 0, zero-padded). Commands start with CRT\0\0 followed by a command word. The device never answers: there are no ACKs, so the host has to pace itself.

Command	Bytes after `CRT\0\0`	Effect
Wake	`DIS`	Screen on
Sleep	`HAN`	Screen off
Brightness	`LIG` `00 00` `<percent>`	Backlight 0–100 %
Keep-alive	`CONNECT`	Keeps the session open (see below)
Clear	`CLE` `00 00` `DC`	Blanks the screen (black) and ends the session; sent by the vendor app on exit
Live frame	`DRA` …	Shows a JPEG now; not stored
Stored image	`LOG` … then `STP`	Shows a JPEG and stores it in flash

Live frame (`DRA`)

This is the path for animation. It is not stored: after a restart the device shows the last stored image again.

report 1:  43 52 54 00 00 44 52 41  "CRT\0\0DRA"
           [8..12]  u32 big-endian: 32 + JPEG length   (the 32-byte header counts!)
           [12]     0xB1
           [13..32] zero
           [32..]   the JPEG starts here
reports 2…: the rest of the JPEG, raw (no prefix); the last report is zero-padded

If the length field holds only the JPEG length, the device silently drops the frame. Smooth at 60 fps on macOS (~15 ms to send a 30 KB frame); the vendor app streams at ~16 fps.

Stored image (`LOG` + `STP`)

report 1:   "CRT\0\0LOG", [8..12] u32 big-endian JPEG length, [12] mode
reports 2…: the JPEG, raw, last report zero-padded
last:       "CRT\0\0STP"

Mode	Meaning
`0x02`	Show and keep across power cycles (used by `save` / `--persist`)
`0x01`	Becomes the boot logo. Overwrites the factory logo; the driver never uses it

The device needs about 1.5 s per stored image (it writes flash). Frames sent during that time are lost, so the driver waits before sending the next image. Avoid storing frequently.

Image format

462x1920 baseline JPEG: the landscape 1920x462 picture turned 90° clockwise. A 1920x462 JPEG is shown rotated.
4:2:0 chroma subsampling works. Very low quality JPEGs with 16-bit quantization tables are rejected.
The vendor app warns above 512 KiB; the driver rejects larger images.

Session and keep-alive

Without CONNECT for about 8 s, the device restarts itself (it disappears from USB for ~3 s) and shows the last stored image. The driver sends CONNECT every 2 s.
After HAN the screen stays dark even while DRA frames keep arriving (checked with one frame per second for 12 s); DIS switches it back on. So the daemon keeps content running while the screen is off.
After CLE DC the session is over and the device does not restart. The driver sends DIS before the next image. (unverified whether DIS is required)
On open the vendor app sends GET_REPORT (version), DIS, LIG 50, then DRA frames. The driver does the same without changing the brightness.
An idle device sends a 2-byte 00 00 input report every 3 s. macOS drops such short reports, so they are not used.

Dangerous commands

CRT\0\0SCREEN\0 (the vendor app’s “extended screen” mode): afterwards DRA and LOG are ignored and the auto-restart stops. Nothing sent over USB recovered it; only a physical replug did. The driver has a test that it never sends SCREEN.
LOG mode 0x01 replaces the boot logo permanently.
Commands from the vendor SDK that showed nothing on this firmware: BGPIC, BAT, and DRA with the SDK’s image count/size fields instead of 0xB1.

Tested platforms

Checked with ssp selftest (all checks pass) on 2026-10-08. Linux and Windows ran in VMware Fusion VMs on an Apple Silicon Mac, with the D92 passed through over USB.

Platform	Connection	Streaming
macOS 27 (Apple Silicon)	direct	52–55 fps
Ubuntu 24.04 (ARM64)	VM, USB pass-through	~58 fps
Windows 11 (ARM64, build 26300)	VM, USB pass-through	17–51 fps (varies with the VM’s load)
Linux / Windows on x86_64		not tried yet

The firmware version is read on all three.

Driver capabilities

Capability	Value
Panel	1920x462, rotated 90° clockwise on the wire, JPEG
Live frames / stored images	yes / yes
Brightness / power / clear	yes / yes / yes
`max_fps`	60
`keep_alive_interval`	2 s
`max_image_bytes`	512 KiB