# Plan global 3-5 ans : compositor Wayland Rust minimal pour remplacer Orbital

## Document A Etudier

Ce fichier est le document global de travail a etudier en priorite :

```text
REDOX_COSMIC_XWAYLAND_RS_PLAN.md
```

Il doit servir de plan directeur pour avancer vers une GUI Redox moderne :

- d'abord un compositor Wayland minimal en Rust qui remplace Orbital ;
- ensuite un backend plus robuste pour Smithay/COSMIC ;
- plus tard une compatibilite X11 via un serveur X11 Rust compatible Xwayland.

## Vision

Construire progressivement un compositor Wayland minimal, natif Redox, ecrit principalement en Rust, qui remplace Orbital comme serveur graphique de base.

La cible initiale n'est pas COSMIC complet. La cible initiale est plus fondamentale :

```text
Applications Wayland simples
        |
        v
Compositor Wayland minimal Rust
        |
        v
Backend Redox : inputd + graphics-ipc + schemes
        |
        v
vesad / framebuffer firmware au debut
GPU userspace Redox plus tard
```

La cible long terme est :

```text
Applications Wayland natives / COSMIC
Applications X11 via serveur X11 Rust compatible Xwayland
        |
        v
Compositor Wayland Redox
        |
        v
Redox natif, sans Orbital
```

Pour etre complete, la GUI Redox doit couvrir trois manques structurels :

- acceleration materielle via GPU ;
- support Wayland standard, ou protocole equivalent clairement documente ;
- accessibilite : lecteurs d'ecran, navigation clavier avancee, focus visible, raccourcis, contraste, zoom et APIs d'assistance.

## Constat Sur L'Existant Redox

### VESA / `vesad`

`vesad` n'est pas vraiment un driver GPU. Il ecrit dans un framebuffer fourni par le firmware via UEFI ou BIOS.

Implication pour le plan :

- le premier compositor doit accepter un rendu framebuffer simple ;
- le rendu CPU reste obligatoire ;
- il ne faut pas attendre les drivers GPU pour commencer ;
- le backend display doit rester compatible avec un framebuffer firmware.

### GPUs

Redox n'a pas encore de pile GPU complete comparable a Linux/BSD.

Sur Linux/BSD, la communication GPU passe par DRM dans le kernel, exposee par `libdrm`, puis utilisee par Mesa3D pour OpenGL/Vulkan.

Dans Redox, un "driver DRM" doit plutot etre un daemon userspace qui parle au materiel via schemes et appels systeme.

Implication pour le plan :

- l'acceleration GPU est un objectif de maturite, pas un pre-requis du MVP ;
- le compositor doit separer clairement :
  - protocole Wayland ;
  - gestion surfaces ;
  - rendu ;
  - presentation display ;
  - allocation buffers ;
- il faudra plus tard un backend Redox dans Mesa3D pour utiliser ces drivers userspace.

### Software Rendering

LLVMpipe fonctionne deja comme emulation OpenGL CPU.

Implication pour le plan :

- le rendu logiciel est le chemin initial naturel ;
- les clients OpenGL peuvent passer par LLVMpipe/OSMesa quand c'est possible ;
- l'objectif court terme n'est pas Vulkan/OpenGL accelere, mais des surfaces `wl_shm` fiables ;
- OSMesa et LLVMpipe doivent etre conserves comme ponts de compatibilite pendant la transition.

### Orbital

Orbital fournit actuellement :

- display server ;
- window manager ;
- compositor ;
- launcher ;
- file manager ;
- text editor ;
- calculator ;
- terminal emulator ;
- raccourcis Super affiches en overlay ;
- protocole client via `orbclient`.

Orbital est plus simple que X11/Wayland. Il est moins avance, mais suffisant pour porter beaucoup de programmes Linux/BSD via des bibliotheques adaptees.

Bibliotheques deja utiles sur Orbital :

- `winit` ;
- `softbuffer` ;
- Slint via `winit`/`softbuffer` ;
- Iced via `winit`/`softbuffer` ;
- egui via `winit` ou SDL2 ;
- SDL1.2 ;
- SDL2 ;
- Mesa3D OSMesa.

Securite deja interessante :

- un programme GUI Orbital ne peut pas lire les events input ou le framebuffer des autres fenetres ;
- ce modele est plus proche de Wayland que de X11.

Implication pour le plan :

