Skip to content

linux-stable-host.md

Latest commit

 

History

History
560 lines (492 loc) · 31.4 KB

linux-stable-host.md

File metadata and controls

560 lines (492 loc) · 31.4 KB
Raw

Linux stable-host vertical slice

Date: 2026-08-09 (updated 2026-08-28)

SOS now has both a real Linux presentation host and a minimal trusted Wayland compositor. The host can remain an ordinary client for desktop development, or the Debian reference VM can boot directly into a systemd/PAM session where SOS owns tty1, seat0, DRM/KMS, libinput, surface policy, and presentation evidence. Both paths preserve the same generated experience, stable-host lifecycle, and local provider/state boundary.

Current process and presentation boundary

experience graph supervisor
    | newline JSON: boot_graph / prepare_graph / present_graph /
    |               confirm_graph / discard_graph / shutdown
    v
stable sos-experience-host process
    | one Luau VM per graph Instance -> validated retained scene -> GPUI
    v
one GPUI Wayland surface
    v
existing Wayland compositor

linux-run also owns a sibling provider/state authority. The Linux-only sos-linux-session helper verifies the revision and graph stores, bootstraps authority state for every Experience in the committed graph, and asks the graph supervisor to activate candidates transactionally. The same authority socket is passed to the supervisor and host; either top-level service exiting tears down the developer session. Recovery reconciles the graph activation journal, registry and graph pointers, and the authority's batched state promotion as one boundary.

experience-host-protocol owns the transport ABI shared by the supervisor and host. Host stdout is reserved for newline-delimited protocol events; all GPUI, runtime, timing, and recovery diagnostics go to stderr. A candidate is compiled and rendered in a fresh Luau VM while the accepted scene remains active. The installed session sets SOS_GRAPH_RUNTIME_ISOLATION=process, which moves v4 graph VMs behind a bounded subprocess protocol. Set it to thread only for a deliberate deployment fallback. On present_graph, the workers commit those prepared VMs and the same GPUI entity renders the new composed scene. In an ordinary Wayland session, a GPUI next-frame callback emits presentation evidence. Under sos-compositor, the host instead arms the scene handoff and waits for the compositor to observe its later shell commit in a successful nested backend submit. A later confirm_graph request proves that the event loop is still responsive before the supervisor advances registry and graph pointers.

The Linux adapter consumes Experience API v4 scenes: orthogonal layout/content/paint/ interaction/animation facets, bounded containing-block layout programs, nested clips/transforms/layers, host-shaped glyph runs, revision images/fonts, and tap, double-tap, long-press, swipe, drag, drop, and single-pointer events all render through GPUI. Android and Linux use the same revision asset/font registry and retained paint/gesture surface. A small shared hook lets Android register each surface with its raw NDK multi-pointer router without making that router part of the Linux client.

The host validates manifest format 4, file sizes, SHA-256 values, source/state binding, package contract, schema, and API version 4 again before activation. It separately loads and re-verifies the candidate revision's content-addressed image/font/shader sidecars, then supplies only that set to the candidate's fresh VM. A candidate therefore cannot inherit assets from the boot or accepted revision. Wayland objects and file descriptors are never exposed to Luau.

When --service-socket is configured, interaction results are committed on a background thread through the versioned provider/state Unix-socket protocol. The Linux boundary maps only the typed notes.attach_to_event, notes.write, calendar.append, and music.command effects; unknown actions are rejected. It checks the active revision's grant for each real adapter, isolates caller cancellation/disconnection, reconciles an ambiguous promotion by stable transaction ID, and accepts the new scene only when authority returns the exact expected state.

Run it in an existing Wayland session

On a Linux desktop or VM logged into a Wayland session:

./tools/sosctl linux-run --windowed

Omit --windowed for a fullscreen shell surface. The first run creates an ignored content-addressed store at .cache/linux-revisions-v4, installs the complete Stock v4 package and theme module, creates its registry and graph pointers, and boots it through the real supervisor. The command stays in the foreground so host and recovery logs remain visible.

