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

image/thalyx.config

@@ -93,6 +93,51 @@ CONFIG_FONT_SUPPORT=y
 CONFIG_FONT_8x16=y
 CONFIG_SYSFB=y
 
+# --- and the one card that is not a card: QEMU's, on a boot with no firmware ---
+#
+# `FB_EFI` above adopts a framebuffer somebody else configured. On `run-uefi`
+# somebody else exists — OVMF, leaving a GOP behind. On `make -C image
+# boot-graphical` and `boot-agent` nobody does: those hand QEMU `-kernel` and
+# `-initrd`, so the firmware is SeaBIOS, there is no GOP, and `screen_info`
+# describes an 80x25 **text** console rather than a linear framebuffer. `SYSFB`
+# then has nothing to publish, `FB_EFI` has nothing to adopt, and the machine
+# comes up with a window that works, a kernel that boots, and
+#
+#     /dev/fb0 could not be opened: No such file or directory
+#
+# — which reads as "the screen is broken" and is really "there is no driver here
+# for the card QEMU actually plugged in". That card, checked in QEMU's source and
+# not assumed: `hw/i386/pc_piix.c` and `pc_q35.c` both set
+# `default_display = "std"`, so a command line with no `-vga` and no `-device`
+# gets **QEMU Standard VGA** — PCI `1234:1111`, the Bochs VBE dispi interface.
+#
+# `DRM_BOCHS` is the driver for exactly that and nothing else: its `id_table` is
+# those two numbers, its Kconfig help says «a KMS driver for qemu's stdvga
+# output», and it sets its own mode over the dispi registers instead of waiting
+# for a firmware to have set one. `FBDEV_EMULATION` is the half that matters
+# here — it is what turns the DRM device into `/dev/fb0`, at 32 bpp, which is
+# the XRGB8888 `thalyx-screen` already writes. It is `default FB` and would
+# therefore arrive on its own today; it is named anyway, because an option
+# nobody asks for is an option `config-check` is blind to, and the day `FB`
+# moves is the day the screen goes away with no line in this file to blame.
+#
+# **This is the DRM/KMS that `vault/02-Arquitectura/La-Pantalla.md` deferred to
+# «otro decreto».** It is not taken for what that section refused — the mode is
+# not Thalyx's to change, there is no second screen, no acceleration and no GPU
+# in userland, and none of that changes. It is taken because on a boot without
+# firmware there is no other way for the rectangle of memory to exist at all: no
+# `vga=` reaches a `-kernel` boot, and the only fbdev that needs no firmware is
+# `vga16fb`, whose 640x480 planar 4 bpp is not a format `thalyx-screen` can
+# write into. One card, one driver, no userland.
+#
+# Real hardware is untouched by this: no PC has a `1234:1111`, so `bochs-drm`
+# never probes there and `FB_EFI` still adopts the firmware's framebuffer as
+# before. What it costs is size — DRM core, KMS helpers and TTM go into the
+# kernel that ships.
+CONFIG_DRM=y
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_DRM_BOCHS=y
+
 # --- the keyboard, which on a real PC is USB and not emulated ---
 #
 # QEMU's keyboard arrives through the serial console, so none of this has ever

vault/02-Arquitectura/La-Pantalla.md

@@ -2,7 +2,7 @@
 tipo: arquitectura
 estado: decretado
 fecha-decreto: 2026-08-27
-fecha-revision: 2026-08-28
+fecha-revision: 2026-09-05
 tags: [pantalla, interfaz, framebuffer, doble-ruta, camino-confiable]
 ---
 
@@ -117,7 +117,12 @@ Lo que eso cuesta, dicho igual de claro:
 | Una sola pantalla física | Multi-monitor no existe aquí, y no está decretado que deba |
 
 Si algún día hace falta cambiar el modo o encender una segunda pantalla, eso es
