rope/nixos
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Make boot greeter frameless and match Gaming display mode

Browse source
This commit is contained in:
rope 2026-09-14 19:37:31 +01:00
parent 7bc5a4c852
commit 0eaf97d134
4 changed files with 47 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/failure-path-fixes.md
View file

@ -61,6 +61,10 @@ nix eval --raw path:.#nixosConfigurations.FredOS-Mediaserver.config.networking.n
The new greeter takes effect on the next login or boot. It supports the configured password authentication; unusual PAM conversations such as forced password changes require a text console. The independent locker starts on the first lock request. Restarting that locker reacquires the lock, while ordinary bar reloads leave it alone.
The boot greeter explicitly disables window decorations and rejects window-close requests. On Gaming, its Cage client applies the first desktop monitor rule's output, mode and scale before launching Quickshell (currently DP-3, 3440x1440 at 180 Hz, scale 1). This avoids maintaining separate greeter and desktop mode settings. The mode command is bounded to five seconds plus a one-second kill grace; an unavailable connector or mode is logged and login continues using Cage's current mode. MacBook retains its preferred-mode behavior. Switching compositors can still cause a brief display transition.
The greeter test verifies close rejection, frameless flags, password failure/retry and authenticated exit. The generated Gaming client was also checked with successful and failed mode-command fixtures to verify ordering and fallback. Both desktop configurations evaluate and both auth bundles build; the physical 180 Hz handover still needs checking on Gaming after deployment.
If media storage is unavailable, restore and verify the missing disks first, then start the affected media services. Their dependencies retry mounts and directory preparation. Services deliberately stay stopped after losing storage; they do not automatically resume merely because a disk returns. Inspect `journalctl -u media-storage-ready` and `systemctl status mnt-storage.mount` when diagnosing this.
The shared deployment transaction is documented separately in [deployment.md](deployment.md).