vgpud: the head follows the F8 resolution, not the window

"virtio gpu doesn't follow f8 menu default resolution" -- it did not, and now
that the head mirrors the console that is visible rather than academic.

vgpud sized itself from GET_DISPLAY_INFO, which answers with the size of the
*host's window*: a number set by dragging a corner, that says nothing about the
machine and everything about QEMU. Meanwhile the resolution the F8 menu offered
at boot is the one that was actually chosen, and it is the console's.

So picking 1024x768 at the menu gave a second display still at 1280x800, with
the console letterboxed inside it on the theme ground -- the right pixels in
the wrong mode, on a display that could simply have been the right size.

console_open() now runs *before* bring_up(), and bring_up() takes the console's
mode when there is a console. That ordering is the whole fix and it is not
cosmetic: the DMA allocation is sized from those numbers and fixed for the life
of the process, so a mode chosen after the fact could only ever be smaller than
the window already paid for. A machine with no console to mirror brings up
whatever the device reports, exactly as before.

Verified by driving the F8 menu over the serial line -- 'o', Resolution,
1024x768, boot -- and screendumping both heads over QMP: both come up 1024x768
and are byte-identical, where the virtio head used to stay 1280x800. `schmode
1024 768` from a 1280x800 boot still works. Both supported configurations: one
boot each, no traps, no panics, socktest and memfdtest green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-09-22 16:21:08 +02:00
commit 38ea83bf05
2 changed files with 64 additions and 7 deletions

View file

@ -150,6 +150,24 @@ non-integer ratio is text you cannot read.
itself, and when there is one, the mirror goes away. Until then the honest
thing for a working display to show is the system running on it.
### The F8 resolution is the head's resolution
`vgpud` used to size itself from `GET_DISPLAY_INFO`, which answers with the
size of the *host's window* — a number the person running QEMU sets by dragging
a corner, and which says nothing about the machine. The resolution the F8 menu
offered at boot is the one that was actually chosen, and it is the console's.
A head that mirrors the console and ignores that choice shows the right pixels
in the wrong mode: pick 1024×768 at the menu and the second display stayed at
whatever the window was, with the console letterboxed inside it. So
`console_open()` runs *before* `bring_up()`, and the mode comes from the
console when there is one.
That ordering is the whole of it, and it is not cosmetic: the DMA allocation is
sized from those numbers and fixed for the life of the process, so a mode
chosen after the fact could only ever be smaller than the window that was
already paid for.
### /run is not a tmpfs
Found while testing the above, and older than it: `schmode` reported *"cannot