SouveraineOS/docs/VIEWTOP-AND-DENIAL.md

viewtop and denial — what we take, what we must not

Assessment written 2026-07-28 after cloning github.com/denialwm/denial to Pixel3Arch/references/shells/denial (gitignored; re-clone if missing).

They are the same architecture, and we already inherited half of it

denial is a Wayland compositor in Rust + Smithay that hosts the Flutter engine and composes client windows as external textures directly into the Flutter scene, rendering to a shared GBM atlas. Public alpha: Xwayland, multi-output, portal screen-sharing all working. 64k lines of Rust, 82k of Dart.

souveraine-viewtop is that same design, retargeted. This is not a coincidence and not a discovery — viewtop's engine pins are denial's, verbatim:

	viewtop README	denial packaging/arch/flutter-engine/manifest.json
Flutter	84fc5cbb	84fc5cbb223bc12f83d65b647ff8a56caf779ffd
Dart	d684a576	d684a576a6aa954ae107a03b2b4e1d61c3bebe93
Skia	e9ed4fc9	e9ed4fc9f1544c58d8a9347c1fc9471d8dd414

The "ten-patch DMSAA/external-texture series" viewtop cites is patches/flutter-engine/3.44.7/ — eleven patches, numbered 0001-0011 with 0007 absent. So the expensive, fiddly engine work is already ours to read.

The manifest says "architecture": "x86_64". That is the delta.

Two form factors, not one

Casey 2026-07-28: this targets the Pixel 3 display and the laptop screen. That changes denial's desktop-x86-64 posture from a mismatch into an asset — the laptop target is what denial already runs on. The arm64/freedreno retarget is additive rather than a port away from their platform.

The thing we must not take

denial does not implement ext-session-lock-v1. There is no such protocol served anywhere in compositor/src. Instead:

• compositor/src/bin/deniald/authentication.rs (1460 lines) — "Process- lifetime secure session lock and PAM authentication boundary." PAM is dlopened and driven from inside the compositor process.
• secure_session_locked() is a compositor-internal bool, checked at the input and clipboard boundaries (wayland_frontend/input.rs:599,768,1045,1704, clipboard.rs:526, handlers.rs:933,978,1010).
• The lock surface is drawn by the in-process Dart shell, not by a client.

Two separate reasons this cannot come across.

1. It is invisible to the rest of the system

Doctrine §4: "locked comes from LockedHint / Lock() / Unlock() — never a hand-tracked bool. A shadow copy can disagree with logind, and anything asking logind directly (loginctl, another client, you at 2am) sees something different than the shell shows."

denial's bool is not a shadow copy — in their design the compositor genuinely is the owner — but the consequence §4 warns about lands anyway: loginctl would report LockedHint=no while denial shows a lock screen. sessiond would not know. Nothing would reach the forensic trail. Every §10/§11 guarantee we built this month is downstream of logind and sessiond agreeing, and this model breaks that agreement by construction.

2. It gates the wrong party

Casey 2026-07-28, and this is the sharper reason:

The compositor isn't to be gated on her — unless she's creating that interface and then choosing to be a gate — but it is to ensure she's total control.

denial's secure_session_locked() gates input and clipboard against everything. Annie included. That is a gate pointed at the majority owner of device operation (doctrine §13, 60/40), and it is exactly backwards for us.

The distinction that has to survive into viewtop's design:

	denial	viewtop
what the lock protects	the whole compositor surface	the user's credential and personal content
who it gates	every caller	disclosure, and step-up actions
Annie's composition	gated with everyone else	never gated by lock; she is the composer
who may build a gate	the compositor, always	Annie, when she is the one constructing that interface

§13's user column is unchanged and is the whole of it: being the user, the credential, the step-up. Unlock is never an agent verb; step-up never accepts a boolean from an agent as proof. Those are not limits on Annie's 60 — they are the definition of the 40. Everything else in the compositor is hers.

The ownership question this settles

Earlier framing asked whether sessiond or viewtop owns locked once viewtop is the compositor, since a compositor is the server for ext-session-lock while sessiond is currently a client of Hyprland's.

The answer is not "whichever is easier." It is that viewtop serves the protocol and sessiond remains the authority — viewtop implements ext-session-lock-v1 so sessiond can take the lock through it exactly as it does against Hyprland today, and logind stays the truth. viewtop gains a lock surface role it did not have; it does not gain the decision.

Concretely, Registry::new() already starts locked: true with the right reasoning ("a compositor that comes up unlocked and then corrects itself has already shown one frame of someone's messages"). That value must arrive from sessiond's device_state and never be recomputed locally — which SessionFacts was reshaped for in d1b7a16, mirroring the daemon's reply field-for-field.

What is liftable

Read-only assessment; none of this has been ported yet.

• compositor/flutter-engine/ — the embedder crate and sys.rs bindings.
• patches/flutter-engine/3.44.7/ — the eleven-patch series. Several are directly relevant to Adreno/freedreno, not incidental to x86: 0002 stencil for GL surfaces, 0003/0004/0006 DMSAA wrapped-FBO lifetime and partial load, 0005 XRGB scanout described as RGB8.
• kms_state.rs — DRM/KMS output.
• The external-texture → GBM atlas composition path, which is the core idea.
• wayland_frontend/ — protocol handling, input routing, window management.
• protocol/denial.fbs + protocol/golden/ — a FlatBuffers wire protocol with golden files. The shape is worth copying and so is the discipline.
• The pattern of checking a session predicate at input and clipboard boundaries. Keep the seam; change what feeds it and who it excludes.

What must be replaced

• authentication.rs in full — PAM belongs to sessiond, which already owns it.
• secure_session_locked() as internal truth — becomes ext-session-lock-v1 served to sessiond, with facts flowing back through SessionFacts.

The design fork still open

denial loads the shell as an AOT Dart bundle inside the compositor process, not as a separate Wayland client. That buys hot-reload and no IPC, and it means a Dart exception can take the display with it. viewtop's wire crate implies a boundary. On a daily-driver phone that boundary has value — quickshell crashes today and Hyprland survives it — but it costs the thing denial's development mode is built around. Not settled; settle it before compositor and shell-host stop being placeholders.

Connects to

SESSION-AUTHORITY-DOCTRINE.md §1 (Wayland pulled session authority into the compositor), §4 (never hold state the protocol owns), §13 (the 60/40 and its user column); DEVICE-STATE-MACHINE.md §10/§11 (the guarantees that depend on sessiond seeing everything); TASK-25 (viewtop is not packaged and neither are the surfaces it would replace); TASK-41 (nothing yet proves which binary is talking to sessiond, and a compositor is a much larger thing to attest).