- Orbital ne doit pas etre jete brutalement ;
- il sert de reference et de fallback pendant plusieurs annees ;
- les bibliotheques deja portees vers Orbital sont des candidats de migration vers Wayland Redox ;
- la securite type Wayland doit etre preservee ;
- `orbclient` ne doit pas devenir la nouvelle API long terme.

## Strategie Corrigee

### Mauvais Chemin

Ne pas commencer par :

- porter COSMIC complet ;
- reecrire Xwayland ;
- attendre les drivers GPU ;
- concevoir un protocole graphique maison concurrent de Wayland ;
- remplacer tout Orbital d'un coup.

### Bon Chemin

Commencer par :

1. Valider les primitives Redox necessaires a Wayland.
2. Faire fonctionner `wayland-rs` sur Redox.
3. Ecrire un compositor Wayland minimal.
4. Reutiliser les idees d'Orbital pour display, input, damage, session et securite.
5. Rendre ce compositor capable de remplacer Orbital experimentalement.
6. Porter progressivement les bibliotheques et clients existants.
7. Preparer ensuite Smithay/COSMIC.
8. Traiter le serveur X11 Rust compatible Xwayland comme un projet long terme separe.

## Objectif Principal

Remplacer Orbital par un compositor Wayland natif Redox capable de :

- prendre le controle de l'ecran sans Orbital ;
- afficher une ou plusieurs surfaces Wayland ;
- recevoir l'input via Redox ;
- gerer focus, clavier, souris, resize et damage ;
- fournir un protocole Wayland suffisamment standard pour porter des clients simples ;
- garder un rendu CPU fiable via framebuffer/LLVMpipe/OSMesa ;
- preparer une future acceleration GPU sans l'imposer au MVP ;
- preparer une couche d'accessibilite ;
- servir de base future a COSMIC.

## Non-Objectifs Initiaux

Ne pas viser dans le MVP :

- COSMIC complet ;
- Xwayland ou equivalent X11 ;
- acceleration GPU obligatoire ;
- Mesa3D GPU complet ;
- Vulkan/OpenGL accelere ;
- multi-GPU ;
- HDR, color management avance, VRR ;
- portails desktop complets ;
- PipeWire/screencast ;
- decorations complexes ;
- compatibilite totale avec GTK/Qt/Electron ;
- lecteur d'ecran complet ;
- accessibilite desktop complete.

Ces objectifs restent importants, mais ils viennent apres le compositor Wayland minimal.

## Architecture Initiale

```text
redox-wayland-compositor
    |
    +-- redox_display
    |       +-- graphics-ipc
    |       +-- vesad/framebuffer firmware
    |       +-- framebuffer CPU
    |       +-- damage flush
    |       +-- future DRM userspace driver daemon
    |
    +-- redox_input
    |       +-- inputd
    |       +-- keyboard
    |       +-- pointer
    |       +-- buttons
    |       +-- relative motion
    |
    +-- wayland_core
    |       +-- wl_display
    |       +-- wl_registry
    |       +-- wl_compositor
    |       +-- wl_surface
    |       +-- wl_shm
    |       +-- wl_output
    |       +-- wl_seat
    |       +-- xdg_shell plus tard
    |
    +-- compositor_core
    |       +-- surfaces
    |       +-- windows
    |       +-- focus
    |       +-- stacking
    |       +-- damage
    |       +-- frame callbacks
    |
    +-- renderer
    |       +-- CPU blit
    |       +-- alpha blend
    |       +-- cursor composition
    |       +-- LLVMpipe/OSMesa path for clients
    |       +-- GPU backend later
    |
    +-- accessibility
            +-- keyboard navigation
            +-- visible focus
            +-- metadata windows/surfaces
            +-- high contrast
            +-- zoom later
```

## Relation Avec Orbital

Orbital doit etre remplace progressivement, pas ignore.

### A Reutiliser Comme Reference

- [main.rs](main.rs) : demarrage via `VT`, lancement d'une commande de login/session.
- [core/display.rs](core/display.rs) : ouverture display, framebuffer CPU, cursor plane, `dirty_framebuffer`.
- [core/mod.rs](core/mod.rs) : event loop Redox, `inputd`, scheme.
- [compositor.rs](compositor.rs) : damage tracking, curseur, composition logicielle.
- [scheme.rs](scheme.rs) : focus, input routing, fenetres, raccourcis.
- [window.rs](window.rs) : modele de fenetre, buffers, flags, events.

### A Conserver Pendant Transition

