fbcond blocked indefinitely in open_display_v2() while handing the console
over to the real graphics driver: boot stopped at "fbcond: Performing
handoff" and never reached the "Opened new display" that follows a
successful open.
fbcond is single-threaded and owns the console, so while it waited there it
stopped draining console writers. getty, login and the login shell all
blocked on their writes, which made the failure look like a slow or hung
shell -- the stall point just tracked whichever process next wrote to the
console. If the graphics driver was itself waiting on the console, the two
deadlocked outright and the console never came back.
The wait comes from the scheme-open handshake: inputd signals the handoff as
soon as the driver registers its path, but the driver may not be serving its
scheme yet, and O_NONBLOCK does not bound the open (it governs later reads).
Split the two halves in inputd's ConsumerHandle: display_path_v2() only does
an fpath on our own handle and returns promptly, while open_display_path_v2()
carries the blocking open. fbcond now resolves the path inline and hands the
open to a worker thread, then picks the result up from the event loop via
poll_pending_handoff(). Console output produced meanwhile is buffered in
pending_writes (already the behaviour while the display is unmapped) and
flushed once the new display is mapped.
The handoff is one-shot: inputd signals it the moment the real display
driver registers its path, but the driver's scheme may not serve the v2
open / capability query for a few more milliseconds. Without a retry, a
transient not-ready driver leaves the framebuffer permanently blank —
the login prompt is drawn to the framebuffer VT, so the console appears
dead even though boot continues on the serial mirror (observed as the
2026-07-20 '-vga std' boot freeze at 'Performing handoff').
Retry the reopen for up to 250 x 10ms; the driver becomes ready well
within this bound in practice. On success after retries, log the retry
count at info level. If the driver is still not ready after the bound,
emit a single explicit warning instead of per-attempt warn spam (the
per-attempt message in display.rs is demoted to debug). Serial mirror
remains unaffected in the failure case.
V2GraphicsHandle::from_file() unwrapped/asserted the DumbBuffer
capability, but the display fd is O_NONBLOCK and the graphics driver
often has not finished coming up at handoff time — so from_file failed
with EAGAIN and the assert panicked fbcond. Since fbcond owns the
console and serial mirror, its death froze the whole boot right after
'Performing handoff' with no login prompt.
Return an error from graphics-ipc when the driver does not yet report
DumbBuffer, and have fbcond log-and-return so the handoff is retried
when the driver publishes its surface, instead of panicking.
(Change found as uncommitted work in the fork; committing to preserve
it and unblock the clean-fork build gate.)
Sync the base fork with 13 upstream commits (xhci event-processing
dedup + IRQ race fix, randd permission simplification, nvmed TimeSpec
fix, /dev/ptmx, fpath legacy-path cleanup, dynamically-linked init
fix, and more). Brings process_one_event into the tree, satisfying the
verify-fork-functions gate for base.
Conflicts resolved (3 of 8 overlapping files; 5 auto-merged):
- drivers/usb/xhcid/src/xhci/irq_reactor.rs: took upstream's
process_one_event/EventProcessResult refactor (b2ed85ea) including
the a01d3ce6 race fix (process events between NoEvent and
unmasking), and re-applied the Red Bear SPURIOUS_REBOOT quirk on the
NoEvent warning (downgrade to debug when quirked).
- randd/src/main.rs: took upstream's permission-handling
simplification (e26db606); re-applied the RB fcntl improvement
(F_GETFL/F_GETFD/F_SETFL/F_SETFD handling, Linux random_fops xref)
and the is_cpu_feature_detected early-return cleanup. Dropped
test_scheme_perms (deleted by upstream's simplification).
- Makefile: kept upstream's new /dev symlink block (dev/null, ptmx,
random, urandom, zero, tty, stdin/stdout/stderr).
Verified: cargo check clean; 57/57 tests pass (xhcid 35, usbhubd 14,
xhci trb 8); verify-fork-functions.sh --no-fetch base reports all
upstream functions present.
The keyboard input path pushed the raw character bytes, so the Enter key
(a bare CR on the keymap) never produced an LF. Line-oriented readers on
the console (e.g. a shell's read_line) then never saw a completed line and
appeared to hang. Convert CR->LF here, matching the serial input path
(push_input_bytes).
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.
For fbbootlog, fbcon and the disk drivers there is no load bearing use
of the fpath output. And for chan relibc already handles both the legacy
and new format.
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