nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

gfx: the second head shows the boot, not just what comes after it

Browse source 
Two things, both asked for.

**The crash report no longer says which monitors it reached.** "The report is
on the virtio-gpu display too" was a line about the crash screen printed on the
crash screen. The report says what happened and where to read it again; that is
not part of it.

**And the second head now shows the F8 menu and the boot.** It used to be black
until vgpud started several seconds into userspace -- through the splash,
through the menu, through every boot message -- which from the outside is
indistinguishable from a display that does not work. Three stages now cover the
whole boot and hand over to each other without coordinating:

*The loader.* LocateProtocol() answers with the first GOP and offers no way to
ask for the rest, so the rest are found by handle and fed the primary's
framebuffer as a Blt source at the points where a screen is finished: the menu,
the resolution chooser, system information, the splash, each segment of the
kernel load. Blt rather than a second framebuffer to draw into, because a
virtio GOP does not have one -- the same fact that made a virtio-only machine
reboot-loop two commits ago.

*The kernel.* gfx remembers which rows were drawn, as one span rather than a
list of rectangles, because console output is lines and a span is what lines
make. display_mirror_console() copies that span across: a line of boot text is
one cell-row transfer, not a screen. Primed once after pci_init(), because a
display that has just appeared has a black scanout and the console it should be
showing was drawn by the loader into a framebuffer it knows nothing about.

*Then vgpud*, from the same console framebuffer, unchanged.

**Two bugs found building it, both worth the retelling.**

The mirror ran per character from inside vt_feed -- which is inside the console
lock -- and vga_disp_acquire() announces its back buffer with a cprintf. A CPU
taking a lock it already holds, with a call chain that said exactly that. It
runs at the end of consolewrite() and cprintf() now, outside the lock, which is
also the better batching: one transfer per write instead of one per character.

And "is this the console's own screen" was asked of the pointer acquire()
returned. vga_fb hands back a back buffer it copies onto the console's
framebuffer afterwards, so on a one-screen machine the answer was "a different
screen" -- and the console was mirrored onto itself through two megabytes of
intermediate, allocated for the purpose. display_ops grew scanout_phys, which
is a fact about the hardware rather than a policy a driver can get subtly
wrong, and it is asked first: it has no side effects and acquire() has two.

Verified with two heads under QEMU, screendumping the virtio head every 400 ms
from power-on: splash, splash, splash, then the console, and it stays. The F8
menu appears on it; choosing 1024x768 there brings both heads up at 1024x768
byte-identical. A panic still reaches both. Both supported configurations: one
boot each, no traps, no panics, socktest and memfdtest green.

One gap remains and is documented rather than hidden: while the kernel's driver
resets the device during probe, QEMU shows "Display output is not active" for a
fraction of a second. A device being taken over has no scanout until the new
driver sets one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-09-22 21:47:35 +02:00
commit 182cc76588
14 changed files with 437 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

25
boot/uefi/efi.h
View file

@ -171,7 +171,12 @@ typedef struct {
void *OpenProtocolInformation;
void *ProtocolsPerHandle;
void *LocateHandleBuffer;
/* SearchType 2 is ByProtocol: every handle that speaks a given protocol,
* which is how the loader finds the displays LocateProtocol does not
* return -- it answers with the first one and there is no second call. */
EFI_STATUS (*LocateHandleBuffer)(UINTN SearchType, EFI_GUID *Protocol,
void *SearchKey, UINTN *NoHandles,
EFI_HANDLE **Buffer);
EFI_STATUS (*LocateProtocol)(EFI_GUID *Protocol, void *Registration,
void **Interface);
} EFI_BOOT_SERVICES;
@ -307,10 +312,26 @@ typedef EFI_STATUS (*EFI_GOP_QUERY_MODE)(
typedef EFI_STATUS (*EFI_GOP_SET_MODE)(
struct EFI_GRAPHICS_OUTPUT_PROTOCOL *This, UINT32 ModeNumber);
/* Blt is how you draw on a GOP that has no linear framebuffer to write into --
* and there is one of those on every machine with a virtio-gpu, because the
* device has no aperture. It is also the only way to put pixels on a *second*
* display: the loader draws into the primary's framebuffer directly and then
* hands that same memory to the other GOP's Blt as a source buffer. */
struct EFI_GRAPHICS_OUTPUT_PROTOCOL;
#define ByProtocol 2
#define EfiBltVideoFill 0
#define EfiBltBufferToVideo 2
typedef EFI_STATUS (*EFI_GOP_BLT)(struct EFI_GRAPHICS_OUTPUT_PROTOCOL *This,
void *BltBuffer, UINTN BltOperation,
UINTN SourceX, UINTN SourceY,
UINTN DestinationX, UINTN DestinationY,
UINTN Width, UINTN Height, UINTN Delta);
typedef struct EFI_GRAPHICS_OUTPUT_PROTOCOL {
EFI_GOP_QUERY_MODE QueryMode;
EFI_GOP_SET_MODE SetMode;
void *Blt;
EFI_GOP_BLT Blt;
EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE *Mode;
} EFI_GRAPHICS_OUTPUT_PROTOCOL;