leyoda/redox-wayland-compositor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
19 commits 1 branch 0 tags 380 KiB
Commit graph

15 commits

Author SHA1 Message Date
Votre Nom
a8898960f1 🎉 Phase 7.8 — resize interactif xdg_toplevel + durcissements 
Resize complet implémenté (compute selon edges + configure cycle)
+ durcissements sécu Move/Resize.

Frontend additions :
- Helper compute_resize_geom(edges, start_x/y/w/h, dx, dy) qui
  interprĂšte le bitmask xdg_toplevel::ResizeEdge :
  Top(1)/Bottom(2)/Left(4)/Right(8). Coins = combinaisons.
  Clamp w/h Ă  MIN_RESIZE_DIM=32.
- Handler xdg_toplevel.Resize complet : valide serial!=0,
  validation soft du serial vs last_button_serial (log warning,
  accept), refuse si drag déjà actif, check client_id (caller ==
  owner de la surface — sĂ©cu dĂ©fense en profondeur). Capture
  start_geom (x,y,w,h) + start_cursor, stocke InteractiveDrag::
  Resize(edges).
- apply_interactive_drag(Resize) : compute new geom, modifie
  registry x/y, envoie xdg_toplevel.configure(w, h, [Resizing]) +
  xdg_surface.configure(serial). Met Ă  jour
  XdgSurfaceData.last_serial = serial pour que l'ack du client
  soit accepté (sinon refusé par garde 7.5).
