Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.
Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.
En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).
Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.
Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston. Le mainteneur de Kwin veut faire son propre compositeur parce qu'il ne veut tout simplement pas jeter tout le code de Kwin à la poubelle et qu'il pense pouvoir garder une grande base commune entre le support de X.org et Wayland (la gestion des fenêtre, le rendu des bordure, les thèmes...).
De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.
L'approche de Mir semble plutôt être de vouloir tout gluer ensemble (https://wiki.ubuntu.com/Mir/Spec?action=AttachFile&do=get&target=mir-scope.png). Je ne comprend pas trop ce qu'il faudrait séparer entre le bureau et le compositeur. Il faut se rappeler que dans le cas de Wayland, ce sont les applications qui font le rendu de leur contenu et le compositeur se charge juste de l'afficher à l'écran et de gérer les fenêtres. Je vois mal comment on pourrait séparer celui qui affiche les fenêtres de celui qui les gère.
(car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).
Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.
Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
Toujours pareil, on aimerait bien voir ces fameux drivers avec le support pour Mir. Dans la situation actuelle, principalement sur les téléphones mobiles, il y a libhybris, qui peut être exploitée par Wayland/Weston (http://en.wikipedia.org/wiki/Hybris_%28software%29). Je doute très fortement que Cannonical arrivera à obtenir autre chose que ce "standard" implicite obtenu avec les drivers propriétaires pour Android. Dans le cas ou ils y arriveraient, qu'est-ce qui empêcherait les compositeurs Wayland de supporter aussi cette nouvelle librairie spéciale Mir ?
Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?
Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.
[^] # Re: Waylands et Mir ?
Posté par Siosm . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 4.
En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).
Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston. Le mainteneur de Kwin veut faire son propre compositeur parce qu'il ne veut tout simplement pas jeter tout le code de Kwin à la poubelle et qu'il pense pouvoir garder une grande base commune entre le support de X.org et Wayland (la gestion des fenêtre, le rendu des bordure, les thèmes...).
L'approche de Mir semble plutôt être de vouloir tout gluer ensemble (https://wiki.ubuntu.com/Mir/Spec?action=AttachFile&do=get&target=mir-scope.png). Je ne comprend pas trop ce qu'il faudrait séparer entre le bureau et le compositeur. Il faut se rappeler que dans le cas de Wayland, ce sont les applications qui font le rendu de leur contenu et le compositeur se charge juste de l'afficher à l'écran et de gérer les fenêtres. Je vois mal comment on pourrait séparer celui qui affiche les fenêtres de celui qui les gère.
Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.
Toujours pareil, on aimerait bien voir ces fameux drivers avec le support pour Mir. Dans la situation actuelle, principalement sur les téléphones mobiles, il y a libhybris, qui peut être exploitée par Wayland/Weston (http://en.wikipedia.org/wiki/Hybris_%28software%29). Je doute très fortement que Cannonical arrivera à obtenir autre chose que ce "standard" implicite obtenu avec les drivers propriétaires pour Android. Dans le cas ou ils y arriveraient, qu'est-ce qui empêcherait les compositeurs Wayland de supporter aussi cette nouvelle librairie spéciale Mir ?
Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.