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

qemu: a target with one screen, and a note saying which is which

Browse source 
`make qemu` gives the machine two display devices, which is deliberate --
stdvga carries the splash and text console, virtio-gpu is what the display
class binds and what a compositor is developed against. What the comment above
QEMU_DISPLAY did not say is that this means **two QEMU displays**, and a window
shows one at a time.

Once vgpud runs they show completely different things: the console and your
shell are on stdvga, and virtio-gpu has whatever vgpud drew, which today is a
test pattern. So a window sitting on the virtio-gpu display shows colour bars
and no prompt, and one that opened before vgpud drew shows black -- and neither
is a failure, though both look exactly like one.

`make qemu-console` boots with one display and no GPU to hand over: vgpud finds
nothing to claim and exits, and the single window is the console. Mostly it is
a way to tell "I am looking at the other screen" apart from "the screen is
broken" in the ten seconds before assuming the second one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
Nexoniarz 2026-09-14 20:05:29 +02:00
commit c028561da0
1 changed files with 23 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

24
Makefile
View file

@ -174,8 +174,25 @@ endif
# through VBE in 16-bit real mode and there is no virtio path that early, so a
# machine with only virtio-gpu boots blind until the kernel is up. Both devices:
# virtio-gpu wins the display class, stdvga carries the splash and text console.
# Two display devices means **two QEMU displays**, and a window can only show
# one at a time -- GTK puts them under View, SDL cycles with Ctrl-Alt-2. Which
# matters more than it sounds once vgpud runs, because the two then show
# completely different things:
#
# stdvga the boot splash, then the text console and your shell
# virtio-gpu whatever vgpud drew, which at the moment is a test pattern
#
# So a window sitting on the virtio-gpu display shows colour bars and no
# prompt, and one that opened before vgpud drew shows black. Nothing is wrong
# when that happens; you are looking at the other screen. `make qemu-console`
# below boots with one display and no GPU to hand over, which is the quickest
# way to tell that apart from an actual failure.
QEMU_DISPLAY = -vga std -device virtio-gpu-pci
# One display, carrying the console. No virtio-gpu, so vgpud finds nothing to
# claim and exits, and the single window is the thing you wanted to look at.
QEMU_DISPLAY_1 = -vga std
# A network card, on every QEMU target.
#
# Spelled out rather than left to QEMU's default NIC. The default exists and is
@ -1245,6 +1262,11 @@ qemu: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) $(QEMU_INPUT) $(QEMU_ACCEL) $(QEMU_NET) \
$(OVMF_DRIVES) -m 1G -smp $(SMP) -machine pc-i440fx-9.2
# The same machine with one screen, which is the console. See QEMU_DISPLAY.
qemu-console: esp $(BUILD)/schfs.img $(OVMF_CODE) $(OVMF_VARS)
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY_1) $(QEMU_INPUT) $(QEMU_ACCEL) $(QEMU_NET) \
$(OVMF_DRIVES) -m 1G -smp $(SMP) -machine pc-i440fx-9.2
# The root filesystem. Built from the staged sysroot; the kernel mounts it as
# / in forkret().
#
@ -1348,7 +1370,7 @@ qrtest: $(QRTEST)
qrcheck: $(QRTEST)
$(PYTHON) tools/python/qrcheck.py
.PHONY: all kernel ramroot cmd ports projects sysroot-install qemu qemu-kvm schcom-test \
.PHONY: all kernel ramroot cmd ports projects sysroot-install qemu qemu-console qemu-kvm schcom-test \
schfs-test schfs-objtest schfs-image-test schfs-check mkschfs \
schfs-fsck crashshot qemu-schfs iso qemu-iso clean distclean \
logo qrtest qrcheck crashqr usb-ids ovmf esp uefi