52301084a58a819db5c233520964b435a466f621
17
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ekklesiaandClaude Opus 5
|
52301084a5 |
feat: an external-only display mode, chosen rather than inferred
The women's Bible study laptop is a fixed appliance: AC power, battery out, lid shut, one television on HDMI. Its own panel should be off. DISPLAY_MODE=external-only says so, and it is a setting rather than something inferred from having a lid, because another laptop may want its own screen or both. Nothing reads DEVICE_TYPE to decide it. The built-in panel is identified by kscreen's output TYPE — 7 is Panel — rather than by connector name. Matching "eDP-1" would be matching one machine's spelling: eDP, LVDS and DSI are all internal, numbered differently per driver and renamed between kernel versions. The names are kept only as a fallback for a driver that reports no type, which some virtual devices do. One rule overrides the setting: never leave the machine with no screen. A laptop asked for external-only whose television is off keeps its own panel and says so in the journal. A machine nobody can see is one nobody can fix standing in front of it, and it corrects itself the next time this runs with the set on. Only the outputs that are not already right are touched, so a television power cycle is not a stream of mode sets. Applied at login from an autostart entry named to sort before the scale one, so the scale lands on the displays this leaves enabled. The lid itself needed no new code — logind ignores every lid event, PowerDevil's lidAction is 0 in all three profiles with triggerLidActionWhenExternalMonitorPresent=false, the profiles are immutable and the classroom account cannot reach suspend through polkit. That was all already true for towers. What was missing was a test saying so, and there is one now, because it is the property the laptop depends on and nothing would have noticed it regressing. KNOWN LIMITATION, and it is written into docs/testing.md rather than left to be discovered: the mode is applied at login, not continuously. If KWin re-enables the internal panel when the television is power cycled, it stays enabled until the next login. The lab has no lid and no HDMI hotplug, so this cannot be settled here; the physical procedure says to check it specifically, because the answer decides whether the follow-up needs an event-driven applier like the audio policy's. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
27cd64a668 |
fix: the room asks for its output again, not only once at boot
River Kids came up silent on stable 0.2.2. The decision this policy makes
was right and was never asked for.
classroom-audio applied its policy once at startup and then only when a
PipeWire event arrived. pactl talks to PipeWire's PulseAudio server, and
the unit was ordered after pipewire and wireplumber but not after that.
At boot it therefore raced the server and lost: the single startup apply
failed with "Connection refused", the subscription attached cleanly a few
seconds later, and from that moment the daemon waited for an event that
had already happened. systemd said active, the subscription was live, and
the policy had never run at all.
That is why the card was found on output:analog-stereo+input:analog-stereo
with its HDMI port available. That profile is WirePlumber's own pick, not
one this policy would ever produce, which is the evidence it never ran.
Reproduced in the lab against real PipeWire 1.4.2 and WirePlumber 0.5.8 by
starting the daemon with pipewire-pulse stopped and then starting it: the
old daemon sits idle forever, the new one converges.
The shape is now: wait for the server, apply, subscribe, apply again the
moment the subscription attaches, and coalesce each burst of events into
one decision. Applying on attach is the fix for the race. While the room
has not got the output it would prefer it also looks again on a backing
off timer capped at a minute, so a television switched on hours later is
picked up whether or not ALSA's jack change ever reaches us as an event.
Once the room has what it wants it stops looking entirely, and a machine
with no digital output never looks at all.
Also here, all of it found by measuring the real server rather than
reading the code:
* sink lookup matched on fields a sink does not have. Two of its three
conditions could never be true; the one that worked returned whichever
sink of the card came first rather than the one for the chosen port.
* volume and mute are no longer touched. The old code unmuted and forced
70% on every output change, so every television power cycle reset a
volume the teacher had set and could unmute an output muted on
purpose. WirePlumber already remembers volume per device. A machine
this policy has never configured still gets 70% once.
* the profile chosen keeps the card's input, which is the difference
between output:hdmi-stereo and the output:hdmi-stereo+input:analog-stereo
an administrator reaches for by hand.
* a card profile is only set when it is not already in place, and only
so many times, so a sink that never appears cannot become a switching
loop.
* a machine with no sound server at all says so once and backs off,
rather than filling the journal. pactl subscribe's own stderr is
dropped because saying it is this daemon's job, and a subscription is
only treated as healthy once it has lasted, since pactl starts
successfully and then fails to connect.
* the fixtures described a machine nobody has. Real pactl puts no
"direction" on a port at all and says "availability unknown" rather
than nothing, so a test could not have caught this.
Existing streams are moved explicitly. Measured both ways on the real
stack: changing the default sink does move a stream that never asked for
a particular sink, but a stream pinned to a device stays where it is with
no policy running, and this moves it back without the application being
restarted.
tests/test-classroom-audio-daemon.sh drives the real daemon through the
boot race, a television switched on with and without an event announcing
it, a power cycle, a set that never comes on, and a room already correct.
It uses a pactl mock because no loopback or dummy sound driver has an HDMI
port, so the one thing a lab cannot prove is that the real jack change
arrives; docs/testing.md carries the physical procedure for that and says
not to take a passing build as evidence of it.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
ekklesiaandClaude Opus 5
|
f65c814eff |
fix: put the popup close button in the dock, and clear the printer location
Three things, none of them redesigns. The close affordance for a secondary Chrome window was a separate layer-shell surface anchored to that window's corner, repositioned by a five-per-second poll. Any position change tore the surface down and built another, so on real hardware it chased the window and flickered. Removed entirely: the GTK button process, the geometry maths that placed it, the --close-button mode that spawned it, and the poll loop that drove it. The window helper no longer imports GTK at all. The behaviour underneath it was right and is kept. The first Chrome top-level is the classroom browser, tiled and borderless; later ones float centred at about three quarters of the output. Creation order is the only thing that can tell them apart — confirmed on a real session, where every Chrome top-level shares app_id, shell, PID and a null transient_for, and sway exposes no window properties for Wayland toplevels at all. Titles are still not used. It now follows sway's own window events instead of polling, so dragging a popup costs nothing. Close moved into the dock, which was already on screen and does not move, so it cannot chase anything. It appears only while a secondary window is focused and runs kill on that one container. The helper publishes which window that is; the dock watches the file rather than polling. A stock sway title bar has no close button, so restoring the border would not have solved this either. Two bugs found by looking rather than by testing state. Chrome renegotiates the size of a popup opened with explicit dimensions after the resize returns, which left windows centred for a width they no longer had; placement now settles and repeats once, at creation only, so dragging is still free. And the dock's Close button came up empty because show_all does not recurse into a no-show-all widget. The printer's Location is now blank. CUPS prints it under the queue name in every dialog, so "Ekklesia Classroom" was a second line the teacher had to read past; the identity is one word. The already-configured check includes Location, so a machine set up before this is corrected rather than left as close enough. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesia
|
7f66228b9e | Release 0.1.37 deployment prep | ||
|
ekklesiaandClaude Opus 5
|
dfd42f6fdf |
feat: give the rooms a line to the church broker
The first piece of turning these machines into connected endpoints. classroom-mqtt is one small service per room that subscribes, validates what arrives, and hands the work to commands that already exist. Nothing in the room depends on it. A broker that is down, a network that is missing, a machine with no broker configured at all — each is a service sitting quietly, not a classroom that fails. Nothing waits for it at boot and the shipped default is off, so every existing classroom upgrades into this release with messaging disabled until a broker exists. The room is the hostname, which is already how these machines are named. Topics carry no product name because the broker is the church's and these are just rooms: classroom/notify/all, classroom/notify/<room>, and a retained classroom/status/<room> so anyone asking later can be told which rooms are up without waiting for them to say so again. Notifications are events and are never retained; status is state and is. Stale messages cannot come back, which is the property that matters most and has two halves. The session is clean, so a broker never hands over a backlog from while the room was off. And retained notifications are refused on arrival, because otherwise one would replay into every room at every reboot forever. The honest limit is written down: MQTT only flags a retained message when it is replayed to a new subscription, so a retained publish delivered live is indistinguishable from an ordinary one and is shown once — which is right, since it is live at that moment, and the replay is the actual hazard. Delivery reuses the session-aware sender rather than a second copy of it. classroom-notify-test grew into the real thing, so it is now classroom-notify with the sample sender a wrapper over it, and its 36 tests came along. The broker password lives in device.conf, so that file stops being world readable: 0640 root:classroom, which everything that reads it already satisfies. Transport logic is kept free of any broker library so it can be tested without one — 40 checks on room identity, the topic contract and which payloads become notifications. Separately verified against a real mosquitto: connect, subscribe, retained status, per-room and all-room delivery, urgency, duplicate and expired and malformed messages ignored, the broker killed with the daemon surviving, reconnect, and a stale retained notification left on the broker not reaching the screen when a room boots. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
a1a218b29f |
fix: draw classroom icons at the display's real pixel density
Icons went soft under UI_SCALE while the clock text beside them stayed sharp, which is visible on a 24" monitor even if it hides on a TV. new_from_file_at_scale rasterises an SVG at its *logical* size. The artwork is vector, but by the time sway scaled the session it was already a fixed raster, and the compositor enlarged that. Text never had the problem because GTK draws it at the real density. GTK 3 has no fractional scaling, so sway advertises the ceiling integer scale and scales the finished buffer down. Measured under sway: scale factor 1 at output scale 1.0, and 2 at 1.25, 1.5 and 2.0. So each icon is now rasterised at size x scale_factor physical pixels and handed to GTK as a cairo surface carrying that device scale. The icon lands at the real density; its logical size, and the whole dock layout, is unchanged. Icons redraw on notify::scale-factor as well as at realize, since the scale factor is not known until a widget is on a display and changes if UI_SCALE is changed under a running session. Browser, DVD, LIVE and all six DVD control icons go through it, in a shared module so the dock and the DVD session cannot diverge. The throbber is drawn rather than loaded and had the same flaw, so it draws on a device-scaled surface too rather than being the one soft thing left in a sharp dock. The artwork is untouched. Verified by rendering the dock under sway at 1.0, 1.25, 1.5 and 2.0 against the previous build: apparent icon size is identical at every scale (28, 35, 42, 56 px), 1.0 is unchanged pixel-for-pixel, and peak edge contrast on the Chrome icon goes from 60 to 99 at 1.25, 49 to 83 at 1.5, and 37 to 82 at 2.0 out of 255. The DVD control bar was checked the same way. Also records that Wonder Ink session-only cookies are confirmed working on the endpoint, which settles the question 0.1.34 shipped as unverified and tells us the session is in cookies rather than localStorage. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
0b2f99a853 |
feat: make Chrome a room appliance rather than somebody's browser
A classroom computer is shared. There is one local Chrome profile owned by the room, teachers sign into websites, and nobody signs into Chrome. BrowserSignin=0 stops Chrome asking who is using it, with SyncDisabled set explicitly alongside it so the intent is in the file rather than implied. BrowserAddPersonEnabled=false stops new profiles and ProfilePickerOnStartupAvailability=1 stops the picker. BrowserGuestModeEnabled=false is the answer to the other profile switching entry point. Guest is the one that survives disabling add person, and turning it off is the supported mechanism rather than hiding UI. Guest is not the browsing model: the room needs one persistent profile so the church YouTube login survives. CookiesSessionOnlyForUrls scoped to [*.]wonderink.org, which covers app.wonderink.org and every other subdomain, so a teacher's Wonder Ink session does not outlive them. BackgroundModeEnabled was already false, which is what lets a session actually end. Every policy name was checked against the strings of the installed Chrome 152 binary, with deliberately invalid names as a control so the check is known to discriminate. Two things are recorded honestly in docs/browser.md rather than claimed. The avatar button stays in the toolbar — screenshotted with and without these policies, it is in the same place either way; what changes is that nothing behind it can create or switch a profile, and no Chrome 152 policy removes the button. And whether session-only cookies actually sign Wonder Ink out is unverified: it needs a real Wonder Ink login, which this machine does not have, and three attempts to prove the mechanism against a local site were inconclusive because the positive control never worked. The endpoint procedure to settle it, including how to tell a cookie session from a localStorage one, is written down. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
8ba04801a7 |
docs: record the Wonder Ink Present view observation
Vimeo plays in the normal lesson view and stops immediately in Present view, which rules the machine out: same video, same host, same codecs, a click earlier. No packages were installed and nothing was changed. Written as a decision procedure rather than a shrug. The first step is a stock Chrome with no classroom policy and a clean profile, which settles in one run whether this is Wonder Ink or something at our end. Two candidates follow if it turns out to be ours, each with the diagnostic that would confirm it, and the note that AutoplayAllowlist is recognised by Chrome 152 but has deliberately not been applied — allowing autoplay on a classroom machine should follow evidence rather than a guess. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
8bed3d186a |
feat: scale the whole session, not just the classroom's own windows
UI_SCALE only ever reached the surfaces we draw ourselves. Chrome stayed tiny — its tabs, omnibox and menus are Chrome's own pixels, and Ctrl+ only scales page content, which is no use to a volunteer reading a toolbar from across the room. UI_SCALE is a property of the television, not of one program, so it now sets sway's output scale, which every client is measured against. classroom-scale runs first in the session and applies it. The display mode is untouched: the panel stays at 1920x1080 and only the logical coordinate space shrinks, which is what makes everything in it larger. Our own surfaces stop scaling themselves. They are measured in the same logical pixels sway is already scaling, so applying UI_SCALE again would double it. SHELL_SCALE is that decision in one named place, and setting it back to ui_scale(config) would restore per-surface scaling without touching a template. Measured at 1920x1080 with Chrome 152. Chrome's tab strip 40 -> 49 -> 59px against 1.0, 1.25, 1.5; sway's title bar 25 -> 31 -> 38px; the classroom dock 74 -> 92 -> 110px. Everything scales once, together, and 1.0 is identical to no scaling at all. Two tradeoffs, both measured rather than assumed. GTK 3 has no fractional scaling, so at 1.5 it renders at 2x and sway scales down — very slightly softer, invisible at classroom distance. XWayland is softer too: terminal text at 1.5 showed about 50% more intermediate-tone pixels than at 1.0. VLC is the only XWayland application here, and in DVD mode none of its interface is on screen, only video from a 720x480 disc that is being upscaled regardless. Chrome is a native Wayland client and stays sharp, which is what matters for reading. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
68b6347c05 |
fix: cover the whole display while a disc loads
The loading surface was invisible. GtkWindow only renders its own CSS background when the application is not painting the window itself, and this window was created app-paintable with no draw handler and no child — so it drew nothing at all. The black area during loading was never it: it was VLC's own window, tiled by sway into the usable area, which excludes the strip the dock reserves. That is why the dock and the wallpaper stayed on screen underneath. An earlier headless check missed this because that sway had no wallpaper configured, so an invisible surface and a black one looked identical. Rechecked with the real wallpaper and the real dock underneath. The surface now paints, and carries a spinner and "Loading DVD..." on the same translucent rounded card as the dock. It moves from the top layer to the overlay layer, because the dock is a top-layer surface and DVD mode has to cover it rather than depend on which surface sway created first. Its exclusive zone of -1 keeps sway from moving it out of the way of the dock's reserved strip. It goes up before VLC is started rather than alongside it, so no part of VLC's window is ever seen against the wallpaper, and comes down only once VLC reports playback on screen. The deadline that takes it down regardless is now twenty seconds, since an optical drive can be slow, and a failure to start VLC at all ends the session instead of leaving a cover with nothing behind it. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
f8ddfbe345 |
feat: make DVD playback a classroom surface, not a media player
Pressing DVD now enters DVD mode rather than opening VLC. VLC is still the backend, because its dvdnav module is what decodes disc menus and nothing else on Debian does that reliably, but nothing a person can see or press belongs to it any more. classroom-dvd-session owns the whole thing. It puts a full-screen black layer-shell surface up the moment the button is pressed, starts VLC behind it, and drops it once playback is actually on screen — so the harsh cut from wallpaper to VLC's black window is gone, and no partial VLC window or reserved dock strip is ever visible. A deadline drops the surface regardless, because DVD mode must never leave a black screen with nothing behind it. The controls are a classroom bar on the overlay layer, the one layer sway draws above a fullscreen window. It slides up when the pointer reaches the bottom of the screen and hides again shortly after it leaves. It is drawn from the dock's own stylesheet at the room's UI scale, so it is the same surface, the same radius and the same white icons. While hidden it only accepts the pointer in a thin strip along the bottom edge, so a click on a disc menu goes to the disc. The bar reaches VLC through an HTTP interface on loopback behind a password generated per session, sending hotkey *actions* by name. That is what makes the next part possible. All 108 hotkeys VLC 3.0.23 defines are unset, then Space, Esc and the arrow keys plus Enter are bound. Crop, aspect ratio, subtitles, audio tracks and deinterlacing are no longer reachable by pressing a key at random, and the arrow keys no longer change VLC's volume — the television owns volume, and CEC will own it properly later. Esc quits instead of leaving fullscreen. There is nothing to leave, and leaving it was what stranded people on a black VLC window. Close, Eject and Esc all ask VLC to quit and escalate to SIGTERM then SIGKILL if it does not; when VLC exits by any route, including a crash, the session ends and the classroom desktop comes back. Verified against VLC 3.0.23 on Trixie: every argument accepted, every control action accepted over the control interface, a wrong password refused, and quit exiting cleanly. The surfaces were rendered under a headless sway and screenshotted to check the bar against the dock. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
a3dba6e8fb |
feat: provision Chrome and DVD codecs without a manual step
A fresh classroom needed two things installed by hand on every box: Google Chrome, which is not in Debian, and the DVD codecs, which Debian cannot ship. Both now happen on their own. ekklesia-classroom-provision.service runs after every boot and does the work that needs the network and the apt lock, neither of which a package postinst can have. Each step returns immediately if it is already done, so a provisioned machine costs nothing and a machine that was offline the first time gets another go at the next boot. Nothing there is allowed to fail the boot: a classroom with no DVD codecs is still a working classroom, and it says so in the log rather than silently. The postinst enables the service but deliberately does not start it. Every OTA update reboots the moment the install finishes, and an apt run killed by that reboot would leave dpkg half-configured. Chrome comes from Google's own repository rather than a one-off .deb, so it keeps getting security updates. Google's package migrates whatever we write into a deb822 file of its own, so the repository is looked for across every source file instead of only the one we would write; otherwise a machine that had Chrome removed would end up with two copies of the same repository. The DVD codec helper previously assumed deb822 sources and did nothing on a machine using a classic /etc/apt/sources.list, which is what the hardware actually runs. It now handles both formats, and only ever adds a missing component to an existing Debian entry — so it cannot produce a duplicate repository or a duplicate component however many times it runs, and third-party repositories like Chrome's are never touched. It also answers libdvd-pkg's debconf questions, so nothing blocks on a prompt in a service with no terminal. Tested against fixture APT trees for classic sources.list, deb822 .sources, contrib already enabled, repeated runs, third-party repositories and the awkward real lines: bracketed options, indentation, trailing comments and flat repositories. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
c81fc1b0b9 |
feat: dress VLC down to an appliance screen
Stock VLC looks like a desktop media player, which is wrong for a room where the TV is the whole interface. VLC stays the backend because its dvdnav module is what provides the disc menus, and menus are the part that matters on a commercial disc. It is dressed down with documented VLC 3.x options, all verified against the 3.0.23 build in Debian Trixie: minimal view, dark palette, no cone, no tray, no now-playing popups, no resume prompt, no recent-disc history, no title banner. sway draws no border on the window either, so there is nothing above the video. The auto-hiding fullscreen controller is deliberately kept: it is not persistent chrome, and it is the only way a volunteer with a mouse can pause or change chapter. No skin is involved. Skins replace the interface wholesale and take the keyboard and mouse handling that DVD menu navigation depends on with them, as would --intf dummy. Also drops --no-qt-updates-notif, which was not an option in Debian's VLC at all. It made VLC exit before it started, so the DVD button could never have launched a disc. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
428eb27a74 |
feat: scale the shell to the room's television
A 32" panel a few feet from the children and a 65" set across a hall want the same design at different sizes. UI_SCALE in device.conf now sets that, and nobody has to edit CSS or source to tune a room. The stylesheet and the notification config become templates carrying measurement tokens. classroom-dock resolves the stylesheet in memory at startup; classroom-notifications resolves the notification config into the session's runtime directory and execs mako on it, so the process is still just mako and everything that looks for it by name still finds it. Neither template is rewritten on disk, so an update cannot lose a room's setting and a room cannot drift from the packaged design. Dock height and the reserved strip, corner radii, padding, button size, spacing, every icon, the clock and its inset, and the notification geometry all follow the scale. Colours, translucency and the hairline borders do not: those are the design, not the size. At UI_SCALE=1.0 the rendered stylesheet is byte-identical to the one the shell used before any of this existed, which is the property worth keeping. Values outside 0.8 to 1.5 are clamped and anything that is not a number falls back to 1.0, so a typo in device.conf cannot produce an unusable classroom. Device configuration moves into a shared module, since the dock and the notification daemon now have to agree about what a setting means. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
ffd18edf7e |
fix: deliver test notifications into the classroom session
The classroom desktop belongs to the classroom user and mako sits on that user's D-Bus session. An administrator over SSH is in a different session where nothing owns org.freedesktop.Notifications, so notify-send asked D-Bus to start a second mako, which had no display to open and timed out with NoReply. Find the running sway process for the classroom user and deliver into its session instead. XDG_RUNTIME_DIR and the bus address are read from that process, falling back to /run/user/<uid> and its bus socket when the environment cannot be read — root has ptrace access on the endpoint, but that is not somewhere to be brittle. The Wayland display is read the same way, and failing that from the wayland-N.lock sway holds open, so no socket name is ever assumed. notify-send only needs the bus, so a display that cannot be resolved is not worth refusing to send over. Refuses to send when mako is not already running, rather than letting D-Bus start one, and says plainly what is wrong when there is no session, no privileges, or no bus socket. --dry-run reports what it resolved without sending. Behaviour inside the session is unchanged, and the sample notifications and styling are untouched. The tests stand a real background process in for sway so /proc/<pid>/environ is genuine rather than mocked, and cover both invocation paths plus the fallbacks and every refusal. The build runs them. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
36100ad40c |
fix: let restore rescue windows left in sway's scratchpad
Nothing puts windows there any more, but a window parked by an older classroom build — the exact case this work exists to fix — would otherwise be invisible to restore and stranded until the next reboot. Counting the scratchpad as hidden means the Browser button and Super+Shift+M both pull it back, tiled. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
a8cf9ef337 |
docs: record the classroom test checklist and DVD notes
The checklist covers the bottom-shell regression explicitly, since that is the part most likely to be broken by a later change, and records the known limitation that Chrome's own minimize button does nothing under sway. Co-Authored-By: Claude Opus 5 <[email protected]> |