Release 0.3.5 candidate

.github/workflows/nightly.yml

@@ -7,8 +7,10 @@ name: Beta builds
 # https://github.com/sidebandstudio/EternalMonitor/releases/download/beta/EternalMonitor-Setup-beta.exe
 # never changes (docs/download.html?channel=beta links it). No tag here starts
 # with v, so release.yml and testflight.yml never run for a beta build, and
-# docs/latest.json, /releases/latest and the apps' update checks never see
-# one. scripts/nightly.py has the version, branch and retention rules.
+# docs/latest.json, /releases/latest and stable installs never see one. A
+# Beta install reads the beta release's body for the newest Beta
+# (host/src/updates.rs). scripts/nightly.py has the version, branch and
+# retention rules.
 #
 # Only a run on main publishes. A manual run with dry_run, on any other
 # branch or for a pull request that changes this pipeline, builds and scans
@@ -163,6 +165,19 @@ jobs:
           python3 scripts/nightly.py notes --version "$VERSION" --branch "$BRANCH" \
             --sha "$SHA" --stable "$STABLE" --sha256 "$SHA256" > notes.md
 
+      # What scripts/sign_beta_manifest.py --sha256/--version must be given:
+      # the hash the build computed, which the step above checked.
+      - name: Summarize the build to sign
+        run: |
+          {
+            echo "### Beta build to sign"
+            echo
+            echo "| | |"
+            echo "|---|---|"
+            echo "| Version | $VERSION |"
+            echo "| Installer SHA-256 | \`$SHA256\` |"
+          } >> "$GITHUB_STEP_SUMMARY"
+
       # The dated release first, checked anonymously; then the fixed beta link,
       # swapped by renames and checked byte for byte before the old asset goes;
       # the beta tag; and last the marker plan reads to skip a finished commit,

ARCHITECTURE.md

@@ -75,6 +75,7 @@ Rust and Swift share golden vectors and stable packet-type registry tests.
 | KEYFRAME_REQUEST | Recovery after repair expiry or decoder error |
 | PING / PONG | Min-RTT clock estimate for end-to-end latency |
 | INPUT_EVENT | Normalized mouse/touch events, HID keys and UTF-16 text |
+| POINTER_SHAPE / POINTER_STATE | The Mirror's pointer image (chunked premultiplied BGRA and an invert mask) and its position, at most once a frame budget, for an iPad that draws the pointer itself (feature bit 5, host capability bit 6); the video then leaves the pointer out. The Second screen does the same when the running virtual display driver started with a hardware cursor (as the host's settings file sets it), which the host knows from its record of that start (boot and device arrival); a pointer image larger than that cursor's caps stays in the video. When the host can't tell, it does as 0.3.4: no pointer messages, and the pointer in the video. |
 | Audio | Sequenced Opus packets with discontinuity and capture timing |
 | BYE | User, background or shutdown teardown; the host ending a silent session |
 
@@ -196,7 +197,15 @@ connected client, writes the requested mode first in VDD XML, and reports actual
 task failures. Setup and the host log the active display paths around every
 driver change; when a change leaves the PC without any real screen it had, they
 re-apply the saved layout once, else switch to "PC screen only" if the built-in
-panel was on (`display_guard.rs`, `display-guard.ps1`). It also ships a UDP
+panel was on (`display_guard.rs`, `display-guard.ps1`). At runtime the host also
+acts while the virtual display is still on: a turn on that leaves it alone
+switches Windows to "Extend" (else the saved layout or "PC screen only"), and a
+turn off never runs while it is the only screen, until Windows ends the session.
+On a hybrid laptop whose panel the virtual display takes away until a restart
+(Windows withdraws its target while the lid is open), it tries nothing and
+keeps the display on while the host runs; the turn offs at start-up, quit and
+in the failure reporter run, so the restart starts without it. Second screen
+mirrors there until the user chooses it again. It also ships a UDP
 firewall rule. Runtime upgrade, task-ACL and
 uninstall checks remain hardware gates.
 

Cargo.toml

@@ -1,8 +1,13 @@
 # docs/ contains the static website (GitHub Pages). Never write build output here.
 [workspace]
 members = ["host", "proto", "updater"]
+exclude = ["vendor"]
 resolver = "2"
 
 [profile.release]
 strip = "symbols"
 opt-level = 3
+
+# Patched copies of upstream crates; vendor/README.md says why.
+[patch.crates-io]
+egui-wgpu = { path = "vendor/egui-wgpu" }

SECURITY.md

@@ -33,7 +33,16 @@ Knowing these limits helps you judge whether a finding is new.
 - The installer is not code-signed yet. Check its SHA-256 against the release page.
 - In-app updates (Windows) trust the network for nothing: the host fetches over
   HTTPS from an allowlist of GitHub hosts, and the installer must match the
