Merge main into Windows wireless doctor

README.md

@@ -76,7 +76,7 @@ Drag files onto the window to send them. Drop a game's .zip, folder or .exe to a
 <td valign="top">
 
 **📸 Screenshots and recordings**<br>
-Browse the shots you take in the headset and save them to your Pictures folder, or have new ones and your Steam clips copied over automatically. Record SteamVR's mirrored headset view, with its sound, or export Steam's clips at any length, as .mp4 files in your Videos folder. [Recording details and passthrough limits](docs/recording.md#does-record-include-passthrough).
+Browse the shots you take in the headset and save them to your Pictures folder, or have new ones and your Steam clips copied over automatically. Record what the headset shows, with its sound, or export Steam's clips at any length, as .mp4 files in your Videos folder ([not tested on a headset yet](docs/recording.md)).
 
 **⌨️ Keyboard and trackpad**<br>
 Type and point in the headset from your computer or phone, through Valve's own input path, with nothing to install. Accents and emoji use KDE Connect, which Frame Control brings along and sets up the first time you type one. Copy text to the headset's clipboard and back again. Press T to open it.

app/package-lock.json

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

app/package.json

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

docs/evidence/steamos-compat-live-2026-10-25.md

@@ -1,22 +0,0 @@
-# SteamOS 0.5.6 compatibility check, 25 October 2026
-
-The real Frame was accessed **after** the 00:00 AEDT hold, under a separately
-acquired `/tmp/frame-test.lock`. The coordinator had finished its v0.4.19 smoke
-test and released its lock first. This check took place approximately 00:04–
-00:08 AEDT (13:04–13:08 UTC). A device clock reading in the first snapshot was
-**00:04:58 AEDT**. The one temporary capture was removed and our lock was
-released. Steam and SteamVR were left running.
-
-| Check | Observation |
-|---|---|
-| OS | `VERSION_ID=0.5.6`, `VARIANT_ID=vr`, `BUILD_ID=20261022.6153909` |
-| Update channel | `atomupd-manager tracked-branch` returned `beta`; tracked variant `vr`; update status `idle`. `atomupd-manager status` and `check` returned D-Bus `AccessDenied` to the normal user. No root, update, or channel change was attempted. |
-| Discovery | `frame.local` and a sample `frame-0000.local` name were unresolved from the Linux host. Avahi was active on the Frame, but `/etc/avahi/avahi-daemon.conf` has `publish-addresses=no`. The configured `ssh frame` alias worked. The host reached the Frame over Tailscale, so a local-subnet scan and same-LAN cached-IP reconnection were not exercised. |
-| Script fallback | `steamos-session-select` was present and `holo-session-select` absent. The installed devkit utilities contained `steamos-prepare-upload` and `steamos-delete`; their `holo-*` replacements were absent. No session switch, install, or delete command was run. |
-| Battery and memory | Frame Control's `ui/frame_status.py` returned a system battery at 98%, Charging, with its source under `/sys/class/power_supply/max1720x_bat_7-36`; memory was 16,422,952,960 bytes total and 11,256,848,384 bytes available. The battery was 97% at the initial raw sysfs check and 98% at the final check while charging. |
-| Recording source | The user `steamvr-v4l2cam.service` and `/dev/video99` were present. A single frame from that device was black while the unworn headset was in standby. Frame Control's MP4 path reads that same SteamVR `system.HeadsetView` mirror and never opens a passthrough camera. Active passthrough inclusion in the mirror remains unverified. The sample image was not retained or published. |
-| Dominant eye | Neither standard `steamvr.vrsettings` path checked had a readable dominant-eye setting. No source or effect on the mirror was verified; Frame Control does not attach dominant-eye metadata. |
-
-This was a bounded compatibility check, not a rerun of the coordinator's
-13-step smoke test. The coordinator reported that smoke passed on this same
-build, with battery 95% to 96% while charging and cleanup complete.

docs/recording.md

@@ -1,6 +1,6 @@
 # Recording and Steam clips
 
-Frame Control can record SteamVR's mirrored headset view, with its sound, and save it as
+Frame Control can record what the headset shows, with its sound, and save it as
 an `.mp4` on your computer. It can also export the clips and background
 recordings from Steam's own game recording, at any length, as one `.mp4` each.
 Both are on **Tools → Capture & Live**. Everything is saved to
@@ -47,21 +47,6 @@ the Frame, converted to `.mp4` there (without re-encoding) and copied to
 
 Recording and **Live** can run together; both read the same device.
 
-### Does Record include passthrough?
-
-**Record captures SteamVR's `system.HeadsetView` mirror from `/dev/video99`.**
-Frame Control does not open the headset's passthrough cameras or add a separate
-camera layer to the MP4. If SteamVR puts passthrough into that mirror, it will
-appear in the recording; Frame Control cannot force or promise that result.
-Steam's own **Steam clips** use a separate game recording path and may differ.
-
-On 25 October 2026, the Frame was in standby. A frame captured from
-`/dev/video99` was black, as expected in standby, so this check **did not
-establish whether active passthrough appears in the mirror**. A wearer-visible
-passthrough session and its simultaneous mirror frame are still needed for a
-yes-or-no answer about passthrough pixels. See the
-[live compatibility evidence](evidence/steamos-compat-live-2026-10-25.md).
-
 ## Steam clips
 
 **Steam clips** lists what Steam's game recording has kept on the Frame: saved

docs/steamos-2026-10-compat.md

@@ -53,13 +53,8 @@ The battery reader selects a system battery by power-supply `type` and `scope`
 and reads standard sysfs fields. The memory reader uses `/proc/meminfo`.
 Neither relies on the performance overlay's labels or hard-coded SteamOS
 paths. SteamOS 0.5.6's improved overlay reporting does not establish a sysfs
-path change. A live check on build `20261022.6153909` confirmed that Frame
-Control's existing readers return battery and memory values. The dominant-eye
-setting is not read yet; recording metadata must not claim an eye until its
-source and effect on `/dev/video99` are verified. The same check found the
-`beta` update branch, but the normal user could not query update availability
-through Atomupd; no update was applied. See the
-[live evidence](evidence/steamos-compat-live-2026-10-25.md).
+path change. The dominant-eye setting is not read yet; recording metadata
+must not claim an eye until its source and effect on `/dev/video99` are verified.
 
 Sources: [SteamOS 3.9 news](https://store.steampowered.com/news/app/1675200),
 [Frame OS news](https://steamcommunity.com/app/4165890/allnews/), and the