- Move handler : check client_id ajouté en mode défense en
  profondeur (un client ne peut pas drag une surface d'un autre).

Nouveau crate : redox-wl-test-client-resize (~285 lignes)
- Bind wl_seat
- 1 fenĂȘtre 320x200 cyan + bordure noire
- À T+8s : toplevel.resize(seat, 1, BottomRight)
- Écoute xdg_toplevel.Configure : à chaque new size, ack +
  nouveau shm pool + nouveau buffer + attach + commit
- Vec<WlShmPool>/Vec<WlBuffer> pour ne pas drop les anciens
  pendant que le serveur peut encore les utiliser

PiÚges trouvés :
- last_serial doit ĂȘtre mis Ă  jour Ă  chaque configure envoyĂ©
  pendant le resize, sinon l'ack du client est refusé par le
  garde 7.5 (serial > last_sent → ignoring).
- Le client peut ignorer la taille initiale suggérée par le
  configure du compositor (legal selon spec). Le compositor
  compose à la taille du buffer attaché.
- À chaque resize, garder les anciens pool+buffer en mĂ©moire
  pour ne pas crasher le serveur qui mmap dessus.

Validation runtime : 3 captures Ă  3 tailles distinctes (320x200
initial, ~520x300 agrandi, ~70x25 rétréci) confirment le pipeline
end-to-end. Logs symétriques cÎté client et compositor.

Bilan phase 7 (1-8) :
- 7.1 xdg-shell, 7.2 wl_seat, 7.3 cursor, 7.4 focus/raise,
  7.5 robustesse, 7.6 multi-clients, 7.7 move, 7.8 resize
- Compositor 7.x désormais utilisable pour un toolkit Wayland
  basique. Prochain jalon : port COSMIC (phase 13 plan-directeur,
  réordonnée avant GPU).

Doc complĂšte : docs/phase7-8-resize.md

Leyoda 2026 – GPLv3
 2026-05-13 19:47:53 +02:00
Votre Nom
50f7a064e4 🎉 Phase 7.7 — move interactif xdg_toplevel validĂ© runtime 
Move interactif complet (Resize en stub log-only, reportable Ă  7.8).

Frontend additions :
- enum DragMode { Move, Resize(u32) } et struct InteractiveDrag
  { surface_id, xdg_toplevel_res, xdg_surface_res, mode,
    start_cursor_x/y, start_x/y, start_w/h }
- WaylandFrontend : interactive_drag: Option<InteractiveDrag> +
  last_button_serial: u32
- XdgToplevelData.xdg_surface: Mutex<Option<XdgSurface>> peuplé
  dans xdg_surface.GetToplevel pour retrouver le wl_surface parent
  depuis un toplevel.move/resize
- Handler xdg_toplevel.Move : valide serial != 0, refuse drag déjà
  actif, retrouve SurfaceId via cascade UserData (xdg_surface →
  wl_surface → SurfaceData), capture start_cursor + start_geom,
  stocke InteractiveDrag
- Handler xdg_toplevel.Resize : stub log-only (à compléter 7.8)
- Handler xdg_toplevel.Destroy nettoie interactive_drag si on Ă©tait
  en train de drag cette surface
- MĂ©thode apply_interactive_drag() : applique le delta (cursor -
  start_cursor) Ă  la position de la surface (Move) ou consume le
  motion (Resize stub)
- forward_input(PointerMotion(Relative)) : apply au début, return
  si drag actif (court-circuite l'envoi de motion au client pendant
  un drag, conforme spec Wayland)
- forward_input(PointerButton release) : sort du mode drag
- set_cursor_position : appelle aussi apply_interactive_drag (sans
  ça, les cycles de test programmatique ne déclenchent pas le drag
  car ils court-circuitent forward_input)
- Tracking last_button_serial Ă  chaque button LEFT Pressed

Test client modifications :
- redox-wl-test-client-shm-two bind wl_seat
- Si label=="A", déclenche toplevel.move(&seat, 1) 8s aprÚs le
  commit initial (mécanisme "synthétique" : le client n'écoute pas
  les pointer events, il envoie Move sans attendre un clic — assez
  pour valider le pipeline serveur, durcissement client 7.8)

Validation runtime :
- Cycle compositor temporaire (retiré du binaire final) qui change
  cursor_position Ă  plusieurs positions pendant que le drag est
  actif, screendumps Ă  3 positions distinctes
- Logs frontend :
  [frontend] xdg_toplevel.move: enter drag sid=SurfaceId(0) start=(60,60) cursor=(500,400)
  [frontend] left-release → exit interactive drag
- A déplacée visuellement entre les captures pos1, pos2 et
  post-release ; sortie clipée sur les bords (pas de snap-to-edge,
  WM policy reportable)

Limitations 7.7 :
- Resize non implémenté (stub)
- Validation serial laxiste (serial != 0)
- Pas de contrĂŽle policy (snap-to-edge, min/max)
- Pas de check "surface du mĂȘme client" (sĂ©cu)
- Pas d'event xdg_toplevel.configure([Resizing]) envoyé pendant le drag

Doc complĂšte : docs/phase7-7-move-resize.md

Leyoda 2026 – GPLv3
 2026-05-13 19:22:04 +02:00
Votre Nom
a87de02555 🎉 Phase 7.6 — multi-clients paquet B validĂ© runtime 
3 livrables :

1. Cleanup post-disconnect (corrige sub-bug 7.5)
   - DumbClientData::disconnected push dans Arc<Mutex<Vec<ClientId>>>
     partagé (peuplé à accept_pending_clients)
   - SurfaceData.client_id: Mutex<Option<ClientId>> capturé au
     wl_compositor.create_surface pendant que _client: &Client est
     encore vivant (à la déconnexion surf.client() retourne None,
     on ne pourrait plus déduire le mapping)
   - WaylandFrontend.garbage_collect_dead_clients drain la queue
     et nettoie surfaces_by_id + registry + focused_surface +
     cursor_surface_id + pointers/keyboards orphelins
   - Appelée à chaque tick depuis le compositor binaire aprÚs
     dispatch_clients

2. wl_buffer.release aprĂšs commit-copy
   - SurfaceData.pending_buffer passé de Option<BufferData> à
     Option<wl_buffer::WlBuffer> pour avoir le Resource sous la main
   - Au commit, aprĂšs la lecture des params via
     buf.data::<BufferData>().cloned() et la copie des pixels,
     appel buf.release() qui signale au client qu'il peut réutiliser
     son buffer

3. Filtrage events par client focused
   - forward_input calcule focused_client_id depuis
     focused_surface.client().map(|c| c.id())
   - wl_pointer.{motion,button,axis,frame} et wl_keyboard.key
     n'arrivent qu'aux Resources dont client_id matche le focused
   - PointerButton recalcule focused_cid APRÈS le hit_test+set_focus
     pour que le clic atterrisse bien sur le nouveau client

PiÚges trouvés :
- Resource n'a pas de client_id() direct → utiliser
  client().map(|c| c.id())
- À l'instant du disconnected(), surf.client() retourne dĂ©jĂ  None
  → capturer le ClientId au CreateSurface, pas aprùs

Validation runtime :
- Test fuzz : surface fantÎme du fuzz1 (brutal exit) nettoyée,
  surfaces=0 stable post-fuzz, capture phase7-6-cleanup-no-ghost.png
  confirme visuellement (vs rectangle noir 7.5)
- Test 2 clients : redox-wl-test-client-shm-two avec parent + fork
  affiche A vert + B magenta en parallĂšle, surfaces=2 stable,
  capture phase7-6-two-clients.png
- Log frontend : [frontend] garbage_collect: client X → destroyed
  1 surfaces (fuzz1), 0 surfaces (fuzz2-4 qui ont cleanup propre)

Doc complĂšte : docs/phase7-6-multi-clients.md

Leyoda 2026 – GPLv3
 2026-05-13 18:51:33 +02:00
Votre Nom
7e81dec637 🎉 Phase 7.5 — robustesse paquet A validĂ©e runtime 
Compositor anti-panic face à 4 cas malformés exercés en succession :
brutal exit sans destroy, ack_configure avec mauvais serial,
create_buffer avec dimensions nulles, create_buffer avec stride
incohérent. Aucun crash, aucun blocage, ticks compositor continus
30s+ aprĂšs la fin du fuzz.

Frontend hardening :
- BufferData.valid: bool, mis Ă  false dans wl_shm_pool.create_buffer
  si dimensions/stride/offset incohérents avec la taille du pool.
  Le wl_buffer est quand mĂȘme crĂ©Ă© (contrat wayland-server) mais
  ignoré au commit.
- ShmPool::read_argb signature passée de Vec<u32> à Option<Vec<u32>>.
  Refuse de lire si w/h/stride invalides ou si l'accĂšs final
  dépasse self.size. Calculs en checked_add/checked_mul pour éviter
  tout overflow sur des params adversariaux. Évite tout accùs UB.
- xdg_surface.ack_configure refuse les serials > last_sent (log +
  ignore, pas de post_error pour 7.5 — tolĂ©rance volontaire).
- wl_surface.commit court-circuite la lecture pour les buffers
  invalides ou si read_argb retourne None (log warning, surface
  garde son ancien contenu).

Nouveau crate : redox-wl-test-fuzz-protocol (~370 lignes)
- fork() pour chaque cas afin qu'un crash potentiel d'un cas ne
  contamine pas les suivants
- 4 cas : brutal exit, bad ack serial, null dimensions, bad stride
- Le parent attend chaque enfant via waitpid avant le suivant

Validation runtime QEMU :
- [fuzz1..4] tous PASS, [fuzz] PASS final
- [frontend] xdg_surface.ack_configure: serial 99999 > last_sent 2, ignoring
- [frontend] wl_shm_pool.create_buffer rejected: offset=0 width=0 height=0 stride=0
- [frontend] wl_shm_pool.create_buffer rejected: offset=0 width=100 height=10 stride=10
- Compositor continue Ă  ticker 30+ s post-fuzz, curseur actif,
  surfaces des fuzz suivants créées et focusées normalement.

Sub-bug documenté (à corriger 7.6) : la surface du fuzz1 (exit
brutal sans destroy) persiste aprÚs la déconnexion du client.
wayland-server détecte le close socket mais ne réveille pas
automatiquement le wl_surface.Destroy handler. À hooker dans
DumbClientData::disconnected pour le cleanup explicite.

Doc complĂšte : docs/phase7-5-robustness.md.

Leyoda 2026 – GPLv3
 2026-05-13 11:57:21 +02:00
Votre Nom
c40ca9fcc8 🎉 Phase 7.4 — focus + raise on click validĂ©s runtime 
Sur clic gauche, le compositor fait hit_test Ă  la position curseur,
raise la surface ciblée au top du Z-order et transfÚre le keyboard
focus Ă  cette surface (broadcast wl_keyboard.leave/enter via le
set_focus déjà implémenté en 7.2).

Frontend additions :
- HashMap<SurfaceId, wl_surface::WlSurface> dans WaylandFrontend,
  peuplée au wl_compositor.create_surface (capture du retour de
  data_init.init), nettoyée au wl_surface.destroy
- Au wl_surface.destroy : clear focused_surface et cursor_surface_id
  si la surface détruite était l'une de ces références (évite les
  wl_surface fantĂŽmes dans les events suivants)
