leyoda/redox-wayland-compositor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
redox-wayland-compositor/crates/redox-wl-display/Cargo.toml

13 lines
408 B
TOML
Raw Normal View History

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-display"
version = "0.1.0"
edition = "2021"
description = "Display backend wrapper around graphics-ipc + drm subset for Redox"
[dependencies]
drm = "0.15"
graphics-ipc = { git = "https://gitlab.redox-os.org/redox-os/base.git" }
inputd = { git = "https://gitlab.redox-os.org/redox-os/base.git" }
🎉 Phase 4 vraie validée visuellement : pixels custom plein écran Capture : docs/phase4-victory-1280x800.png — dégradé ARGB animé 1280x800 écrit par redox-wl-fullscreen-paint, occupant tout l'écran QEMU sans trace de bootlog, fbcond ou Orbital. Cause racine du verrou (3 bugs en cascade) : 1. ConsumerHandle local à RedoxOutput::open() → droppé en fin de fn → inputd::on_close retirait le VT de self.vts → tous les `inputd -A <vt>` ultérieurs retournaient warning "switch to non-existent VT" 2. L'env var VT=N posée par init n'a aucun lien avec le VT alloué par inputd. inputd auto-incrémente next_vt_id à partir de 2 (VT 1 réservé bootlog). Avec fbbootlogd VT 1 + fbcond VT 2, notre paint = VT 3. 3. Sans le bon VT activé, set_crtc est silencieusement no-op côté driver-graphics (lib.rs:575 : `if *vt == self.active_vt { ... }`). Fixes : - RedoxOutput stocke `_consumer: ConsumerHandle` pour préserver le VT - RedoxOutput.vt() lu via fpath sur consumer fd (inputd retourne `<scheme>/<vt>`) - Binary lit output.vt() puis fait inputd -A <vt> avec le bon numéro - 300ms de sleep pour propagation active_vt avant take_crtc Validation automatisée : qemu -display none + monitor unix socket + ncat -U pour sendkey ret + screendump à T+14s + ImageMagick. Image Redox restaurée à boot Orbital normal après la session. Phase 4 close. La piste 1 (consume events VT) reste utile pour le hot-switch propre Ctrl+Alt+Fn mais n'est plus bloquante. Leyoda 2026 – GPLv3
2026-05-09 10:46:20 +02:00
libredox = "0.1"
🎉 Phase 6.3 — display + input + compositor-core intégrés runtime Captures preuves dans docs/phase6-3-*.png : 4 frames qui prouvent visuellement que raise change l'ordre Z et que compose_into propage le résultat à l'écran QEMU : - default-z.png : 3 surfaces overlap, blue top (créé en dernier) - red-top.png : sendkey 1 → raise(red) → red couvre vert et bleu - green-top.png : sendkey 2 → raise(green) → green couvre tout dans sa zone - blue-top.png : sendkey 3 → raise(blue) → retour visuel à initial Modifications : compositor-core (commit dbf3bff → maintenant) : - + iter_z_order_front_to_back() : utile pour hit testing - + hit_test(x, y) -> Option<SurfaceId> : trouve la surface visible la plus haute qui contient le point - + 4 tests unitaires : 27 total / 27 pass natif (0.00s) redox-wl-display : - + dep redox-wl-compositor-core - + impl Framebuffer for RedoxOutput (délègue à pixels_mut + width/height) bin redox-wl-test-compose-static (190 lignes) : - ouvre RedoxOutput + take_crtc - crée InputBackend partagé - 3 surfaces ARGB unies (rouge/vert/bleu) avec overlap centré - boucle event : '1'/'2'/'3' raise resp. red/green/blue - clic souris → hit_test puis raise (motion non testé sans usb-tablet) - ré-render seulement si raise → économie CPU - present_with_takeover() à chaque iter pour tenir le CRTC Validation QEMU automatisée : sendkey 1/2/3 + screendump entre chaque. Les 4 PNG montrent l'ordre Z évoluer correctement. Image Redox restaurée à boot Orbital normal. docs/phase6-compositor-core.md : compte-rendu 6.1-6.3 complet, architecture, dépendances, API, limitations, plan 6.4. Phase 6.3 close. Reste 6.4 (frontend Wayland : wl_compositor + wl_shm + xdg-shell mappés vers compositor-core, damage tracking, frame callbacks). Estimé 2-3 sessions. Leyoda 2026 – GPLv3
2026-05-09 12:20:04 +02:00
redox-wl-compositor-core = { path = "../redox-wl-compositor-core" }
Reference in a new issue Copy permalink