From 100f85dd01494019800799db7fa85712f05ba6cc Mon Sep 17 00:00:00 2001 From: Votre Nom Date: Fri, 8 May 2026 20:11:40 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20phase=204=20display=20backend=20POC=20v?= =?UTF-8?q?alid=C3=A9=20runtime?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- docs/phase4-display-backend.md | 162 +++++++++++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 docs/phase4-display-backend.md diff --git a/docs/phase4-display-backend.md b/docs/phase4-display-backend.md new file mode 100644 index 0000000..27af846 --- /dev/null +++ b/docs/phase4-display-backend.md @@ -0,0 +1,162 @@ +# Phase 4 — Display backend Redox : résultats + +> Document produit le 2026-05-08 dans le cadre du plan directeur +> `REDOX_COSMIC_XWAYLAND_RS_PLAN.md`. +> +> **Périmètre** : valider qu'un binaire Rust userspace peut ouvrir le display +> Redox, énumérer les modes via le subset DRM/KMS, et allouer un buffer +> hardware-backed pour le rendu. + +## Verdict global + +**✅ Pipeline display backend Redox accessible et fonctionnel.** + +Le crate `redox-wl-test-display-backend` a tourné dans une session Redox +réelle (image bootée via `make qemu audio=no`), depuis la console VT 2, +avec succès complet de la séquence : + +``` +ConsumerHandle::new_vt() + └─> open_display_v2() + └─> V2GraphicsHandle::from_file() + └─> resource_handles().connectors() → 1 connecteur + └─> mode 1280x800 + └─> get_driver_capability(DumbBuffer) → Ok(1) + └─> CpuBackedBuffer::new(64x64, Argb8888) → OK + └─> shadow_buf().fill(pattern) + └─> sync_rect() + └─> destroy() +``` + +**Aucun blocage.** Le display backend Redox fonctionne directement avec +les APIs Orbital sans modification. + +## Sortie complète du test + +Capturée le 2026-05-08 dans la console VT 2 de Redox bootée via `make qemu` : + +``` +[disp] Phase 4 display backend test on Redox +[disp] VT env = None +[disp] inputd consumer handle opened +[disp] display file opened from inputd path +[disp] V2GraphicsHandle created +[disp] 1 connector(s) reported by KMS subset +[disp] #0 connector connector::Handle(19): state=Connected, 1 mode(s) +[disp] first mode: 1280x800 +[disp] 1 connected display(s) +[disp] driver caps: dumb_buffer=Ok(1) cursor=?x? +[disp] CpuBackedBuffer allocated 64x64 ARGB8888 (shadow=false) +[disp] painted test pattern + sync_rect +[disp] CpuBackedBuffer destroyed +[disp] PASS: display backend pipeline reachable +``` + +Notes : +- `VT env = None` : le binaire a été lancé manuellement, pas via init. + Pour un compositor en production, il sera lancé par init avec `VT=N` et + appellera `inputd -A N` (déjà branché dans le code, désactivé sans VT). +- `cursor=?x?` : `get_driver_capability(CursorWidth/Height)` retourne Err + pour ce display QEMU. Pas critique, on a `DumbBuffer=Ok(1)` qui suffit. +- `shadow=false` : `DumbPreferShadow` capability vaut 0 sur ce backend, + donc les writes vont direct au framebuffer (pas de shadow buffer en RAM). + +## Fait notable : coexistence avec Orbital + +Au moment du test, Orbital tournait sur **VT 3** (init `20_orbital`). +Notre binaire a été lancé depuis **VT 2** (console getty depuis `30_console`). + +inputd a accepté **deux handlers consumer** simultanés sur deux VTs +distincts, et le scheme `display.*` a été accessible depuis le second +handler sans conflit avec celui d'Orbital. + +C'est une **bonne nouvelle pour la stratégie de coexistence du plan directeur** : +on peut développer un compositor Wayland sur un VT séparé tout en gardant +Orbital opérationnel sur le sien — sans modifier l'init Redox. + +## Implications pour la suite + +### Ce qui est désormais validé + +1. Le subset DRM/KMS Redox (`graphics-ipc::V2GraphicsHandle`) est + complet pour les besoins d'un compositor minimal : + - énumération connecteurs/encoders/CRTCs + - création/destruction de DumbBuffers + - mapping CPU writable + sync rect (= dirty_framebuffer) + - support driver capabilities (DumbBuffer, DumbPreferShadow) + +2. La crate Rust `drm 0.15` upstream fonctionne directement sur Redox + sans patch (déjà confirmé en compile time, maintenant en runtime). + +3. La fondation pour un `RedoxOutput` (cf phase 4 du plan directeur) + est en place : il suffit de wrapper ce qu'on a fait dans le test + en une struct propre + ajouter modeset (`set_crtc`) et page-flipping. + +### Ce qui reste pour un display backend complet + +Le test ne fait **pas** : + +- **modeset/scanout** : on alloue un buffer mais on ne fait pas + `set_crtc(crtc, fb, ...)` pour qu'il soit affiché. Orbital tient + déjà le CRTC sur VT 3. Pour vraiment "afficher", il faudra + prendre la place d'Orbital sur un VT (ou lui prendre VT 3). +- **page flipping** : pas de double buffering, pas de + `wait_for_vblank`, pas de `page_flip`. +- **hotplug** : pas d'écoute des events DRM (connector connect/disconnect). +- **resize** : `V2DisplayMap::resize_if_necessary` (cf Orbital + core/display.rs) à porter. +- **cursor plane** : alloc + `set_cursor` non testés (driver caps + cursor=Err sur QEMU desktop, mais c'est dispo selon Orbital). + +Toutes ces étapes sont des extensions évidentes du test actuel, +documentées dans `orbital/src/core/display.rs` qu'on peut copier presque +verbatim. + +## Prochaine étape : phase 4 vraie + +Le test actuel prouve **la possibilité technique**. La phase 4 vraie +consiste à : + +1. Créer une crate `redox-wl-display` propre (pas un test, une lib) + - struct `RedoxOutput` qui wrappe `V2GraphicsHandle` + `Displays` + - méthodes `enumerate()`, `take_crtc()`, `present(buffer)`, + `release_crtc()` +2. Faire un binaire test qui **prend effectivement** le CRTC, écrit + un buffer plein écran, puis le rend (l'écran devient visible + du pattern écrit). +3. Tester en remplaçant temporairement `20_orbital` dans l'init + par notre binaire — Orbital ne tourne pas, notre binaire tient + le display, et l'écran montre notre rendu. + +C'est le premier moment où **on aura de vrais pixels Redox sortis +de notre code** sur l'écran. + +## Code source + +``` +crates/redox-wl-test-display-backend/ +├── Cargo.toml # graphics-ipc, inputd, drm via git deps base.git +└── src/main.rs # 200 lignes, pattern Orbital simplifié +``` + +Build : + +```bash +cd crates/redox-wl-test-display-backend +redoxer build --release +``` + +Test : + +1. Monter `~/Projets/Redox/redox-src/build/x86_64/desktop/harddrive.img` + via `redoxfs` (cf README section "Voie B") +2. Copier le binaire dans `/usr/bin/` de l'image +3. Démonter +4. `cd ~/Projets/Redox/redox-src && make qemu audio=no QEMU_USER_FLAGS="-k fr"` +5. Ctrl+Alt+F2 → console VT 2 +6. login `root` / mot de passe `password` +7. `redox-wl-test-display-backend` + +--- + +*Fin du document de phase 4.*