- forward_input(PointerButton.left=true) déclenche
  registry.hit_test(cursor_x, cursor_y), puis si la cible n'est pas
  une surface curseur : registry.raise + set_focus(target)
- println! tracing pour [frontend] left-click et focus change

Nouveau crate : redox-wl-test-client-shm-two
- Binaire qui fork() : parent = fenĂȘtre A (verte, pyramide), enfant
  = fenĂȘtre B (magenta, double cercle) aprĂšs sleep 800ms
- 2 connexions Wayland indĂ©pendantes au mĂȘme socket compositor
- timeout 160s aligné sur le compositor 180s

Validation runtime : 4 captures synchronisées via cycle de
positionnement curseur temporaire (retiré aprÚs) prouvent les
2 transitions de Z-order :
- initial : B au top (commit le plus récent)
- click@(80,80) → hit A → A passe au top
- click@(400,280) → hit B → B repasse au top

Traces /tmp/comp.log (extraites via redoxfs) confirment :
[frontend] left-click @ (80, 80) → hit_test = Some(SurfaceId(0))
[frontend] focus change: Some(SurfaceId(1)) → Some(SurfaceId(0))
[frontend] left-click @ (400, 280) → hit_test = Some(SurfaceId(1))
[frontend] focus change: Some(SurfaceId(0)) → Some(SurfaceId(1))