-  SHA-256 in both eternalmonitor.dev/latest.json and the GitHub release. Against
+  SHA-256 in both eternalmonitor.dev/latest.json and the GitHub release. A Beta
+  build may also update to the newer Beta from the fixed `beta` GitHub release.
+  Beta updates are signed: the release must carry a manifest with a valid
+  Ed25519 signature by a public key pinned in the app, made with a key the
+  release workflows don't have, and the manifest's version, SHA-256 and size
+  must match the release body, GitHub's digest of the installer and the
+  downloaded file. Without a valid signature no Beta is offered, and a signed
+  Beta older than one the install has already verified is refused, so an old
+  signed release can't be replayed to hold testers back. Stable builds never
+  take a Beta. Against
   other software already running as your Windows user, the updater adds defense
   in depth rather than a guarantee. Its helper loads DLLs only from System32 and
   imports only Windows system libraries. It inherits only its output pipe from

SETUP.md

@@ -261,6 +261,7 @@ try fewer words. If your problem isn't here, see [Known issues](https://eternalm
 | **That looks like the pairing code, not the PC's address** | A six-digit number was typed where the address goes. | Type the **Address** from the PC window, for example 192.168.1.20. The iPad asks for the code after it connects. |
 | **That looks like your router's address, not your PC's** | Nothing answered at an address ending in .1, which is usually the Wi-Fi router. | Type the **Address** shown in the PC window. |
 | **That address doesn't look right** | The iPad couldn't find anything by that name. | Type the **Address** exactly as the PC window shows it. |
+| **Wi-Fi is off** | iPadOS has no network for the connection: Wi-Fi is off on the iPad, or it hasn't joined a network. | Turn on Wi-Fi and join the same network as the PC, or use a USB cable. |
 | **This iPad isn't connected to a network** | Wi-Fi is off on the iPad, or it hasn't joined a network. | Turn on Wi-Fi and join the same network as the PC, or use a USB cable. |
 | **Local Network is turned off for EternalMonitor** | Local Network access is off for EternalMonitor on the iPad, so it can't reach the PC over Wi-Fi. | Tap **Open Settings** and turn on **Local Network**, or go to **Settings > Privacy & Security > Local Network** and turn on **EternalMonitor**. Then tap **Try again**. A USB cable works without this setting. |
 | **Couldn't connect to your PC** | The connection failed for another reason. | Check that both are on the same Wi-Fi and that EternalMonitor is open on the PC, then tap **Try again**. |
@@ -274,7 +275,8 @@ try fewer words. If your problem isn't here, see [Known issues](https://eternalm
 | **The connection over the cable stopped** | The USB connection broke after it had started. | Keep EternalMonitor and Apple Devices open on the PC, unlock the iPad, then unplug the cable and plug it in again. |
 | **The USB cable was disconnected** | The cable came out, or the PC lost it. | Plug the cable back in. The iPad reconnects by itself. |
 | **USB connections were turned off** | **Allow USB connections** is off in the iPad app's settings. | Turn on **Allow USB connections** to use the cable again. |
-| **Your PC ended the session** | Someone clicked **Stop** on the PC, changed a setting that restarts the stream, or closed EternalMonitor. Or the connection dropped, for example in a Wi-Fi stall, or the PC ran into a problem. | Tap **Try again** when the PC says **Ready for your iPad**. |
+| **Your PC ended the session** | Someone clicked **Stop** on the PC, changed a setting that restarts the stream, or closed EternalMonitor. | Tap **Try again** when the PC says **Ready for your iPad**. |
+| **The connection to your PC ended** | The connection dropped, for example in a Wi-Fi stall, the PC ran into a problem, or EternalMonitor restarted itself on the PC. | Tap **Try again**. With **Reconnect automatically** on, the iPad tries again by itself first. |
 | **Your PC is already streaming to another device** | Only one iPad can connect at a time. | Disconnect the other iPad first, then tap **Try again**. |
 | **Your PC is updating EternalMonitor** | The PC is installing a new version. | Wait. With **Reconnect automatically** on, the iPad connects again by itself. Otherwise tap **Try again** once EternalMonitor has opened on the PC. |
 | **Your PC hasn't come back from its update yet** | The update is taking longer than expected. | Check that EternalMonitor opened again on the PC. Windows may be waiting for you to click **Yes** there. Then tap **Try again**. |

docs/beta-testing.md

@@ -32,6 +32,30 @@ back to Stable by running the Stable installer over it.
   `docs/latest.json`, else that release's next patch. It sorts below `0.3.4`,
   so Beta users get the next Stable release from the normal update prompt, and
   Stable users are never offered a Beta build.
