Phase 4 vraie — pipeline OK, verrou fbbootlogd identifié

Crates ajoutés :
- redox-wl-display (lib) : RedoxOutput { open, take_crtc, pixels_mut,
  present, present_with_takeover, Drop }
- redox-wl-fullscreen-paint (bin) : take CRTC + 30 frames ARGB animées

Validation logique du pipeline display sur Redox bootée :
- ConsumerHandle::new_vt() OK
- open_display_v2() retourne le fd graphics-ipc
- V2GraphicsHandle énumère 1 connecteur 1280x800
- CpuBackedBuffer ARGB8888 plein écran allocable
- add_framebuffer + set_crtc + dirty_framebuffer répondent tous OK
- 30 itérations sync_rect sans erreur ni leak

Validation visuelle automatisée via QEMU monitor screendump :
- QEMU en -display none + -monitor unix:socket
- ncat -U envoie sendkey ret au bootloader puis screendump à T+15s
- ImageMagick convertit PPM → PNG, visualisable

Verrou identifié : fbbootlogd (lancé par init.initfs.d/20_fbbootlogd.service,
embarqué dans le blob initfs) écrit directement dans le framebuffer mémoire
mappé par vesad, hors du pipeline DRM. Il ne release pas le display quand
notre paint fait set_crtc.

Pour vrai visuel, il faut soit :
1. Consommer les events VT côté RedoxOutput (le pattern Orbital, propre)
2. Désactiver fbbootlogd dans l'image (rapide, debug)
3. Implémenter le handoff complet (long, prod)

Le pipeline étant validé, on peut passer phase 5 (input backend) et revenir
sur le visuel quand on aura un compositor qui consomme les events VT.

docs/phase4-display-backend.md enrichi avec l'analyse complète.

Leyoda 2026 – GPLv3

docs/phase4-display-backend.md

@@ -112,6 +112,84 @@ Toutes ces étapes sont des extensions évidentes du test actuel,
 documentées dans `orbital/src/core/display.rs` qu'on peut copier presque
 verbatim.
 
+## Phase 4 vraie : tentative et limite identifiée (2026-05-08 soir)
+
+Crates créés :
+- `redox-wl-display` (lib) : `RedoxOutput` avec `open()` + `take_crtc()`
+  + `pixels_mut()` + `present()` + `present_with_takeover()` + Drop
+- `redox-wl-fullscreen-paint` (bin) : prend le CRTC sur VT 2, peint un
+  dégradé ARGB animé sur 30 frames
+
+**Pipeline logique** : toutes les API DRM répondent OK (open, énumère
+connecteurs, alloc CpuBackedBuffer, add_framebuffer, set_crtc, sync_rect,
+dirty_framebuffer). Aucune erreur retour.
+
+**Validation visuelle automatisée** : QEMU lancé sans display via
+`-display none`, monitor unix socket pour `screendump`. Captures PPM 1280x800
+prises pendant et après l'exécution du paint. Conversion en PNG via ImageMagick
+pour visualisation.
+
+### Verrou rencontré
+
+L'écran capturé montre **les logs kernel + init en mode texte**, pas notre
+dégradé. Notre paint a bien tourné (lignes `[paint]` visibles dans la
+capture, écrites par `fbcond` sur le framebuffer texte), mais le rendu
+graphique de notre `present_with_takeover()` n'apparaît pas.
+
+**Cause** : `fbbootlogd` (lancé par `init.initfs.d/20_fbbootlogd.service`,
+embarqué dans le blob initfs) écrit **directement dans la mémoire
+framebuffer** mappée par vesad, hors du pipeline DRM. Il est ouvert sur le
+scheme `consumer_bootlog` qui force VT 1 actif (cf inputd `main.rs:189`).
+
+Les essais infructueux :
+1. `inputd -A <vt>` après `take_crtc` : warning "switch to non-existent VT"
+   parce que l'env var `VT=N` mise par init n'est pas le VT alloué par inputd
+   (inputd auto-incrémente depuis 2)
+2. `VT=2` (vrai VT alloué) + `inputd -A 2` : retour OK mais l'écran reste
+   sur la sortie fbbootlogd
+3. Désactivation de `30_console` : aucun changement (fbbootlogd est dans
+   l'initfs, pas dans `/usr/lib/init.d/`)
+4. `set_crtc` à chaque frame (`present_with_takeover`) : pas d'effet visuel
+   (fbbootlogd ne lit pas le CRTC, il écrit directement en mémoire)
+
+### Cas où Orbital arrive à afficher
+
+Dans le boot standard, Orbital remplace bien fbbootlogd à l'écran. Mais
+Orbital reçoit un signal **VtEvent::Activate** via inputd et fait un *handoff*
+explicite avec fbbootlogd (cf `inputd::ConsumerHandleEvent::Handoff` qui
+arrête fbbootlogd quand un autre VT prend la main).
+
+Notre `RedoxOutput` ne consomme pas les events VT, donc le handoff ne se
+déclenche pas et fbbootlogd reste actif.
+
+### Étapes restantes pour le visuel
+
+Trois pistes, par coût croissant :
+
+1. **Consommer les events VT côté `RedoxOutput`** — ajouter une boucle
+   `consumer.read_events()` qui détecte `Handoff` et release/re-take le CRTC
+   en conséquence. C'est ce que fait Orbital. **~1 jour de travail.**
+2. **Désactiver fbbootlogd dans l'image** — modifier
+   `~/Projets/Redox/base/init.initfs.d/20_fbbootlogd.service` (commentaire
+   `cmd =`), puis `make all` dans `redox-src/`. Pratique pour test mais pas
+   pour production. **~15 min build + 5 min config.**
+3. **Implémenter le protocole inputd handler complet** — release_display,
+   handoff réciproque, gestion full du switch VT. **~3-5 jours de travail.**
+
+La piste 1 est celle qu'utilise Orbital, donc la cible légitime. La piste 2
+permet de valider visuellement plus tôt.
+
+### Validation indirecte
+
+Même sans visuel, le pipeline est validé par :
+- les codes de retour OK de toutes les API DRM (set_crtc, dirty_framebuffer)
+- les lignes `[paint] frame X/30 présentée` qui sortent à chaque iteration
+- la persistance du buffer `CpuBackedBuffer` (alloc + écriture + sync sans
+  panic, plusieurs centaines de fois sans fuite mémoire visible)
+
+C'est suffisant pour avancer phase 5 (input backend) et y revenir plus tard
+quand on aura un compositor qui consomme les events VT.
+
 ## Prochaine étape : phase 4 vraie
 
 Le test actuel prouve **la possibilité technique**. La phase 4 vraie