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
Test exécuté avec succès sur Redox bootée via make qemu :
[disp] 1 connector(s) reported by KMS subset
[disp] #0 connector ::Handle(19): state=Connected, 1 mode(s)
[disp] first mode: 1280x800
[disp] CpuBackedBuffer allocated 64x64 ARGB8888 (shadow=false)
[disp] painted test pattern + sync_rect
[disp] PASS: display backend pipeline reachable
Implications majeures :
- la crate drm 0.15 upstream fonctionne sur Redox runtime, pas seulement
compile-time
- graphics-ipc::V2GraphicsHandle est un subset DRM/KMS suffisant pour
un compositor minimal
- inputd accepte plusieurs consumers sur des VTs différents → on peut
développer un compositor sur VT 2 tout en gardant Orbital sur VT 3
(validation de la stratégie de coexistence du plan directeur)
Le test n'inclut pas encore modeset/scanout (set_crtc) — c'est l'étape
suivante : crate redox-wl-display + binaire qui prend le CRTC pour
afficher de vrais pixels.
docs/phase4-display-backend.md : compte-rendu complet + roadmap.
Leyoda 2026 – GPLv3