- fallback Orbital dans les images de test ;
- applications Orbital essentielles ;
- bibliotheques deja portees : `winit`, `softbuffer`, Slint, Iced, egui, SDL, OSMesa ;
- experience utilisateur de base : terminal, launcher, raccourcis.

### A Remplacer

- protocole `orbital:` ;
- API client `orbclient` comme interface graphique principale ;
- mapping direct des fenetres via `mmap_prep` Orbital ;
- semantics de fenetres propres a Orbital ;
- hypothese qu'une seule implementation serveur suffit pour tous les clients.

## Roadmap Globale

| Phase | Nom | Objectif |
| --- | --- | --- |
| 0 | Cadrage | depot, build, documentation, perimetre |
| 1 | Audit existant Redox | vesad, graphics-ipc, inputd, Orbital, LLVMpipe |
| 2 | Primitives Redox | sockets, fd passing, shm, mmap, poll |
| 3 | Wayland-rs minimal | serveur Wayland + client test |
| 4 | Display backend | affichage Redox sans Orbital |
| 5 | Input backend | clavier/souris via inputd |
| 6 | Surfaces shm | affichage de surfaces Wayland |
| 7 | Compositor utilisable | focus, stacking, damage, cursor |
| 8 | Remplacement Orbital experimental | boot Redox vers compositor Wayland |
| 9 | Migration bibliotheques | winit, softbuffer, SDL, clients simples |
| 10 | Stabilisation desktop | xdg-shell, clipboard, output, tests |
| 11 | Accessibilite initiale | navigation clavier, focus visible, metadata UI |
| 12 | Acceleration GPU | abstraction renderer, backend GPU experimental |
| 13 | Pont vers Smithay/COSMIC | preparation port COSMIC |
| 14 | Compat X11 Rust | projet separe apres socle stable |

## Phase 0 : Cadrage

### Objectif

Creer un cadre de travail clair.

### Taches

- Creer un depot ou sous-depot `redox-wayland-compositor`.
- Definir les crates :
  - `redox-wl-compositor`
  - `redox-wl-display`
  - `redox-wl-input`
  - `redox-wl-render`
  - `redox-wl-accessibility`
  - `redox-wl-protocol-tests`
- Definir les clients de test.
- Definir la strategie de fallback Orbital.
- Definir la matrice de compatibilite.

### Validation

Un binaire minimal compile et s'integre dans l'environnement de build Redox.

## Phase 1 : Audit De L'Existant Redox

### Objectif

Comprendre exactement ce qui existe avant d'ecrire le nouveau compositor.

### Taches

- Lire le code Orbital actuel.
- Lire le fonctionnement de `graphics-ipc`.
- Lire le fonctionnement de `inputd`.
- Identifier le chemin exact vers `vesad`.
- Identifier comment LLVMpipe/OSMesa sont integres.
- Lister les bibliotheques deja fonctionnelles sur Orbital.
- Lister les APIs Redox disponibles pour sockets, fd passing, shm, mmap.
- Documenter les differences avec Linux.

### Livrables

- `docs/existing-redox-gui.md`
- schema de la stack actuelle ;
- liste des composants reutilisables ;
- liste des blocages.

### Validation

Le projet sait expliquer comment Orbital affiche une fenetre aujourd'hui et comment le nouveau compositor remplacera chaque partie.

## Phase 2 : Primitives Systeme Redox Pour Wayland

### Objectif

Valider les mecanismes necessaires au protocole Wayland.

### Primitives critiques

- Unix domain sockets ;
- passage de file descriptors ;
- memoire partagee ;
- `mmap` ;
- `poll` ou event loop equivalente ;
- timers ;
- gestion des processus clients.

### Taches

- Ecrire tests serveur/client socket.
- Ecrire tests fd passing.
- Ecrire tests shm/mmap.
- Ecrire tests event loop multi-fd.
- Corriger ou completer Redox/relibc si necessaire.

### Validation

Un serveur peut recevoir un client, lui envoyer une zone memoire partagee, detecter des changements et traiter plusieurs fd dans une boucle d'evenements.

## Phase 3 : Wayland-rs Minimal Sur Redox

### Objectif

Faire tourner un serveur Wayland minimal et un client Wayland minimal.

### Protocoles prioritaires

- `wl_display`
- `wl_registry`
- `wl_compositor`
- `wl_surface`
- `wl_shm`
- `wl_buffer`
- `wl_output`
- `wl_seat`
- `wl_keyboard`
- `wl_pointer`

