7 Commits

Include renames

Author	SHA1	Message	Date
jochen	5d7d9020b8	Say the laptop's scripts unparsed where the build seat has no bash ... The Go toolchain the repository check runs in carries no bash, so the scripts' syntax check failed there on a missing interpreter, not a broken script.	2026-10-08 16:20:45 +02:00
jochen	0040c008b5	Let the bar render blocks other modules contribute, and give it the battery and power draw from the power module (hq ADR 0255) ... The bar left the battery out because it belongs to whoever knows the hardware, and had no way to take it back in. i3status-rust now renders bar-neutral blocks through its template; the power module contributes the battery where the machine reports one and the power draw where something measures it, sampling the root-only energy counter as root and publishing only a rate. The memory block shows what programs hold, the figure memory-pressure judges by, instead of counting the cache as used.	2026-10-08 16:12:37 +02:00
jochen	1d4de00603	i3: other modules' lines are contributions to node-display-session (hq ADR 0212) ... rofi, clipmenu, feh, i3status-rust and the laptop's model module wrote files into i3's config.d, naming no dependency on the window manager. They now contribute their lines; i3 places them under a line naming each module, and config.d is the operator's alone. The catalogue-wide test composes the contributions as the controller does and checks the whole with i3 -C.	2026-10-05 10:11:27 +02:00
jochen	6315556152	power: a machine's power as a module holding node-power; the laptop's resume and lid move onto it (hq ADR 0211) ... Code around sleep was written into the service manager's sleep units by the module that needed it, and the mesh could not tell a sleeping machine from a lost one. power runs every module's code for the six moments, each piece bounded, owns logind's power handling from its settings, and says booted, sleeping, woke, shutting-down and the power source on the bus, sleeping under logind's delay lock before the machine sleeps.	2026-10-04 17:19:27 +02:00
jochen	afce6b03f4	triggerhappy: the machine's hotkeys as a module holding node-hotkeys (hq ADR 0212) ... The laptop's model module owned triggerhappy's trigger file and service, although the daemon is a general piece others have keys for. triggerhappy now owns the daemon, reads only the mesh's file, runs every trigger as the account, and the model module contributes its vendor keys.	2026-10-04 16:50:57 +02:00
jochen	1059f12ee0	asus-zephyrus-g14: the laptop's keys, scripts and i3 lines are the module's, with a resume backstop ... The i3 and laptop READMEs each pointed at the other for 10-asus.conf and 20-g14.conf, so nobody owned them. The module now writes both (adopted paths, so no duplicate binding breaks i3's config check), ships the scripts they call, runs the media keys with notifications again, and brings back the touchpad reset after resume as a unit the sleep services want. zephyrus_keys answers what each custom key runs; the check flags as-user, thd's account and the resume unit. xorg-xinput is the xorg module's.	2026-10-04 15:49:46 +02:00
jochen	b098b64b22	Phase 3: asus-zephyrus-g14 and memory-pressure, with Go tools and long-running code ... The laptop model's hardware module and a memory-pressure module for any machine (hq research 027/03, 026/05, to-be 42 phase 3). The predecessor's polling auto-profile and mem-guard user scripts become each module's own Go code launched by the node runtime (ADR 0198): a profile switcher woken by the kernel's power-supply uevents, and a guard that warns on RAM, swap or PSI before systemd-oomd acts, on the desktop over the account's bus and always as an event. supergfxctl and triggerhappy are kept as found (research 027 Q1).	2026-10-04 15:42:56 +02:00