From a second terminal:

./tools/sosctl linux-agent-run --fake .cache/agent-candidates/android-stock-agent.luau
./tools/sosctl linux-agent-prompt "make the active Stock workspace calmer"
./tools/sosctl linux-status
./tools/sosctl linux-stop

The resident authoring broker validates the exact v4 package, migration, and resolved graph before presentation. linux-script remains a trusted local shortcut for a Stock-compatible v4 source and optional state file; it does not create a bare revision. Set SOS_LINUX_REVISION_ROOT to use a disposable or isolated revision store. The boot-owned appliance path below implements the same lifecycle without granting generated code process authority.

The reproducible Debian 13 guest definition, provisioning command, and nested acceptance gate are in linux-vm.md. The authenticated Smithay shell, compatibility-surface policy, input fence, crash recovery, and compositor-owned submit evidence are in linux-compositor.md.

Select SOS from the GDM login screen

SOS can be installed as a selectable Wayland session without replacing GNOME or changing the machine's default systemd target:

sudo apt-get install \
  libgbm-dev libinput-dev libseat-dev libudev-dev libwayland-dev \
  libxkbcommon-dev libxkbcommon-x11-dev
./tools/install-linux-login-session doctor
./tools/install-linux-login-session install

On Fedora, the direct-session module names map to mesa-libgbm-devel, libinput-devel, libseat-devel, systemd-devel, wayland-devel, libxkbcommon-devel, and libxkbcommon-x11-devel. The complete first-hardware dependency recipe is in linux-hardware-gate.md.

Log out after installation. On GDM, select the session menu on the login screen, choose SOS, and authenticate normally. GDM's PAM/logind session remains the seat owner, but sos-compositor replaces GNOME as the session compositor and the experience host is its only ordinary desktop surface. Press Ctrl+Alt+Backspace to end SOS cleanly and return to GDM. Choose GNOME from the same session menu on the next login to return to the conventional desktop.

The installer builds the direct compositor, Linux host, authoring broker, and pinned Node agent in release mode. It installs the session binaries and launchers below /usr/local/libexec/sos, the resident agent below /usr/local/libexec/sos-agent, the reference experiences and API documentation below /usr/share/sos and /usr/share/doc/sos, the per-user sos-session.target and sos-session-shutdown.target, and adds /usr/share/wayland-sessions/sos.desktop. On first installation it also runs the agent's device-code authentication flow as the desktop user; set SOS_AGENT_MODEL before invoking the installer to override the gpt-5.6-sol default. The selectable-session credential helper currently requires the subscription-backed openai-codex provider; API-key providers retain their separate appliance/development configuration. The installer does not stop or reconfigure GDM, change the default boot target, create service users, or enable the appliance units. The first SOS login creates the authenticated user's private revision, authority, recovery, and shell-token state below ${XDG_STATE_HOME:-$HOME/.local/state}/sos; each login receives a fresh private runtime directory below XDG_RUNTIME_DIR.

The experience host keeps the authenticated login's real HOME, XDG_CACHE_HOME, user D-Bus address, and XDG_RUNTIME_DIR, while its compositor socket remains an absolute path in the private SOS runtime directory. This is required for user PipeWire, portals, and other session services. Once the provider and supervisor sockets are ready, the launcher publishes the bounded graphical environment to the user manager and starts sos-session.target. That target binds the standard graphical-session.target; its paired shutdown target conflicts both targets out on logout, so portal and native-application services cannot linger after SOS exits. XDG_CURRENT_DESKTOP=SOS:GNOME permits the standard GNOME and GTK portal backends to participate, although a portal operation that specifically requires a Mutter-only protocol remains unavailable under the SOS compositor.

