fbcond now mirrors all framebuffer-console output to the kernel debug (serial)
scheme AND feeds serial input back into the active VT's input queue. Previously,
once fbcond took over the console after display handoff the serial line went
silent (headless operators saw the boot stop at 'Performing handoff' and never
saw the getty login prompt, which draws only to the framebuffer VT). Now the
same console — boot log, login prompt, and shell — is fully usable over serial,
reusing the working framebuffer getty for both surfaces.
Re-adds the archived-but-unapplied scrollback support: a 1000-line ring
buffer in TextScreen capturing all output (incl. pre-handoff boot log), a
Handle::Scrollback variant opened via /scheme/fbcon/<vt>/scrollback, and a
read path returning the retained buffer. Adapted to the current single-step
openat scheme protocol.
Force probes can be rather expensive on real hardware so according to
the drm_mode_get_connector docs it should only be done at startup, on a
hotplug event and when explicitly requested by the user.
This matches the Linux DRM interface. With this I believe the only
divergence from the Linux DRM interface that would be a breaking change
to the in-tree users of the graphics api to change to the proper
interface is the use of the UPDATE_PLANE ioctl in the place of proper
modesetting interface. It should be possible to support this in
parallel to UPDATE_PLANE, so updating Orbital to the DRM interface
should now be possible. Orbital can be updated to the proper modesetting
interface once it is implemented.
Unfortunately the scheme still has to be created by the daemon due to a
kernel bug, but once that is fixed, it would allow delayed spawning of
scheme daemons.
Red Bear OS