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:
parent
a4cfecd19c
commit
38ea83bf05
2 changed files with 64 additions and 7 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue