Bump Frame Control to 0.4.28 (#203)

Co-authored-by: SAPHID <saphid@users.noreply.github.com>

README.md

@@ -148,7 +148,7 @@ Get-FileHash .\Frame-Control-Setup-x64.exe -Algorithm SHA256
 
 The [source](https://github.com/saphid/frame-control) and [release build workflow](.github/workflows/release.yml) are public. The Windows installer is **not code-signed**, so SmartScreen may warn. The macOS app has only an **ad hoc signature**, not an Apple Developer ID signature; the DMG is **unsigned and not notarized**, so Gatekeeper may warn or block it. Only follow the opening steps below if you trust the download.
 
-日本語: v0.4.26 以降は公式リリースの SHA256SUMS とファイルの SHA-256 値を照合してください。Windows は未署名、macOS は開発者 ID による署名・公証がありません。
+日本語: [5 ステップの接続ガイド](docs/connection-faq.md#日本語-5-ステップで接続)を参照してください。v0.4.26 以降は公式リリースの SHA256SUMS とファイルの SHA-256 値を照合してください。Windows は未署名、macOS は開発者 ID による署名・公証がありません。
 
 **Which build?** On a Mac, check Apple menu → About This Mac: the download is
 for Apple Silicon (M-series); no Intel Mac build is published. On Windows,
@@ -245,6 +245,14 @@ network. Guest Wi-Fi/client isolation can prevent discovery and connections.
    check Developer Mode, the address and network isolation, then run setup again.
    For connections away from home, see [Tailscale](docs/tailscale.md).
 
+**Does Frame Control lower streaming lag?** No. Frame Control manages the Frame
+over SSH. SteamVR or Steam Link carries the game stream. Frame Control does not
+carry that stream, lower ping, or need the Wireless Adapter. It can connect over
+Wi-Fi, the Wireless Adapter, or USB when your computer has an SSH route to the
+Frame. The wired doctor checks only that SSH route. A data-capable USB-A-to-C
+cable has not been tested for the Frame's USB network. See the
+[connection FAQ and Japanese quick start](docs/connection-faq.md).
+
 **What it changes:** only what you click. Installs go to your user account on
 the Frame (`--user` Flatpaks, Lepton instances, Steam downloads, sideloaded
 games in `~/devkit-game`), and nothing

app/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "frame-control",
-  "version": "0.4.27",
+  "version": "0.4.28",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "frame-control",
-      "version": "0.4.27",
+      "version": "0.4.28",
       "license": "MIT",
       "devDependencies": {
         "electron": "^44.4.5",

app/package.json

@@ -1,7 +1,7 @@
 {
   "name": "frame-control",
   "productName": "Frame Control",
-  "version": "0.4.27",
+  "version": "0.4.28",
   "description": "Desktop app for managing a Valve Steam Frame over SSH",
   "private": true,
   "main": "main.js",

docs/connection-faq.md

@@ -0,0 +1,37 @@
+# Connection and streaming lag FAQ
+
+## Does Frame Control lower my streaming lag?
+
+No. Frame Control uses SSH to manage the Frame. SteamVR or Steam Link sends the
+game stream. Frame Control does not carry the game stream. It cannot lower your
+game-stream ping or fix a stream that stops on the PC. A 40–75 ms ping in a VR
+game is not a Frame Control measurement.
+
+You do **not** need the Steam Wireless Adapter to use Frame Control. The app can
+connect over Wi-Fi, the Wireless Adapter, or USB if the computer has an SSH
+route to the Frame. Use the route that lets the app connect. To improve game
+streaming, check the SteamVR or Steam Link connection on the PC and the Frame.
+The [wired connection doctor](wired-connection.md) checks only Frame Control's
+SSH route. A successful doctor check does not prove that the game stream uses
+the cable or has low lag.
+
+## Can I use a USB-A-to-C cable?
+
+A Mac reached the Frame over a USB-C connection on the
+`10.86.200.232/29` USB network. That test used a USB-C host port. We have
+**not tested a USB-A-to-C cable** with the Frame. A data-capable USB-A-to-C
+cable might show a USB network interface on your PC, but this is unknown on
+the tested Frame OS and PC hosts. Check whether your PC shows that interface
+and whether Frame Control's wired doctor can reach the Frame at
+`10.86.200.233`. A charge-only cable cannot carry USB data. You can use Wi-Fi
+for Frame Control if the USB route does not work.
+
+## 日本語: 5 ステップで接続
+
+1. [公式リリース](https://github.com/saphid/frame-control/releases/latest)から PC の OS 用ファイルをダウンロードします。Windows は `.exe`、macOS は `.dmg`、Linux は `.AppImage` または `.deb` です。同じリリースの `SHA256SUMS` でファイルを確認してください。
+2. PC に Frame Control をインストールして起動します。Windows はスタートメニュー、macOS はアプリケーション、Linux はアプリ一覧から開きます。AppImage の場合は実行権限を付けて開きます。
+3. Frame の Steam 設定 → システムで開発者モードを有効にし、開発者設定でユーザーパスワードを設定します。Frame と PC を同じ信頼できるネットワークに接続し、Frame を起こしておきます。
+4. PC の Frame Control で **Set Up Connection…** を選びます。Frame が見つからない場合は、Frame の設定で IP アドレスを確認して入力します。macOS では **Devices & connection → + Add a headset…** からアドレスを設定できます。
+5. Frame に **Pair new host** が出たら、自分が開始した要求だけを承認します。ペアリングに失敗した場合は、PC のターミナルで開発者モードのパスワードを入力します。接続後、Frame Control に戻って状態を確認します。
+
+Frame Control は管理用の SSH 接続を使います。ゲーム映像は SteamVR / Steam Link が送ります。Frame Control を入れてもゲームの ping は下がりません。無線アダプターは必須ではありません。USB-A-to-C ケーブルで Frame の USB ネットワークが使えるかは、まだ確認できていません。

docs/current-support-matrix.md

@@ -1,6 +1,6 @@
 # What we have tested
 
-Current for Frame Control **v0.4.27**, 25 October 2026. “Real Frame + physical PC” means an actual headset and a non-virtual computer. “VM only” means a Windows virtual machine, sometimes connected to the real Frame. A CI test or a simulated device is **not** a physical hardware test. The date/version column is the last relevant check, not a promise that every new release was retested on that platform. See each link for the exact procedure and limits.
+Current for Frame Control **v0.4.28**, 25 October 2026. “Real Frame + physical PC” means an actual headset and a non-virtual computer. “VM only” means a Windows virtual machine, sometimes connected to the real Frame. A CI test or a simulated device is **not** a physical hardware test. The date/version column is the last relevant check, not a promise that every new release was retested on that platform. See each link for the exact procedure and limits.
 
 | Feature | Real Frame + physical PC tested | VM only | Untested or limited | Last check and proof |
 |---|---|---|---|---|
@@ -10,6 +10,7 @@ Current for Frame Control **v0.4.27**, 25 October 2026. “Real Frame + physical
 | OBS headset source on Linux | Real Frame to OBS 30 on a Linux host; H.264 video and a synthetic 440 Hz output tone reached a saved recording | No | Real game audio, audible monitoring, perceptual A/V sync and awake headset view | 25 Oct, PR #174 head, shipped in v0.4.22: [OBS log](evidence/obs-media-source-real-2026-10-25.md) |
 | OBS headset source on Windows | No physical Windows PC test | No OBS/Frame VM end-to-end test | App Start/Stop path has automated Windows checks only | 25 Oct, v0.4.23: [Windows PR #179](https://github.com/saphid/frame-control/pull/179), [OBS guide](obs-headset-source.md) |
 | OBS headset source on macOS | No | No | Helper and OBS Media Source not tested on a Mac with a Frame | 25 Oct, v0.4.22: [OBS PR #174](https://github.com/saphid/frame-control/pull/174), [OBS guide](obs-headset-source.md) |
+| OBS headset source on a SteamOS / Steam Machine PC | No SteamOS PC or Flatpak OBS runtime test | No SteamOS host VM test | v0.4.27 AppImage launched on Ubuntu x86_64 under Xvfb; the helper sent H.264/AAC from a real Frame to a local UDP receiver. SteamOS read-only root, desktop UI and Flatpak OBS remain unverified | 25 Oct, v0.4.27: [host test](evidence/obs-steamos-host-2026-10-25.md), [OBS guide](obs-headset-source.md#steamos--steam-machine-pc-host) |
 | Wired connection doctor | No physical PC/Frame cable test of the doctor | No | Synthetic route/SSH tests; a separate Mac USB-C address observation does not test the doctor or game stream | 25 Oct, v0.4.23: [PR #178](https://github.com/saphid/frame-control/pull/178), [wired guide](wired-connection.md) |
 | Windows Wireless Adapter doctor | No physical Steam Wireless Adapter/dropout test | Windows 11 VM ran read-only checks without the adapter or WLAN | Adapter identification, dropouts and recovery on hardware | 24–25 Oct, v0.4.20–0.4.25: [VM log](evidence/windows-wireless-2026-10-24.md), [doctor guide](windows-wireless-doctor.md), [comparison PR #184](https://github.com/saphid/frame-control/pull/184) |
 | Linux Wireless Adapter doctor | No Steam Wireless Adapter hardware test | No | Read-only Linux host checks and mocked adapter states; no adapter-specific hardware observation | 24 Oct, v0.4.20: [PR #165](https://github.com/saphid/frame-control/pull/165), [doctor guide](linux-wireless-adapter-doctor.md) |

docs/evidence/obs-steamos-host-2026-10-25.md

@@ -0,0 +1,32 @@
+# SteamOS PC OBS host feasibility check, 2026-10-25 UTC
+
+The available x86_64 host, lxso2, runs Ubuntu 24.04.3. It has no `flatpak`
+command, OBS installation, SteamOS 3.9.5 VM or physical Steam Machine. This
+check therefore does **not** verify that Frame Control or Flatpak OBS runs on
+a SteamOS desktop or a read-only-root PC host.
+
+The downloaded v0.4.27 Linux x86_64 AppImage matched GitHub's SHA-256 digest
+`42d774653c69b193c3d577743c32b8fe8dfeee7ea1f8cdf7369902962d647b83`.
+With `APPIMAGE_EXTRACT_AND_RUN=1`, it launched under Xvfb using an isolated
+profile and its bundled server returned HTTP 200. FUSE mounting, physical
+display rendering and SteamOS-specific dependencies were not tested.
+
+The v0.4.27 tagged OBS helper then ran against the real Frame under the shared
+`/tmp/frame-test.lock`. Frame OS was 0.5.6 and SteamVR activity level was 3
+(standby). A receiver bound to `127.0.0.1:15099` on lxso2 accepted 497
+MPEG-TS packets, 93,436 bytes. Every datagram had complete 188-byte packets
+with sync bytes. `ffprobe` found H.264 video and AAC audio. Closing the
+helper's control pipe made it exit 0; no owned remote stream process remained.
+Battery read 100% Full before and after, and the owned lock was released. The
+temporary `.ts` file was removed. This proves the local UDP sender path on an
+Ubuntu host; it does not prove Flatpak OBS could receive it on SteamOS.
+
+The public
+[OBS Flatpak manifest](https://github.com/flathub/com.obsproject.Studio/blob/master/com.obsproject.Studio.json)
+lists `--share=network`, which permits use of the host network. We read that
+manifest but did not install or run the Flatpak. A future check needs a real
+SteamOS 3.9.5 desktop host or VM with Flatpak OBS: launch the AppImage without
+root changes, start the source, record from the Media Source at
+`udp://127.0.0.1:15099`, verify video and audible game audio, then stop and
+confirm cleanup. The standby test cannot establish real game audio, A/V sync
+or active passthrough in the mirror.

docs/obs-headset-source.md

@@ -56,6 +56,42 @@ The [follow-up Linux/Frame transport check](evidence/obs-followup-2026-10-25.md)
 measured packet continuity and a short MP4 recording on the current SteamOS
 build. The headset was still in standby.
 
+## SteamOS / Steam Machine PC host
+
+Use **Desktop Mode** on the SteamOS PC. Download the Linux x86_64 AppImage to
+your home folder. Make it executable and open it there; SteamOS has a
+read-only system root, so these steps do not use `apt` or change `/usr`:
+
+```sh
+chmod +x ~/Downloads/Frame-Control-linux-x86_64.AppImage
+~/Downloads/Frame-Control-linux-x86_64.AppImage
+```
+
+If AppImage mounting reports a FUSE error, try
+`APPIMAGE_EXTRACT_AND_RUN=1 ~/Downloads/Frame-Control-linux-x86_64.AppImage`.
+This extracts to writable temporary space and needs enough free disk space.
+Set up the Frame's SSH connection in Frame Control, then use **Start OBS
+source** before you add or activate OBS's Media Source. Install OBS as the
+`com.obsproject.Studio` Flatpak through Discover or your normal user Flatpak
+setup. In that OBS Media Source, clear **Local File**, set **Input** to
+`udp://127.0.0.1:15099`, and set **Input Format** to `mpegts`. Make a short
+recording and check both picture and sound before a stream. Use **Stop OBS
+source** in Frame Control when done.
+
+The OBS Flatpak's published manifest includes `--share=network`, which is
+needed for its local UDP receiver. Check your installed permissions with
+`flatpak info --show-permissions com.obsproject.Studio` if OBS receives no
+packets. Frame Control's helper sends to loopback on this PC; it does not
+require an open LAN port or an OBS plugin. The PC does not need a system
+`ffmpeg` package for the helper; encoding runs on the Frame.
+
+**Test limit:** The v0.4.27 AppImage launched on an Ubuntu 24.04 x86_64 host
+under Xvfb. Its helper sent H.264 and AAC from a real Frame to a local UDP
+receiver on that host. No SteamOS 3.9.5 PC, Steam Machine, Flatpak OBS runtime,
+read-only-root host, or physical display was available for this check. The
+SteamOS steps and Flatpak receiver therefore remain **untested on SteamOS**.
+See the [test record](evidence/obs-steamos-host-2026-10-25.md).
+
 ## Known issue: game audio in OBS
 
 A Frame owner [reported](https://x.com/AzizahStellazio/status/2114147449468293171)

docs/wired-connection.md

@@ -25,3 +25,19 @@ uses the cable. The Wireless Adapter and Steam streaming can follow a different
 path. No cable is attached to the Linux test host, so this exact UI has only
 synthetic route/SSH tests. Windows and Linux physical USB-C behavior, and a
 fresh wired readback on the current Frame OS, remain unverified.
+
+## If SSH works but the game stream stops
+
+If the stream fails on USB, Wi-Fi and the Wireless Adapter, but this doctor
+reports a working SSH route, check SteamVR on the **PC**. Frame Control's
+`frame.local` reconnect only restores its headset management connection. It
+does not restart PC SteamVR or repair the game stream. On a Windows or Linux
+PC, save your work and close the VR game. Exit SteamVR from Steam on that PC,
+then start it again. This can show whether a PC SteamVR session is stuck; it
+does not fix the cause of repeated drops. SteamVR on macOS is not a supported
+PC streaming host.
+
+Frame Control has no verified cross-platform command that safely stops only
+the intended PC SteamVR session. A forced restart could close a running game
+and lose unsaved progress. For that reason the app gives manual steps and does
+not add a one-click restart button.

ui/wired-doctor.html

@@ -11,6 +11,8 @@
 <section><div class="row"><label for="alias">Your configured headset SSH alias<input id="alias" value="frame" maxlength="64" autocomplete="off"></label>
 <button id="check">Check cable connection</button></div><p id="message" role="status" aria-live="polite">No checks have run.</p></section>
 <div id="results" aria-live="polite"></div>
+<section><h2>SSH works, but the PC stream still fails?</h2>
+<p>The doctor checks Frame Control's SSH route only. If the SteamVR stream stops on USB, Wi-Fi and the Wireless Adapter, the problem may be on the PC. On a Windows or Linux PC, first save your work and close the VR game. Exit SteamVR from Steam on the PC, then start SteamVR again. Frame Control reconnecting to <code>frame.local</code> will not restart PC SteamVR. This is a manual test, not a fix for the cause of repeated drops. Frame Control does not restart PC SteamVR automatically because it cannot safely know which game and session it would stop.</p></section>
 <p class="sub">The observed USB address is 10.86.200.233 on Frame OS tested in 2026. A different OS build may use another subnet. An unknown result does not prove the cable is broken. The doctor never changes IP settings, accepts a new host key, or bypasses SSH warnings.</p>
 </main><script>
 'use strict';