+- **Updates on Beta:** a Beta build also reads the `beta` release below and
+  offers the newer of that Beta and the next Stable release, with the same
+  banner, popup and helper as a Stable update. Beta updates are signed and
+  verified against a public key pinned in the app: the release must carry
+  `beta-manifest.txt` and its Ed25519 signature `beta-manifest.sig`, and the
+  manifest's version, SHA-256 and size must match the release body
+  `nightly.py` writes, GitHub's digest of the installer and the downloaded
+  file. The nightly does not sign; until a build is signed, Beta installs are
+  offered no Beta. After a nightly publishes, open its run (Actions, Beta
+  builds) and copy **Installer SHA-256** and **Version** from the Publish
+  job's summary, "Beta build to sign": the hash the Windows installer job
+  computed for the build it scanned, which Publish checks against the file
+  it uploads. Then run
+  `scripts/sign_beta_manifest.py --sha256 <hash> --version <version>` with
+  the signing key on stdin. It refuses a release that names another
+  installer or version, checks the release's parts agree, signs, checks the
+  signature with the pinned key, uploads both files and verifies them;
+  `--verify-only` checks what is published. A signed Beta older than one an
+  install has already seen is refused, so taking a bad Beta back means
+  signing a newer build, not re-signing an older one.
+  A new Beta is announced at most once a day, never during a stream. Settings, General, **Get Beta updates** (shown only on a
+  Beta build) turns this off. Taking a Stable release leaves the Beta channel.
+  Betas built before this arrived can't update themselves, so their testers
+  install one newer Beta by hand.
 - **On GitHub:** each build is a pre-release tagged `beta-<YYYYMMDD>-<sha>`,
   titled like "EternalMonitor 0.3.4 beta (Oct 30, 2026)". The newest 7 are
   kept. The pre-release `beta` always holds the newest, so this link never

docs/decisions.md

@@ -225,6 +225,36 @@ such frames then completed from late or repaired fragments. The iPad now
 requests a wide gap in several NACKs and asks for a keyframe only when a frame
 is dropped. Evidence: `EternalMonitor-Handoff/evidence/rc-hardware-20260924/`.
 
+### Repair a keyframe until it completes
+
+On WiFi with 4-22% loss, iPads held a frozen picture for 1-4 s and then
+reconnected. The PC answered every keyframe request at once, but each
+replacement keyframe arrived incomplete. A keyframe at 1080p is 80-300
+fragments, so at 10% loss one round of requests and repairs leaves some
+missing. The iPad asked again once, and dropped the keyframe at its 25 ms
+deadline because the small frames sent after it were already complete. Those
+frames need the keyframe, so the decoder held the picture and asked for
+another, which failed the same way.
+
+A keyframe now keeps its place while the frames after it complete. At its
+deadline it is held, like a frame with nothing behind it, until it completes,
+a newer keyframe completes, a second has passed, or the 32 frames the
+assembler holds are full. The hold only moves its deadline. The keyframe's
+requests follow one schedule: after its first retry it asks again every RTT +
+5 ms, sooner than which no repair can return, and only once something has
+arrived since its last request. The repair simulation
+(`proto/tests/wifi_repair_sim.rs`, 10% loss each way, 150-fragment keyframes
+at 60 fps) completed 148 of 390 keyframes before, with 35 freezes over a
+second and the longest 3.4 s. After, it completes 394 of 399, the longest
+freeze is 0.61 s, and no freeze lasts a second. The 1% loss rows also lost
+fewer frames.
+
+Delta frames keep the 25 ms rule and their single retry. Holding them too,
+for at most 100 ms, with every frame asking again, removed nearly every
+remaining drop in the simulation, but raised the p50 latency at 10% loss from
+6.6 to 10.7 ms. It would also undo the repair-window rules above, which were
+tuned on a physical iPad, so it waits for a device run.
+
 ### Use Apple's usbmuxd tunnel for USB
 
 Apple's installed device service handles the cable/trust relationship. EMLINK

host/Cargo.toml

@@ -51,7 +51,7 @@ socket2 = "0.5"
 [features]
 # Lets a release build obey ETERNAL_SIMULATE_STARTUP_FAILURE, for native
 # failure-path checks. Debug builds always do; shipped builds never do.
-fault-injection = []
+fault-injection = ["windows/Win32_Graphics_Direct3D12"]
 # Lets a release build obey ETERNAL_USB_DIRECT, for the end-to-end scripts.
 # Debug builds always do; shipped builds never do.
 usb-direct = []
@@ -86,13 +86,15 @@ features = [
     "Win32_System_Kernel",
     "Win32_System_LibraryLoader",
     "Win32_System_Com_StructuredStorage",
+    "Win32_System_Ole",
     "Win32_System_Threading",
     "Win32_System_LibraryLoader",
     "Win32_System_Performance",
     "Win32_System_Power",
     "Win32_System_ProcessStatus",
     "Win32_Storage_FileSystem",
     "Win32_Devices_FunctionDiscovery",
+    "Win32_Devices_Properties",
     "Win32_UI_Shell_PropertiesSystem",
     "Win32_Graphics_DXCore",
     "Win32_Graphics_Dxgi",
@@ -107,6 +109,7 @@ features = [
     "Win32_System_IO",
     "Win32_NetworkManagement_IpHelper",
     "Win32_NetworkManagement_Ndis",
+    "Win32_NetworkManagement_WindowsFirewall",
     "Win32_Networking_WinSock",
     "Win32_UI_Input_KeyboardAndMouse",
     "Win32_UI_Input_Pointer",