D92（upHere D92 / MiraBox D92）

9.2 インチ・1920x462 のバー型ディスプレイで、upHere D92 と MiraBox D92 の名前で販売されています。ドライバは crates/drivers/d92、ドライバ ID は d92 です。

以下の内容は、macOS 上での hidapi を使った実験と、メーカー製アプリ（Windows 版「MiraBox Craft」）の通信を VMware Fusion の USB アナライザでキャプチャして得たものです。未確認 と書いた項目は推測です。

USB


ベンダー:プロダクト	`2100:0006`
製品名文字列	`HOTSPOTEKUSB HID DEMO`
インターフェース	HID、usage page `0xFFA0`
エンドポイント	Interrupt IN `0x82`（512 バイト）、Interrupt OUT `0x01`（1024 バイト）
バージョン	`GET_REPORT`（input、report 0）で `V25.upHere_gamingD92.02.014` のような文字列が返ります

TURZX のデバイスではありません。TURZX のプロトコル（USB 1CBE:0092）は使えません。

macOS と Windows では、root 権限もドライバのインストールも不要です（OS 標準の HID ドライバを使います）。 Linux では、root なしで使うために contrib/linux の udev ルールを入れてください。

レポート

出力レポートはすべて 1024 バイトです（report ID 0、余りはゼロ埋め）。コマンドは CRT\0\0 に続けてコマンド語を置きます。デバイスは一切応答しません。ACK がないので、送信のペースはホスト側で管理する必要があります。

コマンド	`CRT\0\0` の後のバイト列	効果
点灯	`DIS`	画面をオン
消灯	`HAN`	画面をオフ
明るさ	`LIG` `00 00` `<パーセント>`	バックライト 0〜100 %
キープアライブ	`CONNECT`	セッションを維持（後述）
消去	`CLE` `00 00` `DC`	画面を黒にしてセッションを終了。メーカー製アプリが終了時に送ります
ライブフレーム	`DRA` …	JPEG をすぐに表示。保存はされません
保存画像	`LOG` … のあと `STP`	JPEG を表示し、フラッシュに保存します

ライブフレーム（`DRA`）

アニメーション用の経路です。保存されないため、デバイスが再起動すると最後に保存された画像に戻ります。

レポート1:  43 52 54 00 00 44 52 41  "CRT\0\0DRA"
            [8..12]  u32 ビッグエンディアン: 32 + JPEG の長さ   （32 バイトのヘッダーも含める！）
            [12]     0xB1
            [13..32] ゼロ
            [32..]   ここから JPEG が始まる
レポート2〜: JPEG の続き。プレフィックスなしでそのまま並べ、最後のレポートはゼロ埋め

長さのフィールドに JPEG の長さだけを入れると、デバイスはそのフレームを黙って捨てます。 macOS では 60fps で滑らかに表示できます（30 KB のフレームの送信に約 15 ms）。メーカー製アプリは約 16fps で送っています。

保存画像（`LOG` + `STP`）

レポート1:   "CRT\0\0LOG"、[8..12] u32 ビッグエンディアンの JPEG の長さ、[12] モード
レポート2〜: JPEG をそのまま並べる。最後のレポートはゼロ埋め
最後:        "CRT\0\0STP"

モード	意味
`0x02`	表示し、電源を切っても残す（`save` / `--persist` で使用）
`0x01`	起動ロゴになります。工場出荷時のロゴを上書きするため、ドライバでは使いません

保存には 1 枚あたり約 1.5 秒かかります（フラッシュへの書き込み）。その間に送ったフレームは失われるため、ドライバは次の画像を送る前に待ちます。頻繁に保存するのは避けてください。

画像形式

462x1920 のベースライン JPEG。横長 1920x462 の絵を時計回りに 90° 回転したものです。1920x462 の JPEG を送ると、回転した状態で表示されます。
4:2:0 の色差サブサンプリングで表示できます。量子化テーブルが 16 ビットになるほど品質の低い JPEG は受け付けません。
メーカー製アプリは 512 KiB を超えると警告を出します。ドライバはそれより大きい画像を拒否します。

セッションとキープアライブ

CONNECT が約 8 秒途切れると、デバイスは自分で再起動し（約 3 秒間 USB から消えます）、最後に保存された画像を表示します。ドライバは 2 秒ごとに CONNECT を送ります。
HAN で消灯した後は、DRA フレームが届き続けても画面は暗いままです（毎秒1フレームを 12 秒間送って確認）。 DIS で再び点灯します。そのため、デーモンは消灯中も表示内容を動かし続けます。
CLE DC の後はセッションが終わり、デバイスは再起動しなくなります。ドライバは次の画像の前に DIS を送ります。 （DIS が必須かどうかは未確認）
メーカー製アプリは接続時に GET_REPORT（バージョン）、DIS、LIG 50 を送ってから DRA フレームを送ります。ドライバも同じ手順ですが、明るさは変更しません。
待機中のデバイスは 3 秒ごとに 2 バイトの 00 00 という input レポートを送ってきます。macOS はこの短いレポートを捨ててしまうため、使っていません。

危険なコマンド

CRT\0\0SCREEN\0（メーカー製アプリの「拡張スクリーン」モード）: 送ると DRA も LOG も無視され、自動再起動も止まります。USB 経由で送ったどのコマンドでも復帰できず、物理的に抜き差しするしかありませんでした。ドライバには、SCREEN を決して送らないことを確かめるテストがあります。
LOG のモード 0x01 は起動ロゴを恒久的に置き換えます。
メーカーの SDK にあるもののこのファームウェアでは何も表示されなかったコマンド: BGPIC、BAT、および 0xB1 の代わりに SDK の画像枚数・サイズのフィールドを入れた DRA。

確認済みの環境

2026-10-08 に ssp selftest で確認しました（全項目 PASS）。Linux と Windows は、Apple Silicon の Mac 上の VMware Fusion の VM で、D92 を USB で VM に渡して動かしています。

環境	接続	連続送信
macOS 27（Apple Silicon）	直接	52〜55fps
Ubuntu 24.04（ARM64）	VM（USB を VM に渡す）	約 58fps
Windows 11（ARM64、ビルド 26300）	VM（USB を VM に渡す）	17〜51fps（VM の負荷で変わる）
x86_64 版の Linux / Windows		まだ試していません

ファームウェアのバージョンは、3つの環境すべてで読み取れます。

ドライバの能力値

項目	値
パネル	1920x462、送信時に時計回り 90° 回転、JPEG
ライブフレーム / 保存画像	対応 / 対応
明るさ / 電源 / 消去	対応 / 対応 / 対応
`max_fps`	60
`keep_alive_interval`	2 秒
`max_image_bytes`	512 KiB