Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity
SouveraineOS/docs/DUMP-bugs-2026-08-06.md
Fimeg 528d290ba6 59/60 and the bug dump: what landed the day her face went on the glass 
TASK-59 becomes a record of five bugs that each presented as something else —
the missing #live_talk element, --app-id doing nothing, the GL context claimed
before the canvas was sized, posture wired to a function that does not exist,
and a feed that dropped its own reader for being slow. Plus the furniture role,
input regions, gaze, and what the rig costs next.

TASK-60: the cards were zero pixels wide, and the capture-hang theory is
retracted — the session had been left locked by a test.

DUMP: 3/4/5 closed, 7 retracted with the trap that produced it, 8/9/10 new.
2026-08-07 02:29:37 -04:00

6.4 KiB
Raw Permalink Blame History

Bugs & micro-regressions — 2026-08-06

Collected from the nightly snapshot and the two 2026-08-05 sessions. Each entry is self-contained (what, where, severity, fix direction) so a fresh model can carry it out without re-deriving context.

Runtime / session

  1. sessiond is dead on the phone. systemctl --user status souveraine-sessiond → inactive (dead), unit disabled, as of the 2026-08-05 nightly check. This is the daemon that decides lock/unlock and answers the shell. First step is to confirm it is not a stale snapshot artifact (the unit may have been disabled deliberately), then restore it. Severity: high if real.

  2. viewtop r86 installed, r84 is the live process. PID 327005 /usr/bin/viewtop --kms, started 17:45 before the upgrade. Consequences: the shell's subscribe is refused (it logs once and falls back to polling), and the float/gamma verbs are unreachable. Fix: session restart; then verify subscribe pushes actually arrive (the shell logs a refusal when it does not). Severity: medium — everything works, at polling speed.

  3. Avatar renders nothing on hardware (pre-r360). The loopback origin fix is pushed (3d3eb2c), CI run 1195 green, published as souveraine-0.1.r360. Verify after the update + session restart: double- tap the desktop clock → the rig should actually draw. If it still does not, capture the host's stderr — Face.qml currently drops it. Severity: medium, awaiting hardware verification.

Placement

  1. A second app splits instead of minting a new zone. zone_for_new_window, souveraine-viewtop/crates/compositor/src/ wayland.rs:4164: a mapped toplevel claims the active zone unless it is home, so app #2 tiles onto app #1. Desired: when the active zone already holds a window, workspaces.push() a fresh zone and move there. The whole change is inside that one function. Severity: high, user-visible every multi-app session.

Recording

  1. Unknown whether viewtop serves wlr-screencopy. The ext-* capture globals are served (wayland.rs:721–727), copy_output_into exists (wayland.rs:1332), but zwlr_screencopy_manager_v1 was never found in greps. Phone has grim + slurp; wf-recorder missing; ffmpeg has x264/x265/vaapi/v4l2m2m encoders. First step: answer the protocol question (user: "I do have some screencopy protocol"). Then either serve the global or ship a recorder that speaks ext-capture. Severity: medium, this gates the radial-dial record entry.

Resolved 2026-08-07

Items 3, 4 and 5 are closed, and item 7 below turned out to be a false lead.

  • 3. The avatar renders nothing — FIXED. Not the loopback origin. The page omitted #live_talk, which the bundled character layer reads every frame; it threw on the first update after the model and all four textures had loaded. See TASK-59's 2026-08-07 section for the five bugs in that chain.

  • 4. A second app splits instead of minting a zone — FIXED and verified. Three apps → zones 1/2/3. The fix (60ff764) had been committed and never pushed, so the phone had never had it. The null app_id/title in the workspaces report was real and is also fixed — the report calls them "the join key" and nothing had ever written them — but it was not what broke the cards (see 7).

  • 5. Does viewtop serve wlr-screencopy — YES. grim works. It hangs only behind a lock, which is the capture gate doing its job.

  • 7. Screencopy hangs / the cards are blocked on it — WRONG, and here is the trap. The compositor was refusing captures with "no client captures the screen behind a lock screen" because the session had been left locked by a test, while logind reported LockedHint=no. Check locked in state before concluding anything from a capture failure. The cards were zero pixels wide; see TASK-60.

New, 2026-08-07

  1. The pill strands a pose. A partial slide up leaves the app scaled small and it takes another pull on the pill to get it back. onCanceled already exists on the rail and already calls endPull(false) — that is not the hole, and a duplicate handler added there fails the whole QML module ("Property value set multiple times") and takes the shell down. Cause unfound. Casey also wants the partial slide gated on speed and length and then committed, iOS-style, with no backing-off state at all.

  2. Side panels glitch on the way out. The keyboard half is fixed — the drawer cleared oskOpen on close and SidebarLeft never did, so the OSK outlived the only text field it was serving. The visual glitch on leaving is still uncharacterised.

  3. The terminal cannot keep the keyboard. It disappears while the cursor is in a field and the right panel closes with it. Note a terminal never requests text-input so the OSK must be summoned, and oskOpen flaps by design because the OSK self-hides whenever input-method focus drops — never gate a persistent surface on it. Being the mirror image of 9 suggests one focus-handoff bug, not two.

Recording — narrowed 2026-08-07 (superseded by "Resolved" above)

  1. Screencopy hangs while mission control is open, and that is why the cards never appear. Measured on blueline: grim returns a file in under a second normally, and with mission control up it produces no file, no error, and does not exit. The cards are ScreencopyView against each toplevel — the same capture path — so they wait on pixels that never come and the surface renders as blur with nothing in it.

    It is not missing data. The new overview state verb answers {"zones":2,"windows":1,"subscribed":true} with a window open, so ViewtopControl has the model and the join key. Item 4's null app_id/ title was real and is fixed, but it was not this.

    It is specific to mission control, not to a fullscreen layer surface. The app-grid overview captures fine with the same panel covering the screen. The difference is that mission control is the only surface that opens ScreencopyView sessions — so the hang correlates with live capture sessions existing, not with what is on top.

    Next: capture_window_for / render_capture in wayland.rs, and what happens when several sessions are live at once. A capture that waits on a frame the render loop is not producing would look exactly like this.

Unpacked from the user (pending)

  1. Your list goes here.