For an active SOS login, the launcher holds a logind block inhibitor for idle, sleep, and handle-lid-switch around the complete sos-linux-session run-user lifetime. The direct compositor has no independent screensaver, so the stock development behavior is an always-present shell that keeps its network link available and does not suspend when the lid changes. The inhibitor is released automatically on SOS logout and does not change the GNOME session's stored preferences. A future trusted suspend action must first release this session-owned inhibitor as part of its fixed native ceremony; generated Luau cannot remove or bypass it.

The physical acceptance harness owns the earlier GDM gap separately. Its prepare command starts a root transient block inhibitor before logout, and collect verifies and releases it after the fallback display manager returns. This keeps a remotely observed campaign reachable while no SOS session exists; it does not make the SOS launcher or generated code responsible for GDM power policy.

For a credential- and network-independent first hardware gate, install with ./tools/install-linux-login-session install --offline. This configures the same resident runner with the installed Stock source. A prompt traverses the same broker, validation, submission, and monitored lifecycle boundaries but resolves as already_active. It is a hardware isolation mode, not live-model evidence. Running sos-agent-login later replaces that configuration with the normal subscription-backed mode.

Each install writes /usr/share/doc/sos/install-metadata.env and install-manifest.tsv with the source revision, dirty state, toolchain, mode, and installed artifact sizes and SHA-256 values. The session reads bounded mode/scale/rotation overrides and absolute-input output associations from the user's private ${XDG_STATE_HOME:-$HOME/.local/state}/sos/output.json; {} retains preferred mode, scale 1.0, rotation 0, and the mirrored output layout. Mirror mode uses the largest logical canvas that fits every connected output, centers it on each physical mode, and keeps one workspace when a lid or external output appears. Set "layout": "extend" for a connector-sorted horizontal desktop. On a multi-output system, every touchscreen, tablet, or absolute mouse must name its output; ambiguous or unavailable mappings fail closed. Relative pointers stay inside the mirrored canvas or traverse the complete extended layout.

{
  "layout": "mirror",
  "input_outputs": {
    "PiKVM PiKVM Composite Device": "DP-1",
    "ILIT2901:00 222A:5539": "eDP-1",
    "ILIT2901:00 222A:5539 Stylus": "eDP-1",
    "ILIT2901:00 222A:5539 Mouse": "eDP-1"
  }
}
GDM authentication (login user owns the active logind seat)
    -> sos-login-session
        -> sos-linux-session run-user
            -> sos-compositor --backend drm
            -> provider/state authority
            -> revision supervisor
                -> permanent SOS experience host
        -> per-user authoring broker
        -> resident Pi agent

The authoring broker and resident agent start automatically after the provider and supervisor sockets are ready. They are monitored background children of the login session, use the same private runtime directory, and are stopped on logout. If either exits unexpectedly, the session fails back to GDM instead of silently leaving an apparently available composer without an agent. Credentials, model selection, and message history live below ${XDG_STATE_HOME:-$HOME/.local/state}/sos/agent. To reauthenticate or change the exact model before logging into SOS, run:

SOS_AGENT_MODEL=gpt-5.6-sol \
  /usr/local/libexec/sos/sos-agent-login

The installer completes authentication before offering a successful handoff. If credentials are later removed, the SOS login refuses to start and its journal names the login helper rather than presenting a composer backed by no agent.

This path intentionally differs from the boot-owned appliance session's multi-UID isolation. A process launched from a display-manager session must keep the authenticated UID that logind authorizes for DRM and input. run-user therefore rejects root, rejects explicit service-account overrides, and requires the compositor, provider, supervisor, host, authoring broker, and agent to use the current effective UID and GID. Its per-user directories and shell token are private, but processes in that login account are not security-isolated from one another. Use the system session below when the separate service identities are required.

The selectable-session path has completed physical GDM login, direct DRM page flip, provider actions, native application composition, coordinated activation, and clean logout on a Framework Laptop 12 development-live boot. A later 2026-08-27 remote-controlled run added one-host lifecycle and resident-authoring evidence: recovery and two distinct revisions reached DRM page flips, the host did not restart, durable authority agreed with revision 6b3341ee…, and SOS returned cleanly to an active GDM before GNOME session 246 started.