Pipeline validé end-to-end :
mouse_button QEMU → ps2d → inputd → InputBackend::poll →
RedoxInputEvent::PointerButton → forward_input → hit_test →
raise + set_focus → wl_keyboard.leave/enter broadcast.

Doc complĂšte : docs/phase7-4-focus-raise.md.

Leyoda 2026 – GPLv3
 2026-05-13 10:21:05 +02:00
Votre Nom
5f7587e79e 🎉 Phase 7.3 — curseur software validĂ© runtime 
Sprite curseur 16x16 ARGB dessiné par-dessus la composition aprÚs
`SurfaceRegistry::compose_into()`, avec alpha blending non
prémultiplié (`out = src + dst * (1 - src.a)`) et hot-spot
configurable.

Frontend additions :
- `cursor_surface_id` / `cursor_hot_x` / `cursor_hot_y` /
  `cursor_visible` dans `WaylandFrontend`
- `is_cursor: AtomicBool` dans `SurfaceData`
- `default_cursor_sprite()` : flĂšche hardcoded 16x16
- `blend_argb_over(src, dst)` avec fast paths a=0/a=255
- `draw_cursor<F: Framebuffer>(target)` : clip aux bords du fb,
  blit pixel par pixel
- `set_cursor_initial_position` / `set_cursor_position` /
  `cursor_position` publiques
- `wl_pointer.set_cursor` handler : store la surface client,
  marque `is_cursor = true`, l'exclut du Z-order (visible=false)
- `wl_surface.commit` lit `is_cursor` → si curseur, pas de
  raise/focus et reste invisible dans la composition normale
- `cursor_visible = true` au premier PointerMotion(Relative)

Binaire compositor :
- `set_cursor_initial_position(fb_w/2, fb_h/2)` au boot
- `frontend.draw_cursor(&mut output)` aprĂšs `compose_into`
- timeout porté de 60s à 180s pour validation visuelle confortable

