fix: give the QEMU direct boot a framebuffer to draw on

[CesarManzoCode]

make -C image agent and boot-graphical opened a window, booted the kernel, ran the machine, and then said

/dev/fb0 could not be opened: No such file or directory

Both targets boot with -kernel and -initrd, so the firmware is SeaBIOS and there is no UEFI. No UEFI means no Graphics Output Protocol, no GOP means no framebuffer configured before the kernel starts, and screen_info then describes an 80x25 text console. SYSFB has nothing to publish and FB_EFI has nothing to adopt: the framebuffer was not broken, it never existed. run-uefi was always fine for the same reason in reverse — OVMF leaves a real GOP behind — and the text visible in the window was vgacon, which does not go through /dev/fb0 at all.

Which card, read out of QEMU's source rather than assumed: hw/i386/pc_piix.c and hw/i386/pc_q35.c both set default_display = "std", so a command line with no -vga and no video -device gets QEMU Standard VGA, PCI 1234:1111, the Bochs VBE dispi interface.

DRM_BOCHS is the driver for that card and no other — its id_table in drivers/gpu/drm/tiny/bochs.c is those two numbers, its Kconfig help says "a KMS driver for qemu's stdvga output" — and it programs the mode itself over the dispi registers instead of waiting for a firmware to have done it. DRM_FBDEV_EMULATION is the half that produces /dev/fb0, at 32 bpp, which is the XRGB8888 thalyx-screen already writes. It is default FB and would arrive on its own today; it is named anyway, because config-check is structurally blind to an option nobody asked for.

The cheaper options were looked at first and none of them works here. FB_VESA needs the bootloader to have done a VBE mode set, and vga= lives in the setup header where a -kernel boot cannot reach it. FB_VGA16 needs no firmware but gives 640x480 planar 4 bpp, which is not a format thalyx-screen can write into. Booting boot-graphical through OVMF would be changing the boot architecture of the target that is the regression net under everything else.

Real hardware is untouched: no PC carries a 1234:1111, so bochs-drm never probes there and FB_EFI still adopts the firmware's framebuffer. The cost is size — DRM core, the KMS helpers and TTM go into the kernel that ships.

Nothing outside image/thalyx.config changed: no Rust, no agent, no store, not even the QEMU command lines. config-check verifies the three new lines on its own because it reads that file.

vault/02-Arquitectura/La-Pantalla.md had deferred DRM/KMS to "otro decreto", so the revision is written there: this takes none of what that sentence set aside — Thalyx still does not choose the mode, there is no second screen, no acceleration and no graphics in userland — it is taken because on a boot with no firmware there is no other way for the rectangle of memory to exist.

NOT PROVEN here: this container has neither QEMU nor a kernel build, so the only checks that ran are static — the Kconfig dependency chains against the 6.12 sources, and the vault's own two. The window is Cesar's to open.

Claude-Session: https://claude.ai/code/session_0162V5Lyz4KvgXu1ySgC1wb6