Release 0.3.5 candidate

.github/workflows/beta-installer.yml

@@ -100,12 +100,30 @@ jobs:
       - name: Download the bundled virtual display driver
         shell: pwsh
         run: |
+          # GitHub's download servers sometimes answer 5xx for a minute or two.
+          # Up to 5 tries over 2 minutes; another 4xx fails at once. The next
+          # step checks the driver's pinned SHA-256 either way.
+          function Get-WithRetry($uri, $out) {
+              $waits = 10, 20, 30, 60
+              for ($try = 1; ; $try++) {
+                  try {
+                      Invoke-WebRequest -Uri $uri -OutFile $out
+                      return
+                  } catch {
+                      $status = [int]$_.Exception.Response.StatusCode
+                      $transient = $status -eq 0 -or $status -eq 429 -or $status -ge 500
+                      if (-not $transient -or $try -gt $waits.Count) { throw }
+                      Write-Warning "Download of $uri failed (try $try): $($_.Exception.Message). Retrying in $($waits[$try - 1]) s."
+                      Start-Sleep -Seconds $waits[$try - 1]
+                  }
+              }
+          }
           $dest = "installer\vendor\vdd"
           $url = "https://github.com/VirtualDrivers/Virtual-Display-Driver/releases/download/$env:VDD_RELEASE_TAG/$env:VDD_ASSET"
-          Invoke-WebRequest -Uri $url -OutFile (Join-Path $dest $env:VDD_ASSET)
+          Get-WithRetry $url (Join-Path $dest $env:VDD_ASSET)
           # Its MIT license text, redistributed alongside the binary.
-          Invoke-WebRequest -Uri "https://raw.githubusercontent.com/VirtualDrivers/Virtual-Display-Driver/$env:VDD_RELEASE_TAG/LICENSE" `
-              -OutFile (Join-Path $dest "LICENSE-VirtualDisplayDriver.txt")
+          Get-WithRetry "https://raw.githubusercontent.com/VirtualDrivers/Virtual-Display-Driver/$env:VDD_RELEASE_TAG/LICENSE" `
+              (Join-Path $dest "LICENSE-VirtualDisplayDriver.txt")
 
       - name: Verify the driver against the pinned SHA-256
         shell: pwsh

.github/workflows/ci.yml

@@ -97,6 +97,9 @@ jobs:
       - name: Verify Setup hands its language to the app
         shell: powershell
         run: ./installer/tests/Test-InstallerLanguages.ps1
+      - name: Verify Setup leaves the virtual display driver off Windows 10
+        shell: powershell
+        run: ./installer/tests/Test-InstallerWindows10.ps1
 
   rust-macos:
     name: Rust (macOS, full workspace + E2E)

.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,

.github/workflows/release.yml

@@ -101,12 +101,30 @@ jobs:
       - name: Download the bundled virtual display driver
         shell: pwsh
         run: |
+          # GitHub's download servers sometimes answer 5xx for a minute or two.
+          # Up to 5 tries over 2 minutes; another 4xx fails at once. The next
+          # step checks the driver's pinned SHA-256 either way.
+          function Get-WithRetry($uri, $out) {
+              $waits = 10, 20, 30, 60
+              for ($try = 1; ; $try++) {
+                  try {
+                      Invoke-WebRequest -Uri $uri -OutFile $out
+                      return
+                  } catch {
+                      $status = [int]$_.Exception.Response.StatusCode
+                      $transient = $status -eq 0 -or $status -eq 429 -or $status -ge 500
+                      if (-not $transient -or $try -gt $waits.Count) { throw }
+                      Write-Warning "Download of $uri failed (try $try): $($_.Exception.Message). Retrying in $($waits[$try - 1]) s."
+                      Start-Sleep -Seconds $waits[$try - 1]
+                  }
+              }
+          }
           $dest = "installer\vendor\vdd"
           $url = "https://github.com/VirtualDrivers/Virtual-Display-Driver/releases/download/$env:VDD_RELEASE_TAG/$env:VDD_ASSET"
-          Invoke-WebRequest -Uri $url -OutFile (Join-Path $dest $env:VDD_ASSET)
+          Get-WithRetry $url (Join-Path $dest $env:VDD_ASSET)
           # Its MIT license text, redistributed alongside the binary.
-          Invoke-WebRequest -Uri "https://raw.githubusercontent.com/VirtualDrivers/Virtual-Display-Driver/$env:VDD_RELEASE_TAG/LICENSE" `
-              -OutFile (Join-Path $dest "LICENSE-VirtualDisplayDriver.txt")
+          Get-WithRetry "https://raw.githubusercontent.com/VirtualDrivers/Virtual-Display-Driver/$env:VDD_RELEASE_TAG/LICENSE" `
+              (Join-Path $dest "LICENSE-VirtualDisplayDriver.txt")
 
       - name: Verify the driver against the pinned SHA-256
         shell: pwsh

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

@@ -255,12 +255,13 @@ try fewer words. If your problem isn't here, see [Known issues](https://eternalm
 | **EternalMonitor can't look for PCs** | The iPad isn't allowed to search your local network. | Tap **Open Settings** and turn on **Local Network**, or go to **Settings > Privacy & Security > Local Network** and turn on **EternalMonitor**. Then tap **Search again**. A USB cable works without this setting. |
 | **Couldn't search for PCs** | The iPad's search for PCs failed for a reason other than Local Network access. | Tap **Search again**, or scan the QR code or type the **Address** shown in the PC window. If it keeps failing, turn on **Local Network** for EternalMonitor in the iPad's Settings. |
 | **Couldn't get its address. Type the Address shown on the PC.** under a found PC | The iPad saw the PC's name but not its address. | Type the **Address** shown in the PC window, then tap **Connect to PC**. |
-| **Your PC didn't answer** | Nothing came back from the PC. It may be closed, asleep, on another network, or blocked by a firewall. | Check that EternalMonitor is open on the PC and says **Ready for your iPad**, that the PC is awake, and that both are on the same Wi-Fi, not a guest network. If all of that is right, Windows Firewall or security software is probably blocking EternalMonitor: run EternalMonitor-Setup.exe again, or use a USB cable. Then tap **Try again**. |
+| **Your PC didn't answer** | Nothing came back from the PC. It may be closed, asleep, on another network, or blocked by a firewall. | Check that EternalMonitor is open on the PC and says **Ready for your iPad**, that the PC is awake, and that both are on the same Wi-Fi, not a guest network. If all of that is right, Windows Firewall or security software is probably blocking EternalMonitor: run EternalMonitor-Setup.exe again, or use a USB cable. Then tap **Try again**. If you open EternalMonitor on the PC within a few minutes of the message appearing, the iPad connects by itself. |
 | **Your PC didn't answer over the cable** | The cable is connected, but EternalMonitor on the PC didn't reply through it. | Check that EternalMonitor and Apple Devices are both open on the PC, then unplug the cable and plug it in again. |
 | **Your PC answered, but no picture arrived** | The connection worked, but the PC's second screen didn't start, or the PC couldn't send its screen. | On the PC, choose **Mirror my screen** (**Main display (mirror)** in version 0.3.1), then tap **Try again** on the iPad. If the PC already mirrors, click **Restart** there first. After two attempts in a row end this way, the iPad stops reconnecting by itself until you tap **Try again**. |
 | **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,10 @@ 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 went to sleep** | Windows put the PC to sleep while it streamed. | Wake the PC, then tap **Try again**. |
+| **Your PC is shutting down or signing out** | Windows shut down, restarted or signed out while the PC streamed. | Tap **Try again** once the PC is on, someone has signed in, and EternalMonitor is open. |
 | **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