That 2026-08-27 run is not a physical-input pass. Its original gate printed DIAGNOSTIC_PASS, but the controller audit found four hot-added devices named SOS Remote Diagnostic ...; those devices produced the relative pointer, button, and touch markers. The auditor now rejects any input device absent from the libinput inventory captured by preparation, and it correctly reclassifies that evidence as DIAGNOSTIC_FAIL. The semantic and DRM evidence remains useful, but integrated keyboard, touchpad, and touchscreen input stays open. The session also reported active_graph: null, so it did not physically present the reference live-composition graph. Suspend/resume remains open as well.

The gap closed on 2026-08-28 with exact clean source f9085e5fcd26974c88ab002a243a9c708558114d. A PiKVM-driven campaign first passed the complete v4 composition, containment, recovery, authoring, rollback, and GDM lifecycle while remaining labeled physical_touch=not_claimed. A separate same-boot interval then unbound the PiKVM USB HID interfaces before input collection. The compositor observed the built-in keyboard, PIXA3854 touchpad motion and button, and ILIT2901 touchscreen on eDP-1. The standard gate passed with DIAGNOSTIC_PASS promotion_eligible=false. The independently verified 114-file combined manifest has SHA-256 df1bd6e54f814614af7ccb39783df3995508770375938039f3b26e13b7856591. This closes the Framework composition and integrated-input question, but the mutable development-live environment cannot promote a Linux release.

Keep SSH and a text console available, then use tools/linux-hardware-gate and the exact PASS contract in linux-hardware-gate.md. The gate refuses VMs, dirty or revision-mismatched installs, missing observations, input devices absent from the prepared inventory, and tampered evidence. A SOS-baked Fedora Workstation development-live remix is a mutable diagnostic path; it is not an installed product or release-acceptance artifact. See linux-live-image.md.

After returning to the conventional desktop, ./tools/install-linux-login-session uninstall removes the exact installed SOS session/product paths while preserving per-user state, packages, GDM, and the default boot target.

Boot-owned direct session

The packaged session is deliberately one logind session with one Rust lifecycle owner:

sos-session.target
    -> sos-session.service (PAM login on tty1, active logind session)
        -> sos-linux-session run
            -> sos-compositor --backend drm
            -> sos-provider-state-service
            -> sos-revision-supervisor
                -> permanent sos-experience-host

sos-session.service creates private /run/sos and /var/lib/sos directories, conflicts with the display manager and tty1 getty, and asks libseat explicitly for its logind backend. The PAM session is important: merely starting a user process from SSH does not make it the active seat owner. pam_systemd moves the process tree into the active session-N.scope; sos-linux-session run therefore remains the explicit owner that starts, monitors, gracefully stops, and reaps every child. An unexpected provider, supervisor, or compositor exit fails the lifecycle owner and lets systemd restart the whole session on durable authority and the committed revision. A refused stale supervisor socket is removed only after proving that no process is listening on it.

The lifecycle owner also persists exact executable/PID/start-time records. An uncatchable death of that owner is recovered by validating this registry before the replacement session starts; matching survivors are reaped, while already completed logind/kernel cleanup is recorded explicitly. This is necessary because the active PAM tree lives in session-N.scope, outside the service cgroup. PrivatePIDs=yes was rejected after systemd 257 failed its namespace exec step for this PAM/tty topology before SOS started. The current boot campaign kills the lifecycle owner and proves every old-tree PID disappears before accepting the replacement session.

Startup is presentation-ordered rather than socket-ordered. The compositor creates an exclusive readiness record only after its recovery view reaches a DRM page flip. Only then does the lifecycle owner start authority and the supervisor/host. This keeps the trusted recovery surface present before any generated shell can connect. Routine unchanged page flips are trace-level; recovery transitions and armed revision frames remain info-level evidence so a long-running session does not flood journald.

