Désolé mais non, parce que l'ajout de Mir implique des modifications dans d'autres projets, comme celles nécessaires à l'ajout de Wayland : Mesa, tous les toolkits...
Je ne parlais pas du côté client mais plutôt de la partie entre le compositeur et le matériel (le driver model).
Cette partie n'ai apparemment pas définie dans libwayland-server, ce qui implique que chaque compositeur en fera sa propre implémentation.
Techniquement, il est possible de développer un nouveau frontend pour Mir qui lui permette de parler Wayland à ses clients (cf. la doc de Mir). ce qui ferait de Mir un compositeur Wayland comme un autre.
Ce qui n'apporterai pas magiquement le support des pilotes Mir (libres, Android, bientôt proprio) aux autres compositeurs Wayland.
Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).
Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.
Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.
Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé. On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas).
C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
Je ne parlais pas du côté client mais plutôt de la partie entre le compositeur et le matériel (le driver model).
Cette partie n'ai apparemment pas définie dans libwayland-server, ce qui implique que chaque compositeur en fera sa propre implémentation.
Techniquement, il est possible de développer un nouveau frontend pour Mir qui lui permette de parler Wayland à ses clients (cf. la doc de Mir). ce qui ferait de Mir un compositeur Wayland comme un autre.
Ce qui n'apporterai pas magiquement le support des pilotes Mir (libres, Android, bientôt proprio) aux autres compositeurs Wayland.
Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).
Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.
Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.
Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé. On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas).
C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.
On verra bien ce que tout ça donnera !