### Taches

- Porter ou adapter `wayland-backend`.
- Porter ou adapter `wayland-server`.
- Porter ou adapter `wayland-client`.
- Generer les bindings necessaires.
- Ecrire un client Wayland test.

### Validation

Un client Wayland simple peut creer une surface shm et envoyer un commit au serveur.

## Phase 4 : Backend Display Redox

### Objectif

Ouvrir l'ecran Redox et dessiner sans Orbital.

### Taches

- Creer `RedoxOutput`.
- Ouvrir le display via les primitives Redox existantes.
- Supporter le framebuffer CPU fourni par le chemin firmware/vesad.
- Implementer clear screen.
- Implementer draw rectangle.
- Implementer flush damage.
- Implementer resize si possible.
- Ajouter curseur logiciel initial.

### Validation

Un binaire prend l'ecran sans Orbital et affiche une scene simple.

## Phase 5 : Backend Input Redox

### Objectif

Recevoir clavier, souris et boutons via `inputd`.

### Taches

- Ouvrir le consumer input Redox.
- Lire clavier.
- Lire souris absolue.
- Lire souris relative.
- Lire boutons et scroll.
- Normaliser les coordonnees.
- Router l'input vers une surface.

### Validation

Le compositor recoit l'input et peut deplacer un curseur ou focaliser une surface.

## Phase 6 : Surfaces Wayland SHM

### Objectif

Afficher de vraies surfaces Wayland basees sur `wl_shm`.

### Formats initiaux

- `XRGB8888`
- `ARGB8888`

### Taches

- Recevoir buffers `wl_shm`.
- Gerer `attach`.
- Gerer `damage`.
- Gerer `commit`.
- Composer les surfaces dans le framebuffer Redox.
- Envoyer `frame callbacks`.

### Validation

Une surface Wayland shm s'affiche et se met a jour correctement.

## Phase 7 : Compositor Utilisable Minimal

### Objectif

Passer d'une demo a un mini desktop experimental.

### Fonctionnalites

- stacking ;
- focus clavier ;
- focus pointer ;
- move de fenetres ;
- resize simple ;
- curseur ;
- damage tracking ;
- frame scheduling ;
- fermeture client ;
- raccourcis globaux.

### Validation

Deux clients Wayland simples s'affichent, recoivent input, peuvent etre focalises et deplaces.

## Phase 8 : Remplacement Experimental d'Orbital

### Objectif

Demarrer Redox directement sur le compositor Wayland minimal.

### Taches

- Integrer le compositor dans le boot/session.
- Definir `WAYLAND_DISPLAY`.
- Lancer un client Wayland test au demarrage.
- Garder une option fallback Orbital.
- Documenter la procedure de retour arriere.

### Validation

Orbital n'est plus necessaire pour afficher le premier client graphique de test.

## Phase 9 : Migration Des Bibliotheques Existantes

### Objectif

Utiliser la force de l'existant Redox/Orbital pour alimenter le nouveau monde Wayland.

### Taches

- Auditer `winit` Redox/Orbital.
- Ajouter ou adapter un backend Wayland Redox pour `winit`.
- Auditer `softbuffer`.
- Tester Slint, Iced et egui sur le nouveau chemin.
- Tester SDL2 Wayland si possible.
- Conserver OSMesa/LLVMpipe pour les clients qui ont besoin d'OpenGL CPU.

### Validation

Au moins une application Rust via `winit` ou `softbuffer` s'affiche dans le compositor Wayland Redox.

## Phase 10 : Stabilisation Desktop Minimal

### Objectif

Rendre le remplacement d'Orbital credible pour le developpement experimental.

### Fonctionnalites

- `xdg-shell` basique ;
- clipboard Wayland minimal ;
- multi-fenetre robuste ;
- resize output ;
- key repeat ;
- keymap simple ;
- logs structures ;
- tests pixels ;
- tests input.

### Validation

Des clients Wayland non triviaux peuvent tourner sans adaptation lourde.

## Phase 11 : Accessibilite Initiale

### Objectif

Faire de l'accessibilite une capacite native du desktop Redox.

### Fonctionnalites prioritaires

- navigation clavier complete dans le shell minimal ;
- focus visible ;
- ordre de focus stable ;
- raccourcis configurables ;
- contraste eleve ;
- taille de curseur configurable ;
- zoom logiciel basique ;
- metadata de fenetres/surfaces.