The shell-token source is a root-owned 0400 file. systemd copies it into the service's private credential directory with LoadCredential=, and the compositor and host receive only the credential path. The bounded parser rejects empty, oversized, non-UTF-8, or newline-bearing credentials. The secret is not present in the lifecycle owner, compositor, supervisor, or host command lines or environment values. The compositor/session, provider, supervisor, and generated host run under distinct Unix identities. Per-role credential copies are owner-readable only, and every role child clears inherited lifecycle capabilities before exec.

When real Linux providers are configured, SOS_PROVIDER_GRANTS names a private revision-keyed capability manifest. The host loads the candidate's grants and snapshot before candidate render, switches the live watcher only at commit, and drops events tagged for another revision. A generated interface therefore receives typed data/effects, not provider handles, filesystem paths, network access, or ambient credentials. Development wildcard grants require the explicit SOS_PROVIDER_DEVELOPMENT_GRANTS=1 escape hatch. The selectable session enables that escape hatch automatically only when the baked image identity says both image_kind=development-live and mutable_runtime=true; stable and installed sessions still require exact revision grants.

The first Linux canonical provider slice adapts UPower, NetworkManager, MPRIS, PipeWire/WirePlumber, and freedesktop desktop entries. D-Bus is preferred for stateful services. The narrow wpctl and gio launch adapters pass fixed argument vectors without a shell, and opaque selections are resolved again at action time inside the provider boundary. Stock and generated Luau receive the same model.providers value and cannot observe service paths or commands.

SOS_REVISION_SIGNING_KEY_FILE makes revision installation emit a detached HMAC-SHA256 manifest authenticator; SOS_REVISION_VERIFY_KEY_FILE makes every load require and constant-time verify it. Key files are bounded and must not be group/world accessible. This is suitable for one-owner prototype update and rollback testing. Permanent-host binaries remain distribution/image-owned and must use that update system's signing policy; production revisions should move to asymmetric signatures rather than distribute a shared HMAC key.

The executable link on Debian/Ubuntu requires the XKB development libraries in addition to the usual Rust/GPUI Linux prerequisites:

sudo apt-get install libxkbcommon-dev libxkbcommon-x11-dev

Local evidence

The first nested proof ran on ARM64 Ubuntu 24.04 with Weston 13.0.0. Weston ran with its X11 backend inside Xvfb to supply a real wl_seat; its headless backend has no seat, and the pinned GPUI Wayland client currently unwraps that global at startup. Rendering fell back to Mesa software paths because the user could not open the host render node. That is sufficient functional evidence, not a GPU or latency result.

After rebasing onto Scene ABI v2, the real host booted revision ff63f61d… and emitted a GPUI next-frame event in PID 1527912. It prepared and committed the legacy stateful fixture as revision bc81479e… in the same PID (116 us queue, 1,194 us compile, 646 us render, 1,848 us worker total). It then activated the richer android-exit-agent.luau scene as revision 99ba2162…, exercising layers, shaped glyphs, gestures, and a revision SVG in that same process (26 us queue, 1,936 us compile, 665 us render, 2,608 us total). The deliberately infinite revision 628cb7a7… was interrupted and rejected while 99ba2162… remained accepted in PID 1527912. Killing that host made the supervisor boot the exact committed revision in PID 1528477 and report HostRestarted.

The v3 integration reran the nested proof in the same environment. The host booted f174e726… in PID 1606742, then prepared and presented sidecar-backed revision 728f905e… in that same PID (119 us queue, 874 us compile, 157 us render, 1,039 us worker total). Its 986-byte source tests/fixtures/sidecar-image.luau (SHA-256 3ec9aa6d…) references the checked-in 4,021-byte PNG mipmap-mdpi/ic_launcher.png (SHA-256 11ddafaa…) through the supervisor manifest rather than embedding it in Luau. Infinite revision 632ce86e… was rejected on its Luau time budget while 728f905e… and PID 1606742 remained accepted. Killing the host restarted that exact committed sidecar revision in PID 1607073 with a 1,089 us worker initialization and a new GPUI frame.