Test client SHM :
- timeout porté de 25s à 170s pour rester aligné avec le compositor

Validation runtime : 5 screendumps Ă  5 positions distinctes
prouvent que `draw_cursor` est appelé correctement quel que soit
`(cursor_x, cursor_y)`, dont 2 captures par-dessus la fenĂȘtre
client SHM (overlay alpha-blended sur les bandes arc-en-ciel).

Note runtime : Redox n'a pas de driver USB tablet opérationnel
sous QEMU. `mouse_move` PS/2 du monitor QEMU ne produit pas non
plus de PointerMotion cÎté inputd. Validation faite en mode
programmatique via un cycle temporaire `set_cursor_position`,
retirĂ© du binaire aprĂšs screendumps. À investiguer ps2d/vesad
en phase 7.5 ou plus tard.

Doc complĂšte : `docs/phase7-3-cursor.md`.

Leyoda 2026 – GPLv3
 2026-05-13 09:06:56 +02:00
Votre Nom
baa94701bf 🎉 Phase 7.2 — wl_seat + wl_keyboard + wl_pointer routing input 
Capture preuve : docs/phase7-2-input-routing.png — fenĂȘtre client
xdg_toplevel 480x320 (damier turquoise) Ă  (60,60), compositor stable
pendant que les keyboard events transitent en parallĂšle.

Validation runtime exhaustive : tous les events injectés via QEMU
sendkey/mouse_button arrivent au client via wl_keyboard.key /
wl_pointer.button :
  [client-input] wl_keyboard.key key=54 Pressed   ← 'c'
  [client-input] wl_keyboard.key key=50 Pressed   ← shift
  [client-input] wl_keyboard.key key=38 Pressed   ← 'a' avec shift
  [client-input] wl_keyboard.key key=37 Pressed   ← ctrl
  ...

Modifications redox-wl-wayland-frontend :
- + dep redox-wl-input (pour InputEvent type)
- wl_seat global v7 avec capabilities = Pointer | Keyboard
- wl_seat.name = "redox-wl-seat0" (v2+)
- Dispatch wl_seat : GetPointer, GetKeyboard, GetTouch (no-op),
  Release ; au get_keyboard envoie keymap NoKeymap + repeat_info
- Dispatch wl_pointer / wl_keyboard / wl_touch : Release retire la
  resource de state.{pointers,keyboards}
- forward_input(InputEvent) public method qui broadcast
  wl_keyboard.key, wl_pointer.motion/button/axis/frame aux clients
- set_focus(surface) public method qui envoie keyboard/pointer
  enter/leave events sur changement de focus
- Tracking : focused_surface, cursor_x/y, next_input_serial,
  input_time_ms, pointers/keyboards Vec<Resource>

Modif wl_surface.commit : appelle set_focus(Some(_resource)) pour que
la derniÚre surface commitée reçoive l'enter automatiquement
(politique simple 7.2, Ă  raffiner en 7.4).

Modif compositor binaire (redox-wl-compositor) :
- Forward chaque InputEvent au frontend.forward_input(&ev)
- Esc reste géré cÎté compositor pour exit propre

Bin redox-wl-test-client-input ajouté (~280 lignes) :
- Bind wl_compositor + wl_shm + xdg_wm_base + wl_seat
- get_keyboard + get_pointer aprĂšs reception caps
- Crée xdg_toplevel + buffer ARGB damier turquoise
- Log chaque wl_keyboard.{enter,leave,key,modifiers,repeat_info}
  et wl_pointer.{enter,leave,motion,button,axis}
- Boucle event_queue : flush + prepare_read.read + dispatch_pending
  (CORRECT pattern pour wayland-rs ; le bug initial Ă©tait d'utiliser
  juste dispatch_pending qui ne lit pas le socket)

CritÚre de fin 7.2 validé : un client qui bind wl_seat reçoit
keyboard events via wl_keyboard.key sans panic serveur.

