Document real 100-second Steam clip export

2026-10-24 18:01:56 +02:00 · 2026-10-24 08:56:35 +00:00
3 changed files with 0 additions and 123 deletions
@@ -1,114 +0,0 @@
-# Linux PC host feasibility on lxso2, 2026-10-24
-
-**Blocked on this host's current desktop environment. No feature enabled and
-no feature PR opened.** Investigation for [issue #23](https://github.com/saphid/frame-control/issues/23),
-starting at `4e45648` (main after #154). This concerns flat desktop panels,
-not Linux PC VR streaming.
-
-## Decision
-
-The smallest useful candidate is one explicitly selected **whole screen**,
-captured through the ScreenCast portal's restricted PipeWire connection,
-encoded locally with GStreamer/x264, and sent to the existing viewer through
-the shared SSH controller. Input, individual windows and virtual displays
-would remain unsupported until separately verified. This candidate was **not
-implemented**: lxso2 currently cannot exercise the real capture permission path.
-
-Development packages could unblock compilation, but would not create a desktop,
-portal backend or consented screen. Synthetic encoding, an Xvfb screen grab or
-using the Frame as its own host would not verify Linux PC desktop capture.
-No host packages or services were changed.
-
-## Evidence
-
-Host: `lxso2`, Linux x86-64, kernel `6.8.0-139-generic`.
-
- `DISPLAY`, `WAYLAND_DISPLAY` and `XDG_SESSION_TYPE` were unset. The user bus
-  was reachable at `/run/user/1000/bus`.
- `/run/user/1000/pipewire-0` and `/run/user/1000/wayland-0` did not exist.
-  No processes matched Xorg, Xwayland, Xvfb, GNOME Shell, KWin Wayland, Weston,
-  PipeWire, WirePlumber or xdg-desktop-portal at the process check.
- D-Bus `ListNames` returned D-Bus, systemd and anonymous connections, with no
-  `org.freedesktop.portal.Desktop`. `ListActivatableNames` also had no desktop
-  portal. These calls queried D-Bus itself without activating capture services.
- `dpkg-query` found no `xdg-desktop-portal*` or `pipewire*` packages.
-  `libgstreamer1.0-0:amd64` was installed at `1.24.2-1ubuntu0.1`, but
-  `gstreamer1.0-tools` was uninstalled. `gst-launch-1.0` and `gst-inspect-1.0`
-  were absent from PATH. Xvfb was installed, but supplies no portal by itself.
- `pkg-config --modversion` failed for `gstreamer-1.0`,
-  `gstreamer-app-1.0`, `gstreamer-video-1.0` and `libpipewire-0.3`.
-  `gio-unix-2.0` reported `2.80.0`.
- `desktop/bundle/pc-host.so` did not exist.
-  `python3 desktop/build.py --with-x264 --out /tmp/frame-linux-pc-feasibility`
-  exited **1** before compilation: required GStreamer pkg-config modules were
-  missing. No native build or encoder runtime success is claimed.
-
-Reproduce the non-activating portal checks in the intended desktop user's
-session, using that session's actual runtime directory and bus:
-
-```sh
-gdbus call --session --dest org.freedesktop.DBus \
-  --object-path /org/freedesktop/DBus --method org.freedesktop.DBus.ListNames
-gdbus call --session --dest org.freedesktop.DBus \
-  --object-path /org/freedesktop/DBus --method org.freedesktop.DBus.ListActivatableNames
-pkg-config --modversion gstreamer-1.0 gstreamer-app-1.0 gstreamer-video-1.0 gio-unix-2.0
-```
-
-## Existing implementation reviewed
-
- `ui/frame_pcview.py` selects PCView only on Windows and rejects Linux even
-  when enabled. Linux installers do not carry its native bundle.
- `desktop/portal.c` creates a **RemoteDesktop** session, requests pointer and
-  keyboard devices, and selects monitors and windows (`types=3`). It is not
-  ScreenCast-only or screen-only. Its restricted fd/node and fresh-connection
-  handling are reusable.
- `ui/frame_pc_agent.py` calls the selection a shared window or screen and
-  picks VA-API when the element is present, falling back to x264. A bounded
-  x264 slice needs explicit encoder policy and unsupported-input behavior;
-  exposing the existing Linux path alone would not meet that scope.
- `app/main.js` starts Python with the inherited environment; it does not
-  supply a compositor, portal backend or capture permission.
- `.github/workflows/pc-host.yml` installs native dependencies and tests
-  synthetic x264/protocol behavior with fake capture consent/input. This does
-  not establish interactive Linux desktop capture.
- Issue #23 and its six existing comments distinguish prior synthetic
-  helper/viewer results from untested Linux desktop capture and consent.
-
-## Verification and limits
-
-`python3 -m unittest discover -s tests -p 'test_pc*.py' -v` exited **0**:
-27 tests ran successfully, with one additional native-class setup skip
-(`native PC libraries not built on this host`). Coverage includes the compiled
-C controller trace, Python adapters, grants and default-off/Windows-only gates.
-It does not prove native GStreamer capture or local-client streaming.
-
-No fake/local native stream, consent prompt, real desktop capture, Frame viewer
-run, benchmark, input or window mode was tested in this investigation. No SSH
-connection to the Frame was needed; no lock was acquired and no headset install,
-launch, stop or settings change was attempted. Issue #113 was left alone.
-No issue comments or other public messages were sent.
-
-## Concrete unblock and next slice
-
-1. Supply an interactive Linux desktop, physical or VM, with a working
-   ScreenCast portal/backend, PipeWire and accessible consent dialog. Installing
-   the portal frontend alone is insufficient. A VM can establish software
-   capture/x264 behavior while physical-host behavior remains unverified.
-2. Install the native dependencies listed in `pc-host.yml` in that environment
-   and build a local `--with-x264` bundle. Resolve x264 distribution
-   licensing/source obligations before shipping it: the current build labels
-   that option test-only and the Windows installer omits it.
-3. Implement a ScreenCast-only session with monitor-only selection, no
-   RemoteDesktop/device request, disabled input in protocol and viewer, hidden
-   window/virtual-display modes, and explicit x264 selection. Preserve the
-   default-off gate and existing Mac/Windows paths.
-4. Verify consent acceptance/refusal/cancellation, Stop/reopen, connection loss
-   and portal closure with a local client decoding actual captured content.
-   Run the shared benchmark and record results without inferring hardware or
-   physical laser behavior.
-5. Only after local capture works, acquire the shared Frame lock once and
-   follow [the headset procedure](../testing.md#headset-smoke-test) for a brief
-   viewer test. If occupied, leave the lock alone and defer device testing.
-
-These are prerequisites and proposed scope, not a ready feature. The Linux
-host request in #23 remains open.
@@ -107,12 +107,6 @@ The Linux adapter from #38 (desktop portal, PipeWire, VA-API) is in the tree,
 because it shares `capture.c` and the controller, and CI still builds and tests
 it. The app never offers it and the Linux installers don't include it.

-The [2026-10-24 lxso2 feasibility check](evidence/linux-pc-host-lxso2-2026-10-24.md)
-found no running or activatable desktop portal, no PipeWire socket and missing
-native build dependencies. Linux support remains disabled. The evidence records
-the build failure and prerequisites for a screen-only, view-only x264 slice;
-Linux capture, input and window modes have not been verified there.
-
 ## Measuring

 The Mac benchmark accepts the PC host:
@@ -7,9 +7,6 @@ This covers three directions, plus input:
 - **C. iPhone → Frame**: mirror the phone inside the headset.
 - **PC VR from Linux**: [feasibility and options](linux-vr-streaming.md),
  including Valve's streaming and USB support. No Linux host tested yet.
- **Linux desktop → Frame panels**: [PC-host feasibility on lxso2](evidence/linux-pc-host-lxso2-2026-10-24.md).
-  Blocked on missing desktop portal/PipeWire and native build dependencies;
-  Linux desktop capture remains disabled and unverified.
 - **Input**: type and point in the Frame from the Mac or iPhone.
 - **Live view and Control**: watch a panel flat and tap on it to use it.