From a030bfa1d678f6e88fdd1cb1a35f9772caad8896 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 03:09:33 +0000 Subject: [PATCH] fix: give the QEMU direct boot a framebuffer to draw on MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `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. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_0162V5Lyz4KvgXu1ySgC1wb6 --- image/thalyx.config | 45 ++++++++++++++ vault/02-Arquitectura/La-Pantalla.md | 60 ++++++++++++++++++- vault/06-Pendientes/Punto-Actual.md | 45 +++++++++++++- .../09-Notas-Tecnicas/Construccion-del-ISO.md | 14 ++++- 4 files changed, 159 insertions(+), 5 deletions(-) diff --git a/image/thalyx.config b/image/thalyx.config index cc77800..821cfee 100644 --- a/image/thalyx.config +++ b/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 diff --git a/vault/02-Arquitectura/La-Pantalla.md b/vault/02-Arquitectura/La-Pantalla.md index 4cfdd62..f2cf79d 100644 --- a/vault/02-Arquitectura/La-Pantalla.md +++ b/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: diff --git a/vault/06-Pendientes/Punto-Actual.md b/vault/06-Pendientes/Punto-Actual.md index 7844acf..94a2baf 100644 --- a/vault/06-Pendientes/Punto-Actual.md +++ b/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 diff --git a/vault/09-Notas-Tecnicas/Construccion-del-ISO.md b/vault/09-Notas-Tecnicas/Construccion-del-ISO.md index 2e8a935..ca1c27e 100644 --- a/vault/09-Notas-Tecnicas/Construccion-del-ISO.md +++ b/vault/09-Notas-Tecnicas/Construccion-del-ISO.md @@ -716,11 +716,12 @@ 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 @@ -728,6 +729,17 @@ Cuatro cosas de esa tabla que no son obvias: 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.