-DRM/KMS y es **otro decreto**. No se toma por adelantado.
+DRM/KMS y es **otro decreto**. No se toma por adelantado — y lo que entró el
+2026-09-05 no lo toma: hay un driver DRM en el kernel, para **una** tarjeta que
+sólo existe dentro de QEMU, y sigue sin haber modo elegido por Thalyx, sin
+segunda pantalla, sin aceleración y sin nada de gráficos en el espacio de
+usuario. El motivo está abajo, en la revisión «El arranque directo de QEMU no
+tiene firmware que deje nada puesto».
 
 ## La forma: una pantalla, sin ventanas
 
@@ -252,6 +257,57 @@ preguntarla en una máquina que podría quedarse en negro con la respuesta.
 
 ## Revisiones
 
+### 2026-09-05 — El arranque directo de QEMU no tiene firmware que deje nada puesto
+
+**Defecto acotado, reportado por Cesar.** `make -C image agent` y
+`boot-graphical` abren la ventana de QEMU, el kernel arranca, la máquina
+funciona, y adentro:
+
+```
+/dev/fb0 could not be opened: No such file or directory
+```
+
+**Causa.** Los dos objetivos arrancan con `-kernel` y `-initrd`, así que el
+firmware es SeaBIOS y no hay UEFI. Sin UEFI no hay Graphics Output Protocol, sin
+GOP no hay framebuffer ya configurado, y `screen_info` describe una consola de
+**texto** de 80×25. Entonces `SYSFB` no publica ningún dispositivo y `FB_EFI` no
+tiene qué adoptar. No es que el framebuffer esté roto: **nunca hubo uno**. Por eso
+`run-uefi` —que sí arranca con OVMF— siempre se vio bien, y por eso la ventana de
+`boot-graphical` mostraba texto: eso era `vgacon`, la consola de texto de la VGA,
+que no pasa por `/dev/fb0`.
+
+**Qué tarjeta es.** Comprobado en el código de QEMU, no supuesto: `hw/i386/pc_piix.c`
+y `hw/i386/pc_q35.c` ponen los dos `default_display = "std"`. Una línea de comandos
+sin `-vga` y sin `-device` de video recibe la **QEMU Standard VGA**, PCI `1234:1111`,
+con la interfaz Bochs VBE dispi.
+
+**El driver mínimo.** `CONFIG_DRM_BOCHS` es de esa tarjeta y de ninguna otra: su
+`id_table` en `drivers/gpu/drm/tiny/bochs.c` son esos dos números, su ayuda de
+Kconfig dice literalmente «a KMS driver for qemu's stdvga output», y programa el
+modo él mismo por los registros dispi en vez de esperar a que un firmware lo haya
+dejado hecho. `CONFIG_DRM_FBDEV_EMULATION` es la mitad que importa aquí: es lo que
+convierte el dispositivo DRM en `/dev/fb0`, a 32 bpp, que es el XRGB8888 que
+`thalyx-screen` ya escribe.
+
+**Por qué no hubo una opción más barata**, que es lo que se buscó primero:
+
+| Alternativa | Por qué no |
+|---|---|
+| `FB_VESA` | Necesita que el gestor de arranque haya hecho el cambio de modo VBE. `vga=` vive en la cabecera de `setup`, no en la línea de comandos, y a un arranque con `-kernel` no hay cómo dársela |
+| `FB_VGA16` | No necesita firmware, pero da 640×480 planar de 4 bpp, y eso no es un formato en el que `thalyx-screen` pueda escribir |
+| OVMF también para `boot-graphical` | Es cambiar de arquitectura de arranque, y `boot` es la red de regresión de todo lo demás |
+
+**Lo que cuesta.** Tamaño: el núcleo de DRM, los ayudantes de KMS y TTM entran al
+kernel que se embarca. Nada más. En hierro real no cambia nada — ninguna PC tiene
+un `1234:1111`, así que `bochs-drm` no llega ni a probar ahí y `FB_EFI` sigue
+adoptando el framebuffer del firmware como siempre.
+
+**Lo que esta revisión pide ratificar.** La sección «Sobre qué se dibuja» dejaba
+DRM/KMS para «otro decreto». Esto entra sin decidir nada de lo que esa frase
+apartaba: Thalyx sigue sin elegir el modo, sin segunda pantalla, sin aceleración y
+sin un gramo de gráficos en el espacio de usuario. Entra porque en un arranque sin
+firmware **no hay otra forma de que el rectángulo de memoria exista**.
+
 ### 2026-08-28 — La pantalla es lo que se ve al arrancar, no un verbo que la enciende
 
 **Decretado por Cesar.** Sus palabras:

vault/06-Pendientes/Punto-Actual.md

@@ -1,7 +1,7 @@
 ---
 tipo: estado-vivo
 estado: activo
-fecha-actualizacion: 2026-08-31
+fecha-actualizacion: 2026-09-05
 tags: [continuidad, punto-actual, sesiones]
 ---
 
@@ -14,10 +14,51 @@ tags: [continuidad, punto-actual, sesiones]
 >
 > Para *cómo* trabajar en el proyecto, ver `CLAUDE.md` en la raíz del repo.
 
-## Los hijos del toolchain ya encuentran el toolchain — 2026-08-31
+## La ventana de QEMU ya tiene framebuffer — 2026-09-05
 
 **Éste es el estado actual.** Los bloques de abajo son cómo se llegó.
 
+`make -C image agent` y `boot-graphical` abrían la ventana, el kernel arrancaba,
+la máquina funcionaba, y adentro `/dev/fb0 could not be opened: No such file or
+directory`.
+
+**Causa:** esos dos objetivos arrancan con `-kernel` y `-initrd`, así que el
+firmware es SeaBIOS. Sin UEFI no hay GOP, sin GOP no hay framebuffer ya
+configurado, `SYSFB` no publica nada y `FB_EFI` no tiene qué adoptar. Nunca hubo
+un framebuffer — el texto que sí se veía era `vgacon`, que no pasa por
+`/dev/fb0`. Por eso `run-uefi`, que arranca con OVMF, siempre se vio bien.
+
+**La tarjeta**, leída del código de QEMU y no supuesta: `hw/i386/pc_piix.c` y
+`pc_q35.c` ponen los dos `default_display = "std"`, así que una línea sin `-vga`
+recibe la **QEMU Standard VGA**, PCI `1234:1111`. **El driver mínimo de esa
+tarjeta y de ninguna otra** es `DRM_BOCHS`, que programa el modo él mismo por los
+registros dispi; `DRM_FBDEV_EMULATION` es lo que lo convierte en `/dev/fb0` a 32
+bpp, que es el XRGB8888 que `thalyx-screen` ya escribe.
+
+**El cambio son tres líneas en `image/thalyx.config`** y nada más — ni Rust, ni
+agente, ni store, ni la línea de comandos de QEMU:
+
+```
+CONFIG_DRM=y
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_DRM_BOCHS=y
+```
+
+`config-check` las verifica solo, porque lee `thalyx.config`. Las cadenas de
+dependencias se comprobaron contra los Kconfig de 6.12 (`DRM` sólo pide
+`HAS_IOMEM` y `AGP=n`; `DRM_BOCHS` pide `DRM && PCI && MMU`, y `PCI` ya estaba),
+pero **este contenedor no compila kernels ni tiene QEMU**, así que nada de esto
+está corrido: falta que Cesar arranque la ventana.
+
+**Y pide ratificación:** [[La-Pantalla]] dejaba DRM/KMS para «otro decreto». Esto
+entra sin decidir nada de lo que esa frase apartaba —Thalyx sigue sin elegir el
+modo, sin segunda pantalla, sin aceleración y sin gráficos en el espacio de
+usuario— pero es DRM en el kernel, y la nota quedó revisada diciéndolo.
+
+## Los hijos del toolchain ya encuentran el toolchain — 2026-08-31
+
+Los bloques de abajo son cómo se llegó.
+
 La VM real cerró el problema anterior: dentro de Thalyx,
 `cargo 1.90.0 from: thalyx` y `rust-analyzer 1.90.0 from: thalyx`. Y aun así
 `context('LanternRegistry')` contestaba `resolution: nothing` y el rename