Limitations connues (sous-tickets ultérieurs) :
- Keymap NoKeymap (pas de XKB layout) — 7.2 utilise scancodes raw
- Broadcast Ă  tous les keyboards/pointers (pas de filtrage par
  client focus) — multi-client viendra en 7.6
- Pas de pointer.motion testé (besoin -device usb-tablet QEMU)
- Pas de validation modifier state (juste enter envoie 0,0,0,0)

Image Redox restaurée à boot Orbital normal.

Phrase reprise 7.3 :
> Reprendre au commit XXX : Phase 7.3 curseur software. Dessiner un
> sprite curseur 16x16 par-dessus la composition, position basée sur
> InputBackend cursor_x/y. Hot-spot configurable via wl_pointer.set_cursor
> (déjà no-op à 7.2). Tester avec usb-tablet QEMU pour avoir motion absolu.

Leyoda 2026 – GPLv3
 2026-05-09 15:05:03 +02:00
Votre Nom
4bff319c7f 🎉 Phase 7.1 — xdg-shell minimal validĂ© runtime 
Capture preuve : docs/phase7-1-xdg-toplevel.png — fenĂȘtre 320x240 du
client externe positionnée à (60, 60) par le compositor (cascade par
défaut), avec bandes verticales arc-en-ciel + bordure noire 2px.

DiffĂ©rence visuelle vs phase 6.4 : la fenĂȘtre est maintenant
positionnée par le compositor (pas plaquée à 0,0).

Modifications redox-wl-wayland-frontend :
- + dep wayland-protocols (feature server)
- xdg_wm_base global v5
- XdgSurfaceData { wl_surface, last_serial, acked_serial }
- XdgToplevelData { title, app_id }
- SurfaceData.xdg_pending_initial_configure : bloque l'affichage tant
  que ack-configure pas reçu (sémantique xdg-shell standard)
- WaylandFrontend.next_xdg_serial : counter monotone serial
- WaylandFrontend.next_toplevel_index : cascade position +60 par fenĂȘtre
- DEFAULT_TOPLEVEL_SIZE = 640x480 envoyé en initial configure
- Dispatch xdg_wm_base : GetXdgSurface, CreatePositioner (no-op),
  Pong (no-op), Destroy (no-op)
- Dispatch xdg_positioner + xdg_popup : no-op (out of scope)
- Dispatch xdg_surface :
  - GetToplevel → cascade pos + envoie xdg_toplevel.configure(640,480)
    + xdg_surface.configure(serial)
  - AckConfigure(serial) → enregistre + dĂ©bloque affichage
  - Destroy → cache la surface
- Dispatch xdg_toplevel :
  - SetTitle / SetAppId → stocke
  - tout le reste ignoré (move, resize, maximized, ...)

redox-wl-test-client-shm adapté :
- + dep wayland-protocols (feature client)
- bind 3 globals : wl_compositor, wl_shm, xdg_wm_base
- Dispatch XdgWmBase::Event::Ping → pong (au cas oĂč)
- Dispatch XdgSurface::Event::Configure → store serial
- Dispatch XdgToplevel::Event::Configure / Close → log
- Workflow runtime :
  1. create_surface + get_xdg_surface + get_toplevel
  2. set_title / set_app_id
  3. surface.commit (initial empty)
  4. attente Configure event (timeout 5s)
  5. ack_configure(serial)
  6. shm + buffer + attach + commit POST-ack
  7. boucle 25s
  8. destroy propre

Init submodule wayland-rs/wayland-protocols/protocols (XML files
gitlab.freedesktop.org/wayland/wayland-protocols).

Validation runtime QEMU complĂšte :
[client] globals : compositor=true shm=true xdg_wm_base=true
[client] xdg_toplevel configure suggéré : 640x480
[client] initial configure reçu, serial=1
[client] ack_configure(1)
[client] buffer attach + damage + commit POST-ack
[comp]  tick=30..450 surfaces=1 elapsed=1.2..18.2s
PNG capturée à T+14s : surface visible à (60,60), bandes RGB+jaune+
violet+orange comme attendu.

