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
|
||
|---|---|---|
| crates | ||
| docs | ||
| .gitignore | ||
| README.md | ||
| REDOX_COSMIC_XWAYLAND_RS_PLAN.md | ||
redox-wayland-compositor
Portage de Wayland sur Redox OS, en Rust pur, visant à terme à remplacer Orbital comme serveur graphique de base.
État : phases 1+2+3 du plan directeur complétées le 2026-05-08.
Le pipeline shm Wayland complet est validé end-to-end sur Redox via redoxer
(crate redox-wl-test-shm-pipeline) : socket Unix réel, wl_compositor +
wl_shm globals, fd passing via SCM_RIGHTS, wl_shm_pool + wl_buffer,
wl_surface.attach/damage/commit, lecture pixels côté serveur via le
fd reçu — pixel-perfect.
Structure
.
├── REDOX_COSMIC_XWAYLAND_RS_PLAN.md # plan directeur 14 phases / 5 ans
├── docs/
│ ├── existing-redox-gui.md # phase 1 : audit Orbital + graphics-ipc + inputd + relibc
│ └── redox-wayland-primitives.md # phase 2 : 5 primitives + POC pixels validés sur Redox
├── crates/
│ ├── redox-wl-test-unix-socket/ # primitive 1 : SOCK_STREAM Wayland-shaped
│ ├── redox-wl-test-fd-passing/ # primitive 2 : SCM_RIGHTS mono-process (artefact)
│ ├── redox-wl-test-fd-passing-fork/ # primitive 2b : SCM_RIGHTS via fork (vrai cas Wayland)
│ ├── redox-wl-test-shm-open/ # primitive 3 : shm_open + mmap MAP_SHARED
│ ├── redox-wl-test-poll-multifd/ # primitive 4 : poll() multiplexing + POLLHUP
│ ├── redox-wl-poc-pixels/ # POC : datapath shm + SCM_RIGHTS bout en bout
│ ├── redox-wl-test-handshake/ # phase 3 : wayland-rs server/client registry
│ ├── redox-wl-test-shm-pipeline/ # phase 3 : pipeline shm complet validé
│ └── redox-wl-test-display-backend/ # phase 4.1 : ouvre display Redox via inputd + V2GraphicsHandle
└── (pas de Cargo.toml racine : chaque crate est standalone — voir note ci-dessous)
Note structure : pas de workspace Cargo racine. Chaque crate dans
crates/est autonome avec son propreCargo.tomlet son propretarget/lors de la build. Raison :redoxer build/redoxer runcherche le binaire dans<crate>/target/...et n'arrive pas à le retrouver si letarget/est centralisé au niveau workspace. Ce sera repensé quand on aura un compositor unique vs plusieurs binaires de tests.
Prérequis
- Rust nightly (récent — testé 2026-05-07)
- Target installé :
rustup target add x86_64-unknown-redox --toolchain nightly cargo install redoxerpuisredoxer install(sysroot Redox ~456 Mo)- Repo upstream
Smithay/wayland-rscloné en../wayland-rs/(paths relatifs depuiscrates/*/Cargo.toml)
Reproduire les tests
Chaque crate s'exécute via redoxer (mini-VM Redox sous QEMU) :
cd crates/redox-wl-test-shm-pipeline
redoxer run --release
Pattern attendu en fin d'exécution : [test-XX] PASS: ....
Important : utiliser
redoxer buildouredoxer run, pascargo build --target=x86_64-unknown-redoxdirect qui fait un fail au link (undefined reference CMSG_NXTHDR/CMSG_DATA) parce que le linker host ne sait pas chaîner librelibc.a du sysroot Redox.redoxerconfigure le linker correctement.
Tests qui exigent un vrai framebuffer
Les binaires qui touchent au display (à partir de redox-wl-test-display-backend)
ne tourneront pas sous redoxer run standard car celui-ci est headless.
Deux voies pour les exécuter :
Voie A — redoxer exec --gui (mini-VM interactive)
cd crates/redox-wl-test-display-backend
redoxer build --release
redoxer exec --gui target/x86_64-unknown-redox/release/redox-wl-test-display-backend
Ouvre une fenêtre QEMU, boote une mini-VM Redox avec framebuffer, lance le binaire. À fermer manuellement quand le test est fini.
Voie B — Image complète + make qemu
Pousser le binaire dans une image Redox bootable via redoxfs-fuse, puis booter en mode interactif. Étapes :
# 1. Monter l'image (redoxfs reste en foreground tant que monté)
mkdir -p /tmp/redox-mnt
~/Projets/Redox/redox-src/build/fstools/bin/redoxfs \
~/Projets/Redox/redox-src/build/x86_64/desktop/harddrive.img \
/tmp/redox-mnt &
sleep 2
# 2. Copier le binaire dans /usr/bin de l'image
cp ~/Projets/Redox/redox-wayland-compositor/crates/redox-wl-test-display-backend/target/x86_64-unknown-redox/release/redox-wl-test-display-backend \
/tmp/redox-mnt/usr/bin/
# 3. Démonter
fusermount -u /tmp/redox-mnt
rmdir /tmp/redox-mnt
# 4. Booter (avec clavier FR si besoin, voir hook QEMU_USER_FLAGS dans mk/qemu.mk)
cd ~/Projets/Redox/redox-src
make qemu audio=no QEMU_USER_FLAGS="-k fr"
Une fois Redox bootée :
- Ctrl+Alt+F2 pour basculer sur le VT 2 (console texte), sans Orbital
- Login :
root/ mot de passepassword - Lancer :
redox-wl-test-display-backend
Le binaire écrit aussi sur
/scheme/debug(serial), donc même si tu lances depuis Orbital (VT 3) la sortie sera visible côté host dans le terminal qui a lancémake qemu.
Roadmap
Voir REDOX_COSMIC_XWAYLAND_RS_PLAN.md pour le plan complet 14 phases / 5 ans.
Prochaine étape : phase 4 — display backend Redox via graphics-ipc::V2GraphicsHandle.
Licence
Leyoda 2026 — GPLv3+