The ILI9486 has its own opinions

Owning the framebuffer doesn't mean the panel behaves. A few things it took real bench time to work around:

• No controllable backlight. /sys/class/backlight is empty on this panel, so "dimming" after idle is a software screensaver that darkens the rendered image rather than a hardware fade. If a PWM backlight ever gets wired in, Scottina will auto-detect the sysfs node and use it — the code's already there, just unused.
• Rotation lives in the overlay, calibration doesn't. The panel comes up through one line in config.txt — dtoverlay=piscreen,drm,rotate=90 — and that's the only display setting that needs a reboot. Touch axis mapping (swap X/Y, invert X, invert Y) is a runtime config value instead, so re-calibrating after a mount change is a Settings-screen toggle or a config.json edit over SSH, never a re-flash.
• The console has to be told where to live. The panel only scans out over SPI once its DRM pipe is enabled, and that's driven by whatever the console is mapped onto — not guaranteed to be fb0 by default. The systemd unit forces it with con2fbmap before Scottina starts, blanks the cursor, and gives the modeset a moment to settle first.

Making an SPI panel feel fast

SPI is not a fast bus, so full-frame redraws at interactive rates were never going to happen. Every screen that ticks reports the boxes that actually changed; framebuffer.py merges those into row bands (bands within 8 rows of each other get fused — a seek costs more than a few extra rows) and writes only those, since the DRM fbdev layer derives its SPI damage from the byte range touched anyway. That's a 2–15× saving over a full blit, and it's what lets live screens like CAN Bus tick at ~20 Hz while everything idle sits at ~1 Hz without cooking the bus.

Next log: hotplug — how a screen's tile appears the instant its dongle is plugged in, and disappears the instant it isn't.