CritÚre de fin 7.1 validé : client xdg-shell crée toplevel, reçoit
configure, ack, commit, affiche via shm, sans panic serveur, 18s
stable, destroy propre.

Limitations connues : focus, cursor, move/resize, multi-client,
robustesse — sous-tickets 7.2-7.7.

Image Redox restaurée à boot Orbital normal.

docs/phase7-1-xdg-shell.md : compte-rendu complet, cycle de vie,
limitations, plan 7.2.

Leyoda 2026 – GPLv3
 2026-05-09 14:34:45 +02:00
Votre Nom
8a897d975d 🎉🎉🎉 Phase 6.4 — Wayland complet : un client externe affiche ses pixels 
Capture preuve : docs/phase6-4-wayland-client-surface.png — pattern ARGB
320x240 écrit par un binaire client Wayland externe affiché par notre
compositor sur le framebuffer Redox dans QEMU.

Crates ajoutés :

redox-wl-wayland-frontend (lib, ~430 lignes) :
- WaylandFrontend struct avec SurfaceRegistry intégré + Display<Self>
  + ListeningSocket
- bind_absolute(path), accept_pending_clients(), dispatch_clients(),
  flush_clients(), notify_frame_done()
- ShmPool : mmap + munmap on drop
- BufferData : Arc<Mutex<ShmPool>> + offset/w/h/stride/format
- SurfaceData : Arc<...> qui contient SurfaceId + pending_buffer
  + pending_frame_callbacks
- Dispatch impls : wl_compositor v5, wl_shm v1 (advertise ARGB+XRGB),
  wl_shm_pool, wl_buffer, wl_surface (attach/damage/commit/frame/destroy),
  wl_callback, wl_region (no-op)

SĂ©mantique commit : copy-on-commit (lit pixels via mmap, copie dans
SurfaceBuffer owned). Plus simple que de garder le mmap vivant. Au
commit, raise auto la surface (politique simple).

redox-wl-compositor (bin, ~150 lignes) :
- ouvre RedoxOutput + InputBackend partagé
- bind WaylandFrontend sur /tmp/redox-wl-comp.sock
- export WAYLAND_DISPLAY env var
- boucle main 30 fps : accept clients → dispatch → input → render →
  notify_frame_done → flush
- Esc = exit propre

redox-wl-test-client-shm (bin, ~170 lignes) :
- attente du socket compositor (50 retries × 100ms)
- Connection::from_backend aprĂšs UnixStream::connect
- Dispatch handlers minimal pour wl_registry, compositor, shm, pool,
  buffer, surface
- shm_open + ftruncate + mmap + pattern ARGB déterministe (orange
  + bandes diagonales)
- shm.create_pool(fd) + pool.create_buffer + compositor.create_surface
- surface.attach + damage_buffer + commit
- reste connecté 25s pour qu'on capture l'écran

Validation runtime : compositor en init VT=2, client lancé en parallÚle
via 30_console. Logs serial montrent toute la séquence :
  [client] globals : compositor=true shm=true
  [client] shm créé, peint 320x240 ARGB
  [client] surface attach + damage + commit envoyés
  [comp]  tick=30 surfaces=1 elapsed=1.2s
  [comp]  tick=510 surfaces=1 elapsed=20.7s    ← surface persiste 20+s

PNG capturée à T+12s montre la surface du client visible sur le
framebuffer. Position (0,0) parce que xdg-shell absent (placement
absent). Reportable phase 7.

Image Redox restaurée à boot Orbital normal.

docs/phase6-4-wayland-frontend.md : compte-rendu complet, archi,
sémantique commit, limitations, plan phase 7.

Phase 6 entiĂšrement close. Le compositor naissant fonctionne avec un
vrai client Wayland externe sur Redox.

Leyoda 2026 – GPLv3
 2026-05-09 13:30:05 +02:00
Votre Nom
509aae7769 🎉 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
Votre Nom
a9bb88d9f3 🎉 Phase 5 — input backend Redox validĂ© runtime 
Crates ajoutés :
- redox-wl-input (lib) : InputBackend wrappe Arc<ConsumerHandle>
  + enum InputEvent { Key, TextInput, PointerMotion(Relative)?,
  PointerButton, PointerScroll, Quit, Unhandled, Handoff }