vault/09-Notas-Tecnicas/Construccion-del-ISO.md

@@ -716,18 +716,30 @@ su párrafo cada grupo:
 | Qué | Opciones | Qué falla sin eso |
 |---|---|---|
 | La pantalla | `FB`, `FB_EFI`, `FRAMEBUFFER_CONSOLE`, `FONT_8x16`, `VT`, `VT_CONSOLE` | La ISO arranca en una PC y **no se ve nada** |
+| La pantalla dentro de QEMU sin firmware | `DRM`, `DRM_FBDEV_EMULATION`, `DRM_BOCHS` — agregadas el 2026-09-05 | `boot-graphical` y `boot-agent` abren la ventana, la máquina arranca bien, y adentro `/dev/fb0 could not be opened` |
 | El teclado | `INPUT`, `HID_SUPPORT`, `HID`, `HID_GENERIC`, `USB_HID`, `USB_XHCI_HCD`, `USB_EHCI_HCD`, `SERIO_I8042`, `KEYBOARD_ATKBD` | La máquina llega al prompt y no se le puede contestar |
 | Los discos | `BLK_DEV_NVME`, `SATA_AHCI`, `ATA`, `SCSI`, `BLK_DEV_SD`, `PCI_MSI` | El instalador no ve el disco en el que va a instalar |
 | El medio | `USB_STORAGE` — agregada el 2026-08-07 | La máquina arranca de la USB y **dos comandos después** dice que no encuentra un medio de Thalyx |
 
-Cuatro cosas de esa tabla que no son obvias:
+Cinco cosas de esa tabla que no son obvias:
 
 - **`FB_EFI` no es un controlador de video.** Es el framebuffer que el firmware
   **ya configuró** antes de que el kernel arranque, y este driver lo adopta. Por
   eso no hay aquí un driver de ninguna tarjeta real: Thalyx necesita dibujar texto,
   no levantar una GPU, y un driver por cada chip del mercado es un userland entero
   — que es justo lo que esta imagen existe para no tener. El costo se dice en vez
   de esconderse: la resolución es la que eligió el firmware y no se puede cambiar.
+- **Y por eso mismo `FB_EFI` no sirve donde no hay firmware.** `boot-graphical` y
+  `boot-agent` arrancan con `-kernel` y `-initrd`: el firmware es SeaBIOS, no hay
+  GOP, `SYSFB` no publica nada y `FB_EFI` no adopta nada, así que no existe
+  `/dev/fb0` — aunque la ventana se vea llena de texto, porque eso es `vgacon` y no
+  pasa por el framebuffer. Lo que QEMU enchufa ahí, comprobado en su código
+  (`default_display = "std"` en `hw/i386/pc_piix.c` y `pc_q35.c`), es la **QEMU
+  Standard VGA**, PCI `1234:1111`, y el driver de esa tarjeta y de ninguna otra es
+  `DRM_BOCHS`, que programa el modo él mismo en vez de esperar a un firmware.
+  `DRM_FBDEV_EMULATION` es lo que convierte ese dispositivo DRM en `/dev/fb0`, a 32
+  bpp. El razonamiento completo, y qué alternativas más baratas se descartaron, está
+  en [[La-Pantalla]].
 - **`PCI_MSI` no es un lujo.** El driver de NVMe arma sus colas alrededor de
   interrupciones por mensaje, y `allnoconfig` lo deja apagado. Nada más de este
   archivo lo habría pedido.