### Validation

La session minimale peut etre utilisee sans souris pour lancer, focaliser, deplacer et fermer une application.

## Phase 12 : Acceleration GPU Experimentale

### Objectif

Preparer la transition vers l'acceleration materielle sans casser le rendu CPU.

### Taches

- Definir un trait `Renderer`.
- Garder le renderer CPU comme reference.
- Ajouter abstraction de buffers :
  - shm CPU ;
  - futur buffer GPU ;
  - import/export futur.
- Etudier :
  - drivers DRM userspace Redox ;
  - backend Redox Mesa3D ;
  - LLVMpipe comme transition ;
  - virtio-gpu ;
  - wgpu si viable ;
  - renderer Rust dedie si necessaire.

### Validation

Le compositor peut choisir entre renderer CPU et backend experimental sans changer sa logique Wayland.

## Phase 13 : Preparation Smithay/COSMIC

### Objectif

Transformer les acquis du compositor minimal en backend reusable pour Smithay/COSMIC.

### Taches

- Extraire un backend Redox propre :
  - display ;
  - input ;
  - session ;
  - renderer logiciel.
- Porter une demo type `smallvil` ou `anvil`.
- Auditer `cosmic-comp`.
- Remplacer les dependances Linux :
  - libinput ;
  - udev ;
  - libseat/logind ;
  - systemd ;
  - EGL/GBM si absent.

### Validation

Smithay ou un `cosmic-comp` reduit peut utiliser les primitives developpees.

## Phase 14 : Horizon Serveur X11 Rust Compatible Xwayland

### Objectif

Apres stabilisation Wayland, lancer un projet separe de serveur X11 Rust.

### MVP X11

- handshake X11 ;
- table de ressources ;
- `CreateWindow` ;
- `MapWindow` ;
- `DestroyWindow` ;
- `ConfigureWindow` ;
- `PutImage` ;
- `CopyArea` ;
- events clavier/souris ;
- `Expose` ;
- fenetre top-level transformee en surface Wayland.

### Extensions ensuite

- BIG-REQUESTS ;
- MIT-SHM ;
- XFIXES ;
- DAMAGE ;
- RENDER ;
- RANDR minimal ;
- XInput2 minimal ;
- Composite plus tard ;
- GLX tres tard.

### Validation

Une application X11 simple peut ouvrir une fenetre, dessiner et recevoir input dans la session Wayland Redox.

## Jalons Annuels Indicatifs

### Annee 1 : Audit Et Fondations

Livrables :

- audit complet de l'existant Redox GUI ;
- tests fd passing/shm/mmap ;
- serveur Wayland minimal ;
- client Wayland test ;
- backend display affichant des pixels sans Orbital.

Validation :

- le socle systeme est compris ;
- une surface shm peut etre recue ;
- l'ecran peut etre controle dans une demo hors Orbital.

### Annee 2 : Premier Compositor

Livrables :

- input Redox ;
- surfaces shm composees ;
- curseur ;
- focus ;
- damage ;
- plusieurs fenetres simples.

Validation :

- deux clients Wayland simples s'affichent et recoivent input.

### Annee 3 : Remplacement Experimental d'Orbital

Livrables :

- integration session ;
- terminal minimal ;
- launcher minimal ;
- clipboard texte initial ;
- `xdg-shell` basique ;
- navigation clavier ;
- focus visible.

Validation :

- Orbital n'est plus requis pour une session graphique experimentale.

### Annee 4 : Stabilisation Et Migration

Livrables :

- multi-fenetre robuste ;
- tests automatiques ;
- keymap/repeat ;
- migration `winit`/`softbuffer` ou equivalent ;
- mode contraste eleve ;
- zoom logiciel basique ;
- trait renderer CPU/GPU.

Validation :

- au moins une app issue de l'ecosysteme existant Redox/Orbital tourne sur le nouveau compositor.

### Annee 5 : Smithay/COSMIC/GPU

Livrables :

- backend Smithay Redox avance ;
- premiere execution de `cosmic-comp` reduit ou demo equivalente ;
- backend GPU experimental ou rapport technique documentant les blocages ;
- service accessibilite experimental ;
- debut du serveur X11 Rust seulement si le socle est stable.

Validation :

- decision claire : continuer compositor maison, migrer vers Smithay, ou brancher COSMIC directement ;
- decision claire sur le chemin GPU : Mesa/DRM userspace, virtio-gpu, wgpu, renderer Rust dedie, ou CPU optimise.

