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/charge-limit.md

@@ -9,11 +9,6 @@ only control the Frame has is a vendor charger attribute that Valve's own
 charging daemon also manages. Research as of 2026-10-23, confirmed with the
 read-only checks below on a Frame running SteamOS 0.5.6 (build 20261015.6141207):
 
-Rechecked read-only on build `20261022.6153909` on 2026-10-25: the
-`BatteryChargeLimit1` interface still returned `UnknownInterface`, no
-`charge_control_*` sysfs attribute existed, and the vendor charging switches
-were root-owned mode `644`. See [Round 3 headset evidence](evidence/round3-headset-2026-10-25.md).
-
 - `steamosctl get-max-charge-level` fails with `UnknownInterface: ...BatteryChargeLimit1`.
 - `/usr/share/steamos-manager/devices/` has `[battery_charge_limit]` only for
   the Steam Deck, ROG Ally, ROG Xbox Ally and MSI Claw, not the Frame.

docs/evidence/round3-headset-2026-10-25.md

@@ -1,19 +0,0 @@
-# Round 3 headset checks, 25 October 2026
-
-These checks used the real Frame after the device hold ended. SteamOS was
-0.5.6, build `20261022.6153909`. Each device session acquired
-`/tmp/frame-test.lock` atomically and released only its own lock. The battery
-read 100% and Full in the first check and after the OBS session; Steam and
-SteamVR were left running.
-
-| Question | Observation | Conclusion |
-|---|---|---|
-| Does active passthrough appear in SteamVR's `/dev/video99` mirror? | The mirror service was active. One 1920×1080 RGB frame read from `/dev/video99` had a single pixel value, `(24, 28, 53)`, throughout. The headset was unworn; no active passthrough session or wearer-visible room view was established. Frame Control has no verified remote passthrough toggle. The temporary frame was removed. | **Still unknown.** A uniform standby frame cannot answer whether SteamVR composites active passthrough into its mirror. No headset setting was changed. |
-| Can Frame Control prompt when a headset text box opens? | No desktop `plasmashell` process was running during this check. There is no verified cross-app focus event from SteamVR, Lepton and the nested desktop; KDE Connect's `keyboardstate` packet describes keyboard support, not a focused text field. | **Not built.** A prompt triggered by an unverified signal would be misleading. The existing **Type on the headset** control remains available. |
-| Does reverse clipboard exist? | Frame Control already has **Copy the headset's clipboard here**. Its earlier real Frame test used a temporary nested desktop and confirmed that text copied through Klipper reached a Linux PC clipboard. No desktop panel was open during this session, so it was not rerun here. | **Shipped and previously verified**, text only. Windows/macOS backends and arbitrary headset apps remain unverified on a real Frame. |
-| Is an 80% charge limit available and writable? | `steamosctl get-max-charge-level` returned `UnknownInterface: ...BatteryChargeLimit1`. No `charge_control_*` attribute was found under `/sys/class/power_supply`. Only `pm8550b-charger/charging_pause` and `charging_enable` were present, each mode `644`, owner `root:root`. | **No supported user-writable control.** No battery attribute was written. |
-
-The separate OBS transport check on the same build sent the mirror and the
-default-output monitor to a Linux PC. A 4.021-second temporary capture had
-H.264 video and AAC audio according to `ffprobe`. It was removed; OBS itself
-and audible playback were not tested. See the OBS source PR and guide.

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