- redox-wl-test-input (bin) : ouvre display + take CRTC + peint bleu
  marine + polle events 30s en logguant chaque event

Modifs redox-wl-display :
- _consumer: ConsumerHandle → consumer: Arc<ConsumerHandle>
- + pub fn consumer() -> Arc<ConsumerHandle> pour partage avec input

Validation runtime sur Redox bootée via QEMU + monitor unix socket :
20 events injectés via `sendkey` et `mouse_button` HMP commands, tous
reçus et traduits correctement :
- a/b/c PRESS+RELEASE — keymap directe
- shift+a → 'A' uppercase — modificateur fonctionnel
- ctrl+c → ctrl PRESS + 'c' PRESS — composition fonctionnelle
- mouse_button 1/0 → PointerButton L=true/false
- Esc, Enter, Shift, Ctrl reçus avec scancode brut

Décision architecturale : un seul ConsumerHandle partagé via Arc entre
RedoxOutput (pour vie du VT) et InputBackend (lecteur unique d'events).
Sinon deux consumers = deux VTs distincts dont un seul reçoit les events.

Capture preuve : docs/phase5-blue-screen-with-input.png — bleu marine
plein Ă©cran 1280x800 confirmant que display + input fonctionnent
ensemble dans le mĂȘme binaire.

docs/phase5-input-backend.md : compte-rendu complet.

Image restaurée à boot Orbital normal aprÚs session.

Leyoda 2026 – GPLv3
 2026-05-09 11:22:54 +02:00
Votre Nom
753a30757b 🎉 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
Votre Nom
5b1e038333 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
Votre Nom
100f85dd01 docs: phase 4 display backend POC validé runtime 
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
 2026-05-08 20:11:40 +02:00
Votre Nom
53e6626231 Initial commit: phases 1-3 du portage Wayland Rust pour Redox OS 
Plan directeur 14 phases / 5 ans (REDOX_COSMIC_XWAYLAND_RS_PLAN.md).

Phase 1 — Audit Redox (docs/existing-redox-gui.md, 486 lignes) :
- Orbital, graphics-ipc (API DRM compatible Linux subset KMS), inputd, vesad
- relibc support : AF_UNIX, SCM_RIGHTS, shm_open, mmap, poll
- 3 manques identifiés : memfd_create, keymap XKB, AT-SPI

Phase 2 — Validation primitives sur Redox via redoxer (5 tests + 1 POC) :
- test-unix-socket : SOCK_STREAM Wayland-shaped roundtrip
- test-fd-passing : SCM_RIGHTS mono-process (artefact kernel)
- test-fd-passing-fork : SCM_RIGHTS multi-process (validation Wayland critique)
- test-shm-open : shm_open + mmap + persistance + unlink
- test-poll-multifd : poll() multiplexing + POLLHUP
- poc-pixels : datapath shm + SCM_RIGHTS bout en bout (10000 pixels ARGB)

Phase 3 — wayland-rs sur Redox (compile + runtime) :
- wayland-{scanner,backend,server,client} compilent pour x86_64-unknown-redox
  sans patch upstream (rustix supporte Redox via libc backend)
- test-handshake : server/client wl_registry handshake roundtrip
- test-shm-pipeline : pipeline complet (ListeningSocket Unix réel + fd passing
  via wl_shm.create_pool + wl_shm_pool + wl_buffer + wl_surface + commit +
  serveur lit pixels via fd reçu, validation pixel-perfect)

Verdict phase 3 : wayland-rs upstream est viable sur Redox out-of-the-box,
le port "Wayland sur Redox" est désormais un problÚme de compositor à écrire,
pas de stack Ă  porter.

Prérequis build : redoxer (pas cargo direct, car CMSG_NXTHDR/CMSG_DATA
ne sont pas linkés autrement vers librelibc.a).

Leyoda 2026 – GPLv3
 2026-05-08 17:41:55 +02:00