The Linux host unit suite also starts the real provider/state daemon on a local Unix socket, commits state plus one typed notes attachment, shuts the service down, restarts it from the durable authority file, and reads the same attachment back through the socket. The combined workspace suite additionally proves that each prepared worker candidate receives its own sidecar set and that the Linux manifest loader carries verified sidecars into the runtime boundary.

The coordinated executable rerun used an isolated Xvfb/Weston seat and store. It bootstrapped authority revision f174e726…, booted the real host in PID 1661845, staged transaction linux-activate-1-552f0696…, and activated revision 552f0696… in that same PID. The worker reported 34 us queue, 1,162 us compile, 654 us render, and 1,825 us total. After activation the durable authority and supervisor current pointer both named the full candidate revision. linux-stop shut down both top-level services, and the exact disposable read-only store was made owner-writable and removed. This was still the ARM64 Ubuntu nested setup, not the Debian VM gate.

The reproducible VM gate then passed in an ARM64 Debian 13.6 guest on kernel 6.12.100+deb13-arm64, provisioned from the verified official generic image. Weston 14.0.2 ran inside Xvfb 21.1.16 with Mesa Vulkan 25.0.7. The real host booted f174e726… and initialized its worker in 3,635 us, then activated 552f0696… through linux-activate-1-552f0696… in unchanged PID 3874. That candidate measured 374 us queue, 1,147 us compile, 651 us render, and 1,807 us worker total. The exact authority revision and supervisor pointer matched after the GPUI frame and confirmation. This completes the functional client-host VM gate, not a GPU, compositor-presentation, or latency gate.

The boot-session gate then rebooted that same VM with sos-session.target as its default while seatd was disabled. logind reported active Wayland session 1 on seat0/tty1 with lifecycle PID 770 as its leader. The host booted in PID 883, activated 552f0696… in that same PID, and recovered the killed host in PID 1089. Boot, activation, and recovered boot produced DRM-backed commit/submit pairs 1/3, 43/11, and 50/19. Killing the provider failed the lifecycle owner; systemd restarted it once as PID 1222, removed the refused stale supervisor socket, and booted the committed revision in host PID 1312 with a new 1/3 page-flip fence. The verifier then rebooted to graphical.target, confirmed GDM and seatd, and removed its exact units, binaries, credential, and state.

Completed Linux envelope

The permanent Linux host now has the following platform adapters around the same Scene ABI and worker:

  • compositor/client wl_touch transport into the shared multi-pointer router, plus a compositor-owned cursor and direct-libinput VM campaign;
  • a compositor-restricted sos-input-method input-method-v2 client with pinyin preedit/candidates/commit, candidate selection, dead acute composition, keyboard grab, popup rendering, and cursor rectangles;
  • end-to-end Wayland data-device clipboard ownership for copy, cut, and paste;
  • Markdown notes, iCalendar, JSON/MPRIS music, and Linux time, connectivity, PipeWire audio, battery/AC, DRM-display, and input-device snapshots with revision-scoped grants, live generation events, typed writes/commands, cancellation, disconnected-client isolation, and explicit unavailable errors;
  • capability-scoped video/camera frame surfaces backed by provider-owned atomic PNG/JPEG/WebP updates; protected content is represented but deliberately remains unavailable because this prototype has no secure scanout path;
  • an SOS-owned Unix semantic service for traversal, semantic focus, activation, scrolling, editable text/selection/clipboard actions, status changes, and automation waits;
  • a direct compositor recovery panel showing current/previous revision, progress and failure, with restart, rollback, safe-mode, and provider-disable controls. The lifecycle owner republishes status after ordinary activation;
  • connector/DRM-device rescans, libseat pause/activate handling, live output mode/scale/rotation configuration, simultaneous outputs, input hotplug, child/host/lifecycle-owner recovery, clean stop, and durable authority;
  • executable resource-free WGSL paint through a capped offscreen target and an opt-in bounded rootless XWayland compatibility service;
  • private revision grant manifests, bounded Luau execution, a restricted systemd unit, scoped shell credential delivery, and optional detached HMAC-SHA256 revision-manifest verification.

