redox-wayland-compositor/crates/redox-wl-fullscreen-paint/Cargo.toml

[package]
name = "redox-wl-fullscreen-paint"
version = "0.1.0"
edition = "2021"

[dependencies]
redox-wl-display = { path = "../redox-wl-display" }
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 2026-05-09 10:11:06 +02:00			`[package]`
			`name = "redox-wl-fullscreen-paint"`
			`version = "0.1.0"`
			`edition = "2021"`

			`[dependencies]`
			`redox-wl-display = { path = "../redox-wl-display" }`