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 · 2026-05-08 17:41:55 +02:00 · 53e6626231
commit 53e6626231
21 changed files with 3676 additions and 0 deletions
--- a/docs/existing-redox-gui.md
+++ b/docs/existing-redox-gui.md
@ -0,0 +1,486 @@
+# Audit Phase 1 — Existant Redox GUI
+
+> Document produit le 2026-05-08 dans le cadre du plan directeur
+> `REDOX_COSMIC_XWAYLAND_RS_PLAN.md` (phase 1 : audit avant code).
+>
+> **Périmètre** : comprendre l'architecture graphique actuelle de Redox
+> (Orbital + drivers + primitives) pour calibrer le portage Wayland.
+
+## Résumé exécutif
+
+Redox dispose **déjà d'une fondation graphique plus mûre que prévu** :
+
+- **Une API DRM compatible Linux** (subset KMS) exposée via `graphics-ipc` et utilisée par Orbital
+- **Plusieurs drivers** : VESA firmware (`vesad`), virtio-gpu (`virtio-gpud`), Intel HD (`ihdgd`)
+- **Un input multiplexer** (`inputd`) qui gère VT switching, keymaps, producteurs/consommateurs
+- **Orbital** très compact (~3900 lignes Rust) qui valide le pattern serveur-clients via scheme
+
+Côté primitives système, **l'essentiel de ce que Wayland exige est déjà là** :
+
+- AF_UNIX sockets via le scheme `chan:` ✅
+- `sendmsg`/`recvmsg` avec **SCM_RIGHTS implémenté** (fd passing) ✅
+- `shm_open` via `/scheme/shm/` ✅
+- `mmap MAP_SHARED` ✅
+- `poll`/`epoll` ✅
+- ⚠️ `memfd_create` : numéro syscall défini mais implémentation à vérifier
+
+**Conclusion** : la phase 2 (primitives OS) du plan directeur sera moins lourde que craint.
+La majorité des briques existent — il faudra surtout valider le comportement par tests dédiés.
+
+---
+
+## 1. Architecture Orbital
+
+### 1.1 Point d'entrée et boot
+
+`orbital/src/main.rs` (82 lignes) :
+
+```text
+main()
+  └─ orbital()
+       ├─ lit env "VT" (passé par inputd au boot)
+       ├─ Orbital::open_display()           ← ouvre display via inputd
+       ├─ exec "inputd -A <vt>"             ← s'enregistre comme handler du VT
+       ├─ Config::from_path("/ui/orbital.toml")
+       ├─ OrbitalScheme::new(displays, config)
+       └─ orbital.run(scheme, login_cmd)    ← event loop principal
+```
+
+**Note séquence de boot** : c'est `inputd` qui orchestre l'ouverture du display
+au moment où le VT s'active. Orbital ne touche pas directement aux drivers
+graphiques — il passe par inputd qui lui retourne un fd `/scheme/.../v2/...`.
+
+### 1.2 Event loop (`core/mod.rs`, 662 lignes)
+
+Architecture deux-fd :
+
+```text
+EventQueue<Source>
+  ├─ Scheme fd (clients Orbital)         → SchemeSync trait
+  └─ Input fd (depuis inputd consumer)   → ConsumerHandleEvent::Events
+```
+
+**Patterns clés** :
+
+- Utilise `event::EventQueue` (crate `redox_event`) — équivalent Redox de
+  `wl_event_loop` Wayland ou `epoll` Linux
+- Chaque source a son fd, multiplexé en édge-triggered READ
+- Les requests scheme bloquantes sont stockées dans `delayed: VecDeque` puis
+  réveillées quand un input arrive (équivalent du `wl_display_dispatch_pending`
+  Wayland)
+
+**Réutilisable pour le compositor Wayland** :
+
+- Le pattern EventQueue avec sources typées (`user_data!` macro) est exactement
+  ce qu'il faut pour le compositor Wayland
+- Le mécanisme `delayed` pour les reads bloquants est réutilisable tel quel
+
+### 1.3 Protocole `orbital:` (le scheme)
+
+Implémenté dans `core/mod.rs::OrbitalHandler::SchemeSync` et `scheme.rs` (1721 lignes).
+
+**API client** (ce qu'un client appelle pour ouvrir une fenêtre) :
+
+```text
+open("/scheme/orbital/<flags>/<x>/<y>/<w>/<h>/<title>")
+  → returns window_fd
+
+write(window_fd, "T,nouveau titre")     → titre
+write(window_fd, "S,800,600")           → resize
+write(window_fd, "P,100,200")           → position
+write(window_fd, "Y,0,0,800,600,...")   → damage rectangles
+write(window_fd, "F,t,1")               → flag transparent on
+read(window_fd, &mut events)            → pull events (clavier, souris, ...)
+mmap_prep(window_fd, ...)               → obtient un buffer mmap zero-copy
+fsync(window_fd)                        → commit (équivalent wl_surface.commit)
+```
+
+**Concepts à transposer en Wayland** :
+
+| Orbital | Équivalent Wayland |
+|---|---|
+| open() avec path verbeux | `xdg_surface` + `xdg_toplevel` configure |
+| write("S,...") resize | `xdg_toplevel.configure` + ack |
+| write("Y,...") damage | `wl_surface.damage_buffer` |
+| mmap_prep | `wl_shm_pool.create_buffer` + `wl_surface.attach` |
+| fsync | `wl_surface.commit` |
+| read events | event queue Wayland |
+
+**Limites du protocole Orbital** :
+
+- API basée sur strings dans les writes — pas type-safe, pas de versioning
+- Une seule sémantique d'extension (préfixes "A","D","F","M","P","S","T","Y")
+- Pas de négociation de capabilities côté serveur
+- Buffer mmap'é direct — moins flexible que `wl_shm_pool` mais plus rapide
+
+### 1.4 Composition (`compositor.rs`, 281 lignes)
+
+Compositor logiciel CPU pur :
+
+- `Image::roi_mut()` pour écrire dans le framebuffer
+- `Color` ARGB8888
+- Damage rectangles propagés aux clients via `Y,...`
+- Curseur SW si pas de hardware cursor disponible (cf `core/display.rs:140`
+  `set_client_capability(CursorPlaneHotspot, true)`)
+
+**Réutilisable directement** : la logique damage tracking + composition CPU
+est exactement ce qu'il faut pour la phase 6-7 du plan (`wl_shm` + composition).
+
+---
+
+## 2. Stack graphique Redox
+
+### 2.1 API `graphics-ipc` (la lib commune)
+
+`base/drivers/graphics/graphics-ipc/src/lib.rs` (127 lignes).
+
+**Découverte critique** (commentaire ligne 13-15) :
+
+> *The v2 graphics API allows creating framebuffers on the fly, using them for
+> page flipping and handles all displays using a single fd. This is basically
+> a subset of the Linux DRM interface with a couple of custom ioctls in the
+> place of the KMS ioctls that are missing.*
+
+**Conséquence** : Redox a une **API DRM compatible Linux** (subset KMS).
+La crate Rust `drm` upstream fonctionne directement sur Redox.
+
+API exposée :
+
+```rust
+V2GraphicsHandle::from_file(file)
+  ├─ resource_handles()          ← liste connectors/encoders/CRTCs
+  ├─ get_connector(handle, force_probe)
+  ├─ get_encoder(handle)
+  ├─ create_dumb_buffer(size, fourcc, bpp)
+  ├─ map_dumb_buffer(buffer)     ← mmap CPU-accessible
+  ├─ add_framebuffer(buffer, depth, bpp)
+  ├─ set_crtc(crtc, fb, position, connectors, mode)
+  ├─ dirty_framebuffer(fb, &[ClipRect])  ← damage flush
+  ├─ move_cursor / set_cursor2
+  └─ destroy_*
+```
+
+`CpuBackedBuffer` (lignes 46-127) :
+- Wrapper sur `DumbBuffer` DRM
+- Optionnel : shadow buffer host (write-combining mitigation)
+- `sync_rect()` pour copier shadow → on-screen par damage
+
+**Implications pour le portage Wayland** :
+
+1. Pas besoin de réinventer le display backend — l'API DRM existe
+2. Peut être utilisée telle quelle par un compositor Wayland Rust
+3. `CpuBackedBuffer::shadow_buf()` retourne `&mut [u8]` — exactement
+   le format SHM que Wayland attend pour la composition
+
+### 2.2 Drivers graphiques disponibles
+
+Localisation : `base/drivers/graphics/`.
+
+| Driver | Cible | Statut | Notes |
+|---|---|---|---|
+| **`vesad`** (133 + 275 lignes) | VESA framebuffer firmware (BIOS/UEFI) | Stable | Lit FRAMEBUFFER_* env, support multi-FB |
+| **`virtio-gpud`** (615 + 528 lignes) | virtio-gpu (QEMU/KVM) | Actif | C'est ce qui tourne sur ton image desktop |
+| **`ihdgd`** | Intel HD Graphics | Actif | Driver natif HW |
+| `fbcond` | Console framebuffer | — | Texte console |
+| `fbbootlogd` | Boot log framebuffer | — | Affichage early boot |
+| `console-draw` | Helpers dessin console | — | Lib commune |
+| `driver-graphics` | Couche d'abstraction commune (`GraphicsScheme`) | — | C'est elle qui exporte `display.<driver>` |
+
+Tous publient leur scheme sous forme `display.<nom>` (ex: `display.vesa`).
+
+### 2.3 Chemin d'ouverture du display
+
+```text
+Orbital
+  └─> ConsumerHandle::new_vt()                     // /scheme/input/consumer
+        └─> open_display_v2()
+              └─> fpath() pour récupérer le path complet
+                    └─> open("/scheme/.../v2/<display>")  // fd graphics-ipc v2
+                          └─> V2GraphicsHandle::from_file
+```
+
+C'est `inputd` qui détient la connaissance du driver graphique actif et
+expose un chemin standard. Orbital ne hard-code pas `vesa` ou `virtio-gpu` —
+il demande à inputd.
+
+**Implication pour le compositor Wayland** : suivre le même pattern.
+Demander à `inputd` quel display est associé au VT, ouvrir le fd retourné,
+le wrapper en `V2GraphicsHandle`. Pas de hardcode de driver.
+
+### 2.4 `vesad` — le chemin firmware framebuffer
+
+`base/drivers/graphics/vesad/src/main.rs` (133 lignes).
+
+**Bootstrap** (lignes 19-44) :
+```rust
+FRAMEBUFFER_WIDTH    // hex string, ex "780"  → 1920
+FRAMEBUFFER_HEIGHT   // ex "438"              → 1080
+FRAMEBUFFER_ADDR     // adresse physique du FB fournie par firmware
+FRAMEBUFFER_STRIDE   // bytes par ligne
+```
+
+Le bootloader (UEFI/BIOS) place ces variables avant de chainer vers le kernel.
+`vesad` mappe l'adresse physique en mémoire userspace et expose le FB via
+`GraphicsScheme`.
+
+**Fallback bootloader env** (lignes 60-84) : `vesad` lit `/scheme/sys/env`
+pour `FRAMEBUFFER1`, `FRAMEBUFFER2`, ... — support multi-écran natif au boot
+si le firmware en remonte plusieurs.
+
+**Implication** : pour la phase 4 du plan (backend display), partir de `vesad`
+comme chemin de validation initial = sûr et simple. virtio-gpud est plus
+puissant mais plus complexe (gpu commandes, virgl optionnel).
+
+---
+
+## 3. Stack input
+
+### 3.1 `inputd` — le multiplexer
+
+`base/drivers/inputd/src/{lib.rs,main.rs}` (211 + 663 lignes).
+
+**Schemes exposés** :
+
+| Path | Pour | Rôle |
+|---|---|---|
+| `/scheme/input/consumer` | Orbital, futur compositor | reçoit les events triés (orbclient::Event) |
+| `/scheme/input/consumer_bootlog` | bootlog | events early-boot |
+| `/scheme/input/producer` | drivers ps2d, usbhidd | écrit des events bruts |
+| `/scheme/input/control` | gestion VT/keymap | active VT, change keymap |
+| `/scheme/input/handle/<scheme>` | délégation à un autre scheme | déléguer un VT à un autre serveur |
+| `/scheme/input/handle_early/<scheme>` | idem mais avant init VT | bootlog, etc. |
+
+**API ConsumerHandle** :
+
+```rust
+let h = ConsumerHandle::new_vt()?;
+let display_fd = h.open_display_v2()?;     // ← ouvre le display de ce VT
+let evt_fd = h.event_handle();             // ← fd à mettre dans EventQueue
+match h.read_events(&mut events)? {
+    ConsumerHandleEvent::Events(slice) => /* traite events */,
+    ConsumerHandleEvent::Handoff => /* VT change, on perd le contrôle */,
+}
+```
+
+Le **handoff via `ESTALE`** est crucial : quand le VT switch (Ctrl-Alt-F2),
+inputd retourne ESTALE — Orbital sait qu'il doit se mettre en veille
+proprement. Le compositor Wayland devra gérer la même sémantique.
+
+### 3.2 Drivers input
+
+`base/drivers/input/` :
+- `ps2d` — clavier/souris PS/2 (legacy + KVM)
+- `usbhidd` — HID USB (clavier, souris, tablette)
+
+Tous écrivent vers `/scheme/input/producer`. inputd dédoublonne, séquence,
+attribue au VT actif, transmet au consumer.
+
+### 3.3 Format d'event
+
+`orbclient::Event` (struct C-compatible) — défini dans la crate `orbclient`.
+Types : `KeyEvent`, `MouseEvent`, `MouseRelativeEvent`, `ButtonEvent`,
+`ScrollEvent`, `FocusEvent`, `QuitEvent`, etc.
+
+**Pour Wayland** :
+- Mapping `orbclient::KeyEvent` → `wl_keyboard.key` : direct
+- Codes de touches : `orbclient` utilise des scancodes — il faudra
+  traduire vers les **keycodes XKB** que Wayland attend
+- ⚠️ **xkb keymap** : à concevoir, voir section 5
+
+---
+
+## 4. Primitives OS pour Wayland (relibc)
+
+Vérifications effectuées dans `~/Projets/Redox/relibc/src/`.
+
+### 4.1 Sockets Unix (AF_UNIX)
+
+`platform/redox/socket.rs` :
+
+- AF_UNIX **bind/connect** : implémenté via syscall direct (commentaire ligne 69 :
+  *"bind/connect with AF_UNIX were replaced with SYS_CALL"*)
+- Path encoding : `chan:<path>` (ligne 177 : `buf.starts_with(b"chan:")`)
+- SOCK_STREAM ✅ et SOCK_DGRAM ✅ supportés
+- Compatible avec l'usage Wayland (`$XDG_RUNTIME_DIR/wayland-N`)
+
+### 4.2 fd passing — `sendmsg` / `recvmsg` avec SCM_RIGHTS
+
+**🟢 Critique** : `platform/redox/socket.rs` :
+- Lignes 272 et 447 : `(SOL_SOCKET, SCM_RIGHTS)` traité dans cmsghdr
+- Lignes 835 et 924 : `recvmsg` / `sendmsg` implémentés en interne
+
+C'est **le pré-requis n°1** du plan (risque majeur 1) — il est rempli.
+Il faut quand même écrire des tests dédiés en phase 2 pour valider :
+- Passage simple de fd entre deux processus
+- Multiple fds dans un même cmsg
+- Passage d'un fd shm + lecture côté receveur
+
+### 4.3 Mémoire partagée — `shm_open` + mmap
+
+**`shm_open`** : `header/sys_mman/mod.rs:185` :
+```rust
+pub unsafe extern "C" fn shm_open(name, oflag, mode) -> c_int {
+    // traduit "/foo" → "/scheme/shm/foo" puis open() classique
+}
+```
+
+Mécanisme : un scheme dédié `/scheme/shm/` sert de namespace
+(équivalent `/dev/shm` Linux mais via le scheme system).
+
+**`mmap MAP_SHARED`** : présent (`header/sys_mman/mod.rs`). Tous les buffers
+DRM dumb sont déjà mappés ainsi par `graphics-ipc`.
+
+### 4.4 ⚠️ `memfd_create`
+
+- Numéro syscall défini : `__NR_memfd_create = 319` (x86_64)
+- **Implémentation** : pas vue dans la sortie grep — probablement absente
+  ou stub
+- **Impact pour Wayland** : libwayland-client moderne préfère `memfd_create`
+  pour les shm pools (pas de path needed). Fallback : `shm_open` avec nom
+  unique → fonctionne, juste un peu plus verbeux
+
+À traiter en phase 2 :
+- Soit implémenter `memfd_create` au-dessus de `shm_open + shm_unlink`
+- Soit ajouter une couche `cfg(target_os = "redox")` côté `wayland-client`
+  qui force le path shm_open
+
+### 4.5 Event loop / poll
+
+- `header/poll/mod.rs` : `poll()` POSIX disponible
+- `header/sys_select/mod.rs` : `select` POSIX
+- `header/sys_epoll/mod.rs` : `epoll_*` (probablement émulé sur Redox via
+  l'EventQueue native — à vérifier)
+- **Native Redox** : `redox_event::EventQueue` — utilisé par Orbital, plus
+  idiomatique. Pour le compositor Rust pur, autant l'utiliser directement
+  plutôt que de passer par poll() POSIX.
+
+---
+
+## 5. Manques identifiés (à traiter dans le plan)
+
+### 5.1 Pas de keymap XKB sur Redox
+
+Wayland exige que le serveur envoie un keymap XKB au client (`wl_keyboard.keymap`
+event, format `XKB_V1`). Or :
+- Redox utilise des scancodes orbclient
+- Pas de `xkbcommon` packagé sur Redox (à confirmer en cherchant la recette)
+- Pas de fichiers de keymap XKB système
+
+**À traiter en phase 5 (backend input)** :
+- Option A : porter `libxkbcommon` (C, ~10k loc)
+- Option B : utiliser la crate Rust `xkb` (wrapper xkbcommon, dépend du C)
+- Option C : implémenter un sous-ensemble XKB en Rust (plus long mais
+  cohérent avec l'esprit du projet)
+
+Recommandation : **Option C** mais avec scope minimal (US layout + variantes
+basiques) au début. La crate `xkeysym` peut servir de base.
+
+### 5.2 Pas d'AT-SPI / dbus pour l'accessibilité
+
+- Phase 11 du plan vise navigation clavier + métadata d'accessibilité
+- Sur Linux, AT-SPI transporte ces métadata via dbus
+- Dbus existe sur Redox mais portage limité ; AT-SPI n'est pas porté
+- À concevoir : protocole Redox simple d'accessibilité, ou wayland-protocols
+  custom (text-input-v3 comme point de départ)
+
+### 5.3 GPU userspace driver manquant
+
+- vesad et virtio-gpud existent mais pas de DRM driver "GPU complet" hors virtio
+- Mesa3D Redox = LLVMpipe seulement (CPU)
+- Phase 12 du plan = GPU expérimental — restera CPU pour le MVP
+- À documenter : aucune accélération hardware n'est garantie pour les phases 0-11
+
+### 5.4 Pas de session manager / VT API stable
+
+- Sur Linux : `logind` / `seatd` gèrent les VT et l'accès aux devices
+- Sur Redox : `inputd` joue un rôle similaire mais pas équivalent
+- Pour Smithay (phase 13), il faudra un backend session Redox basé sur inputd
+
+---
+
+## 6. Ce qui est réutilisable directement
+
+| Composant Redox actuel | Usage dans le compositor Wayland |
+|---|---|
+| `redox_event::EventQueue` | Boucle principale du compositor |
+| `redox-scheme::SchemeSync` | Si on choisit aussi de publier un scheme `wayland:` |
+| `graphics-ipc::V2GraphicsHandle` | Backend display (phase 4) — direct |
+| `graphics-ipc::CpuBackedBuffer` | wl_shm composition (phase 6) — direct |
+| `inputd::ConsumerHandle` | Backend input (phase 5) — direct |
+| `orbital/src/compositor.rs` damage tracking | Référence pour notre damage logic (phase 6-7) |
+| `orbital/src/scheme.rs` focus + raccourcis | Référence pour focus management (phase 7) |
+| `redox-log` | Logging |
+| Crate `drm` upstream | Si on veut adresser DRM directement |
+
+---
+
+## 7. Décisions recommandées pour la suite
+
+### Phase 2 (primitives OS) — peut être réduite
+
+Plutôt que d'auditer toutes les primitives, **se limiter à des tests dédiés** :
+
+1. Test fd passing : 2 processus, l'un crée un memfd-like, l'autre le mappe
+2. Test Unix socket SOCK_STREAM avec messages Wayland-shaped (header binaire)
+3. Test event loop multi-fd avec signaux POSIX
+4. Test concurrent shm_open/mmap depuis plusieurs processus
+
+Si les 4 tests passent, on a la garantie que `wayland-rs` peut tourner.
+Estimation : **1 mois à 2h/jour** au lieu des 6 mois initialement budgétés.
+
+### Phase 3 (port wayland-rs) — à découper
+
+`wayland-rs` upstream a peu de deps OS-specifiques dans son crate `wayland-backend`.
+Ordre suggéré :
+1. `wayland-scanner` (génération code XML → Rust) : pure logic, devrait marcher tel quel
+2. `wayland-backend` : couche socket — vérifier le `cfg(unix)` vs ajout d'un
+   `cfg(target_os = "redox")`
+3. `wayland-server` : haut niveau — devrait fonctionner si backend OK
+4. `wayland-client` : symétrique
+
+### Phase 4 (display backend) — voie rapide possible
+
+`V2GraphicsHandle` est si proche de l'API DRM Linux qu'on peut s'inspirer
+directement de `core/display.rs` d'Orbital pour le RedoxOutput.
+
+**Estimation : 2 mois à 2h/jour** (au lieu des 6 mois si on partait de zéro).
+
+---
+
+## 8. Repos clonés localement pour la suite
+
+```text
+~/Projets/Redox/
+  ├── orbital/              ← référence compositor (gitlab.redox-os.org/redox-os/orbital)
+  ├── base/                 ← drivers + graphics-ipc + inputd (gitlab.redox-os.org/redox-os/base)
+  ├── relibc/               ← libc Redox, primitives POSIX (--depth 1)
+  ├── redox-src/            ← repo umbrella, ~/Projets/Redox/redox-src/build/x86_64/desktop/harddrive.img
+  └── docs/existing-redox-gui.md  ← ce document
+```
+
+Sources additionnelles à cloner si on creuse plus :
+- `redox-os/wayland-rs-redox-fork` *(à créer le moment venu)*
+- `redox-os/drivers` *(déjà inclus dans base/drivers/)*
+- `Smithay/smithay` *(plus tard, phase 13)*
+
+---
+
+## 9. Documents à produire ensuite
+
+Selon le plan directeur (section "Documents A Produire Ensuite") :
+
+| Document | Quand | Contenu |
+|---|---|---|
+| `redox-wayland-primitives.md` | Phase 2, après tests | Résultats des 4 tests dédiés + conclusions |
+| `compositor-architecture.md` | Phase 3-4 | Crates, traits, flux de données |
+| `display-backend-redox.md` | Phase 4 | Détails RedoxOutput + dirty_framebuffer flow |
+| `input-backend-redox.md` | Phase 5 | Mapping orbclient → Wayland + XKB strategy |
+| `software-rendering-and-gpu-roadmap.md` | Phase 4 + 12 | CPU paths + GPU horizon |
+| `accessibility-roadmap.md` | Phase 11 | Décisions sans AT-SPI |
+| `orbital-migration.md` | Phase 8-9 | Comment porter winit/softbuffer/clients |
+| `cosmic-smithay-roadmap.md` | Phase 13 | Quand y aller, dépendances bloquantes |
+| `x11-compat-rust-roadmap.md` | Phase 14 | Projet séparé |
+
+---
+
+*Fin de l'audit phase 1.*
--- a/docs/redox-wayland-primitives.md
+++ b/docs/redox-wayland-primitives.md
@ -0,0 +1,296 @@
+# Phase 2 — Primitives Redox pour Wayland : résultats des tests
+
+> Document produit le 2026-05-08 dans le cadre du plan directeur
+> `REDOX_COSMIC_XWAYLAND_RS_PLAN.md`.
+>
+> **Périmètre** : valider par tests dédiés que les 4 primitives système
+> indispensables à Wayland (Unix sockets, fd passing SCM_RIGHTS, shm_open+mmap,
+> poll multi-fd) fonctionnent sur Redox. Décision conditionnée par l'audit
+> phase 1 (`existing-redox-gui.md`) qui a montré que ces primitives
+> existent en théorie dans relibc.
+
+## Verdict global
+
+**✅ Wayland est techniquement viable sur Redox.**
+
+Les 4 primitives critiques fonctionnent dans le scénario réel Wayland
+(client + compositor en deux processus séparés). **Aucun blocage** identifié
+pour démarrer la phase 3 (port `wayland-rs`).
+
+| Test | Scope | Résultat |
+|---|---|---|
+| Test 1 — Unix socket SOCK_STREAM | mono-process via socketpair | ✅ PASS |
+| Test 2 — SCM_RIGHTS | mono-process | ⚠️ Artefact (numéro fd réutilisé) |
+| Test 2b — SCM_RIGHTS | multi-process (fork) | ✅ PASS |
+| Test 3 — shm_open + mmap MAP_SHARED | mono-process | ✅ PASS |
+| Test 4 — poll() multi-fd | mono-process | ✅ PASS |
+
+## Méthodologie
+
+Workspace : `~/Projets/Redox/redox-wayland-tests/`
+Toolchain : `nightly-2026-05-07` + target `x86_64-unknown-redox`
+Exécution : `redoxer run --release` (mini-VM Redox sous QEMU/KVM)
+
+Chaque test est un binaire Rust autonome utilisant uniquement la crate
+`libc 0.2` (pour rester proche du métal et éviter d'introduire des biais
+d'abstraction).
+
+---
+
+## Test 1 — Unix socket SOCK_STREAM avec format Wayland
+
+### Objectif
+Valider qu'un message Wayland-shaped (header `object_id` + `(size << 16 | opcode)`,
+payload aligné sur 4 bytes) traverse une socketpair AF_UNIX/SOCK_STREAM sans
+corruption.
+
+### Setup
+- `socketpair(AF_UNIX, SOCK_STREAM, 0, fds)`
+- Construire un message : 8 bytes header + 32 bytes payload aligné = 40 bytes
+- write_all côté A, read_exact header puis payload côté B
+
+### Résultat
+```text
+[test-01] sent 40 bytes (header 8 + payload 32 aligned to 32)
+[test-01] PASS: roundtrip OK, 40 bytes recv, oid=0x1 op=0xa
+```
+
+**Conclusion** : `wayland-rs/wayland-backend` peut utiliser des Unix sockets
+Redox sans modification au niveau wire format.
+
+---
+
+## Test 2 — SCM_RIGHTS mono-process
+
+### Objectif
+Valider l'API SCM_RIGHTS via `sendmsg`/`recvmsg`. Vérifier que le fd
+reçu donne accès au même fichier que le fd envoyé.
+
+### Observation initiale (FAIL)
+En mono-process :
+- `sendmsg(SCM_RIGHTS, [fd=5])` → succès
+- `recvmsg(...)` → control de 24 bytes, fd reçu = **5** (identique)
+- `dup(tmp_fd) → 8`, send 8, recv → **8**
+
+Conclusion : le kernel Redox **réutilise le numéro fd** plutôt que de créer
+un nouveau slot dans la fd table. Quand on `close(tmp_fd)` puis `close(dup)`,
+le fd reçu devient EBADF.
+
+### Interprétation
+Ce comportement est **un artefact mono-process** :
+- Mono-process, le sender et le receiver partagent la même fd table
+- Le kernel optimise en évitant de créer un slot redondant
+- Ce n'est **pas** un comportement représentatif du cas Wayland réel
+  (client et compositor sont toujours en deux processus séparés)
+
+### Code relibc concerné
+`relibc/src/platform/redox/socket.rs:289` (send) et `:467` (recv) :
+```rust
+redox_rt::sys::sys_call_wo(socket, &fds_slice, CallFlags::FD, &[])?
+redox_rt::sys::sys_call_ro(socket, fds_bytes, call_flags, &[])?
+```
+Le syscall Redox `sys_call_wo/ro` avec `CallFlags::FD` est l'implémentation
+réelle. Sa sémantique multi-process est validée par le test 2b ci-dessous.
+
+---
+
+## Test 2b — SCM_RIGHTS multi-process (le vrai test Wayland)
+
+### Objectif
+Valider que SCM_RIGHTS transfère effectivement un fd d'un processus parent
+vers un processus enfant créé par `fork()`. C'est le scénario Wayland exact.
+
+### Setup
+1. Parent : `open("/tmp/...")` avec un marker connu
+2. Parent : `socketpair(AF_UNIX, SOCK_STREAM)`
+3. Parent : `fork()`
+4. Parent : `sendmsg(SCM_RIGHTS, [tmp_fd])`, drop tmp_fd
+5. Child : `recvmsg`, lit via le fd reçu, vérifie le marker, `_exit(0/N)`
+6. Parent : `waitpid`, recupère exit code
+
+### Résultat
+```text
+[test-02b PARENT] tmp fd=5, sockets 6/7
+[test-02b PARENT] forked child pid=36, sending fd
+[test-02b CHILD pid=36] recvmsg on sock 7
+[test-02b CHILD] received fd=5
+[test-02b CHILD] marker matches, exit 0
+[test-02b PARENT] child reaped: exited=true code=0
+[test-02b] PASS: fd passed across fork() correctly
+```
+
+**Conclusion critique** : Le child a reçu fd=5 (numéro réutilisé localement,
+ce qui est normal puisque sa fd table est indépendante du parent), et la
+**lecture via ce fd a retourné le marker écrit par le parent**.
+
+C'est la sémantique POSIX correcte pour SCM_RIGHTS et c'est **exactement
+ce que Wayland exige** : un client envoie un fd shm au compositor, le
+compositor reçoit dans sa propre fd table un descripteur fonctionnel.
+
+### Implication pour le projet
+
+Le risque majeur n°1 du plan directeur (cf section "Risques Majeurs") est levé :
+
+> *Wayland depend fortement de sockets, fd passing, shm et mmap.
+> Mitigation : traiter cette phase avant tout port COSMIC ;
+> maintenir des tests bas niveau.*
+
+Pré-requis fonctionnel : ✅ confirmé.
+Tests bas niveau à maintenir : ✅ ce document + le code source
+`redox-wayland-tests/`.
+
+---
+
+## Test 3 — shm_open + mmap MAP_SHARED
+
+### Objectif
+Valider que `shm_open` (qui sur Redox est traduit en
+`open("/scheme/shm/<name>")` par relibc) supporte le pattern Wayland :
+créer une zone partagée nommée, écrire, refermer, rouvrir, relire.
+
+### Setup
+1. `shm_open("/redox-wl-test-03", O_RDWR|O_CREAT, 0600)`
+2. `ftruncate(fd, 4096)`
+3. `mmap(NULL, 4096, RW, MAP_SHARED, fd, 0)`
+4. Écrire 1024 u32 = pattern `0xDEADBEEF + index`
+5. `munmap` + `close`
+6. `shm_open("/redox-wl-test-03", O_RDWR)` — réouverture
+7. `mmap` à nouveau
+8. Vérifier le pattern bit à bit
+9. `shm_unlink`
+
+### Résultat
+```text
+[test-03] phase1: shm_open created, fd=5
+[test-03] phase1: mmap at 0x15000
+[test-03] phase1: wrote 1024 u32 pixels
+[test-03] phase2: shm_open reopened, fd=5
+[test-03] phase2: mmap at 0x15000
+[test-03] phase2: pattern verified across close/reopen
+[test-03] cleanup: shm_unlink OK
+[test-03] PASS: shm_open/mmap/persistence/unlink all work
+```
+
+**Notes** :
+- Le pattern est intégralement préservé entre close/reopen → la zone
+  partagée vit indépendamment des fds qui la mappent (sémantique POSIX
+  correcte)
+- `shm_unlink` retire effectivement la zone
+- `mmap` retourne la même adresse (0x15000) sur les deux mappings — pas
+  une garantie POSIX mais cohérent
+
+**Conclusion** : Wayland peut utiliser `wl_shm_pool` via `shm_open`+`mmap`
+sans adaptation. Pour `memfd_create` (préféré par libwayland-client moderne),
+voir section "Manque restant" plus bas.
+
+---
+
+## Test 4 — poll() multi-fd
+
+### Objectif
+Valider le multiplexage `poll()` qui sera la base de l'event loop du
+compositor (équivalent `wl_event_loop`).
+
+### Setup
+Trois pipes (`ra/wa`, `rb/wb`, `rc/wc`). On `poll()` les trois read ends
+avec POLLIN. Trois sous-tests :
+- A : timeout 50ms sans data → doit retourner 0
+- B : `write(wb, "X")` → poll doit ne signaler que `rb`
+- C : `close(wa)` → poll doit signaler ra (POLLHUP/POLLIN)
+
+### Résultat
+```text
+[test-04] A: timeout 50ms with no data → poll returned 0 OK
+[test-04] B: poll detected only rb (index 1) ready, as expected
+[test-04] B: read 1 byte 'X' from rb OK
+[test-04] C: closing wa caused POLLHUP/POLLIN on ra (revents=0x1)
+[test-04] PASS: poll() multiplexes correctly across fds and detects HUP
+```
+
+**Conclusion** : multiplexage fiable, comportement POSIX standard.
+On peut soit utiliser `poll()` directement, soit s'appuyer sur
+`redox_event::EventQueue` (utilisé par Orbital) qui wrappe le scheme
+event Redox de manière plus idiomatique.
+
+---
+
+## Manques restants à traiter
+
+### `memfd_create` non implémenté
+
+L'audit phase 1 avait noté :
+> Numéro syscall défini (`__NR_memfd_create = 319`) mais pas vu d'impl
+> dans relibc.
+
+Confirmé dans ce travail. **Impact** : libwayland-client moderne préfère
+`memfd_create` aux `shm_open` (pas de path nécessaire, anti-leak en cas
+de crash client).
+
+**Solutions possibles, par ordre de simplicité** :
+
+1. **Wrapper côté wayland-rs Redox** : ajouter un `cfg(target_os = "redox")`
+   qui force le path `shm_open` avec un nom unique (ex: `pid + counter`)
+2. **Implémenter `memfd_create` dans relibc Redox** au-dessus de
+   `shm_open` + `shm_unlink` immédiat (pour rendre la zone anonyme)
+3. **Ajouter un syscall Redox `memfd_create` natif** (le plus propre,
+   le plus long)
+
+Recommandation pour la phase 3 : option 1 dans un premier temps. Si on
+upstream chez Redox plus tard, option 2.
+
+### Numéros de fd réutilisés en mono-process
+
+Constat du test 2 : pas vraiment un bug, mais à documenter dans
+`compositor-architecture.md` pour qu'on n'écrive pas de tests qui
+reposent sur des numéros distincts.
+
+### `pipe()` ne semble pas exposer pipes nommés FIFO
+
+Non testé ici. Pas critique pour Wayland (on utilise socket pairs).
+À noter si on veut un jour porter du code Linux qui utilise des FIFO.
+
+---
+
+## Conclusions pour la suite du plan
+
+### Phase 2 → ✅ TERMINÉE
+
+La phase 2 du plan visait :
+> *Valider les mécanismes nécessaires au protocole Wayland.*
+
+Mission accomplie en **une session** au lieu des 6 mois budgétés. C'est
+possible parce que l'audit phase 1 avait déjà localisé les implémentations
+relibc — les tests n'avaient qu'à confirmer le comportement.
+
+### Implications pour le calendrier annuel
+
+Le plan directeur prévoyait année 1 = "audit + primitives". On a fait
+les deux en deux sessions de 2h. **Année 1 peut donc démarrer la phase 3
+dès maintenant**, avec une marge confortable.
+
+### Premier ticket de phase 3
+
+> Cloner `wayland-rs` upstream, ajouter target `x86_64-unknown-redox`,
+> tenter `cargo build` sur les crates `wayland-scanner`, `wayland-backend`,
+> `wayland-server`, `wayland-client`. Documenter les `cfg(unix)` qui ont
+> besoin d'un `cfg(target_os = "redox")` distinct.
+
+---
+
+## Code source des tests
+
+```text
+~/Projets/Redox/redox-wayland-tests/
+├── test-01-unix-socket/         (40 bytes Wayland-shaped roundtrip)
+├── test-02-fd-passing/          (mono-process, expose l'artefact)
+├── test-02b-fd-passing-fork/    (multi-process via fork — la vraie validation)
+├── test-03-shm-open/            (shm_open + mmap + persistance)
+└── test-04-poll-multifd/        (poll multiplexing + POLLHUP)
+```
+
+À conserver en CI quand le repo `redox-wayland-compositor` sera créé
+(phase 0 du plan, à venir).
+
+---
+
+*Fin du document de phase 2.*