tools/linux-compositor/verify-nested proves the IME, clipboard, provider, accessibility, activation, abort suppression, and host-recovery interactions in one campaign. tools/linux-vm/verify-direct-session uses kernel uinput keyboard, relative-pointer, and two-contact touchscreen devices through direct libinput, including held inputs across successful and aborted activations. tools/linux-vm/verify-boot-session boots the appliance target, invokes the recovery rollback channel in both directions, drives the packaged resident agent through context, validation, submission, and visible completion, exercises VT pause/resume, s2idle freezer recovery and output hotplug, kills/restarts the host, kills a provider to restart the whole service, and restores GNOME afterward. Focused development runs may stop after the agent or lifecycle phases with SOS_BOOT_GATE_STOP_AFTER_AGENT=1 or SOS_BOOT_GATE_STOP_AFTER_LIFECYCLE=1; neither marker substitutes for the complete gate.

The 2026-08-27 x86_64 Debian 13 campaign completed the full gate in 57.952 seconds on kernel 6.12.101+deb13-amd64. The resident faux Pi flow activated revision 431f6687… with DRM page-flip evidence, and the later activation/recovery campaign ended on revision 578c1f5a…. The lifecycle owner moved from PID 878 to recovered PID 1877 and then PID 2146 after the intentional service failures; the host moved from PID 1005 to 1764 and 1957. Every service identity remained separated, GDM and seatd were active after the restoration reboot, and the disposable SOS installation state was absent.

The same campaign closed two races exposed by the stricter sequencing. First, DRM master could disappear before libseat delivered its pause event; only the explicit inactive/permission-denied commit result is now deferred until seat activation. Second, an asynchronous model render or candidate commit could restore prepare-time agent, shell, or appearance fields over newer live state; both completion boundaries now re-merge those host-owned channels. The focused agent and lifecycle reruns passed before the complete campaign was accepted.

Honest remaining boundaries

  • An ordinary linux-run still uses GPUI's next-frame callback. Nested compositor submit evidence cannot prove that its outer compositor displayed the buffer. Direct mode waits for DRM VBlank, but only physical hardware can turn that into a panel/touch latency claim.
  • Core wl_touch does not carry finger pressure; tablet-v2 transports stylus pressure. Framework touch routing passed, but calibration accuracy and touch/stylus coexistence remain unverified.
  • The VM proves libseat pause/resume, s2idle kernel freezer suspend/resume, connector removal/reconnect, two simultaneous VirtIO outputs, and live mode/scale/ rotation. The Framework development-live campaign proves physical Intel DRM, panel presentation, and built-in keyboard, touchpad, and touchscreen input. Full platform sleep/wake, physical hotplug, measured GPU/panel performance, memory pressure, latency, thermals, and power remain unverified.
  • The prototype service processes have distinct Unix identities, executables, owner-managed sockets, peer checks, scoped credentials/capabilities, and zero effective child capabilities. Fine-grained MAC policy and production secret rotation remain hardening work.
  • HMAC manifests provide prototype authenticated rollback/install control, not public-key distribution or a production permanent-host update system. A production image should use distro/immutable-image signing for the host and asymmetric revision signatures.
  • XWayland is deliberately opt-in and bounded; it is compatibility, not a promise to integrate every legacy application or protected media stack.
  • Provider frames are functional image updates, not zero-copy decoded video; protected playback, camera capture ownership, and secure scanout require a concrete provider/device integration.

The Linux integration prototype is complete at VM scope and has physical development-live diagnostic evidence on the Framework Laptop 12. Installed or immutable release promotion, the measurements above, and production security remain open.