## Definition Du MVP

Le MVP est atteint quand :

- Redox peut demarrer une session graphique sans Orbital ;
- le compositor Wayland minimal prend l'ecran ;
- un client Wayland shm s'affiche ;
- clavier et souris fonctionnent ;
- plusieurs surfaces peuvent coexister ;
- le focus fonctionne ;
- le damage fonctionne ;
- une application minimale type terminal ou launcher peut etre lancee ;
- la navigation clavier minimale fonctionne ;
- le focus visible est implemente.

## Definition Du Remplacement Orbital

Orbital peut etre considere remplace experimentalement quand :

- le boot graphique peut utiliser le compositor Wayland dans une image de test ;
- les applications de base ont une alternative Wayland ;
- le debug reste possible depuis un terminal ;
- le compositor peut etre quitte ou redemarre proprement ;
- un fallback Orbital existe pendant la transition ;
- l'utilisateur peut effectuer les actions principales au clavier.

Orbital peut etre considere remplace fonctionnellement quand :

- les composants desktop essentiels sont disponibles en Wayland ;
- les tests de session passent regulierement ;
- la gestion input/output est stable ;
- la memoire partagee ne fuit pas ;
- les crashs clients ne tuent pas le compositor ;
- les bases d'accessibilite sont presentes ;
- une strategie GPU est implementee ou documentee avec backend experimental.

## Risques Majeurs

### Primitives OS Insuffisantes

Wayland depend fortement de sockets, fd passing, shm et mmap.

Mitigation :

- traiter cette phase avant tout port COSMIC ;
- maintenir des tests bas niveau.

### GPU Trop Immature

Redox n'a pas encore de drivers GPU complets.

Mitigation :

- renderer CPU obligatoire ;
- LLVMpipe/OSMesa comme pont ;
- interface renderer stable ;
- backend GPU experimental seulement apres stabilisation.

### Scope Trop Large

COSMIC et X11 peuvent absorber plusieurs annees.

Mitigation :

- les exclure du MVP ;
- avancer par clients Wayland simples.

### Divergence Avec Wayland Standard

Un compositor maison peut devenir incompatible.

Mitigation :

- utiliser `wayland-rs` ;
- tester avec clients externes ;
- implementer `xdg-shell`.

### Accessibilite Oubliee

Un desktop impossible a utiliser sans souris serait incomplet.

Mitigation :

- navigation clavier dans le MVP ;
- focus visible obligatoire ;
- metadata accessibles definies tot.

## Crates Proposees

```text
crates/
    redox-wl-compositor/
    redox-wl-display/
    redox-wl-input/
    redox-wl-render/
    redox-wl-accessibility/
    redox-wl-protocol-tests/
```

## Documents A Produire Ensuite

Apres ce plan global, les documents utiles seront :

```text
docs/existing-redox-gui.md
docs/redox-wayland-primitives.md
docs/compositor-architecture.md
docs/display-backend-redox.md
docs/input-backend-redox.md
docs/software-rendering-and-gpu-roadmap.md
docs/accessibility-roadmap.md
docs/orbital-migration.md
docs/cosmic-smithay-roadmap.md
docs/x11-compat-rust-roadmap.md
```

## Ordre D'Etude Recommande

1. Lire ce document global en entier.
2. Lire le code Orbital actuel :
   - `main.rs`
   - `core/display.rs`
   - `core/mod.rs`
   - `compositor.rs`
   - `scheme.rs`
   - `window.rs`
3. Etudier `graphics-ipc` et `inputd`.
4. Etudier `vesad` et le chemin framebuffer Redox.
5. Etudier comment LLVMpipe/OSMesa sont integres.
6. Etudier `wayland-rs`, surtout `wayland-backend`, `wayland-server`, `wayland-client`.
7. Etudier ensuite Smithay.
8. Etudier COSMIC seulement apres les bases Wayland Redox.

## Regle De Progression

Chaque phase doit produire :

- un binaire testable ;
- une demo visible ;
- des logs exploitables ;
- au moins un test automatique quand possible ;
- une note de limitations.

Ne pas passer a COSMIC tant que le compositor minimal ne peut pas remplacer Orbital dans une image experimentale.

Ne pas lancer le serveur X11 Rust tant que le compositor Wayland ne sait pas gerer correctement surfaces, focus, damage et input.