Principalement parce que SurfaceFlinger est un projet a code ouvert que Google controle completement et destine uniquement a l'embarque (Google ne l'utilise pas sur ses ChromeBook). Wayland a l'oppose a ete concu pour pouvoir fonctionner sur toute la gamme des machines sur lequel un Linux tourne. Le protocol est le resultat de la cooperation de personne qui ont des annees d'experience avec X, les Window Manager, les Composite Manager, les drivers, les toolkits graphiques, en securite, en embarque … C'est un travail enorme et colossale qui a ete realise et il y a encore beaucoup a faire. La plus part des gens ne se rendent pas compte de l'ensemble des contraintes et des problemes a resoudre. La plus grande reussite de Wayland, c'est d'avoir reussi a attirer tous ces gens. Ce que ni SurfaceFlinger, ni DirectFB et pas non plus Mir a reussi a faire.
Quand on regarde la TODO de Mir, on se rend compte qu'ils n'ont meme pas encore attaque les sujets difficiles. Il y a un total manque d'experience de leur cote et ce projet va probablement avoir un destin funeste.
Il est comprehensible qu'ils se demarque de X, vu qu'ils ont du mal a monetiser leur plateforme Linux desktop et qu'il se tourne vers Android pour ca. Or cela veut dire se baser alors sur la stack graphique de Android. Je comprend en tout cas leur effort vers Mir comme un objectif de devenir une distribution Android. Mais bon, ils ont loupe que le protocol Wayland ne definit pas ce qu'est un buffer ID et que sous Android on aurait tres bien pu utiliser Gralloc. Il n'y a rien d'ailleur qui empeche d'ajouter un second protocol a son serveur Wayland pour gerer le protocol de SurfaceFlinger quand on est sous Android.
Il est tres probable que la plus part des implementations de Wayland implemente a terme plus que juste KMS. Ainsi avoir un backend fbcon est necessaire pour etre portable sur les BSD. Un backend XPixmap pour avoir acces au driver proprio NVidia. Donc un backend Android ne sera finalement plus que un backend supplementaire. Pourquoi pas aussi un backend SDL ? Et le code necessaire pour ses backend se limitera a peu de chose pres a gestion de buffer et lecture des inputs. Tout le reste du code etant commun a toutes les plateformes.
[^] # Re: Quelques infos
Posté par cedric . En réponse au journal Mir, un serveur d'affichage de trop ?. Évalué à 10.
Principalement parce que SurfaceFlinger est un projet a code ouvert que Google controle completement et destine uniquement a l'embarque (Google ne l'utilise pas sur ses ChromeBook). Wayland a l'oppose a ete concu pour pouvoir fonctionner sur toute la gamme des machines sur lequel un Linux tourne. Le protocol est le resultat de la cooperation de personne qui ont des annees d'experience avec X, les Window Manager, les Composite Manager, les drivers, les toolkits graphiques, en securite, en embarque … C'est un travail enorme et colossale qui a ete realise et il y a encore beaucoup a faire. La plus part des gens ne se rendent pas compte de l'ensemble des contraintes et des problemes a resoudre. La plus grande reussite de Wayland, c'est d'avoir reussi a attirer tous ces gens. Ce que ni SurfaceFlinger, ni DirectFB et pas non plus Mir a reussi a faire.
Quand on regarde la TODO de Mir, on se rend compte qu'ils n'ont meme pas encore attaque les sujets difficiles. Il y a un total manque d'experience de leur cote et ce projet va probablement avoir un destin funeste.
Il est comprehensible qu'ils se demarque de X, vu qu'ils ont du mal a monetiser leur plateforme Linux desktop et qu'il se tourne vers Android pour ca. Or cela veut dire se baser alors sur la stack graphique de Android. Je comprend en tout cas leur effort vers Mir comme un objectif de devenir une distribution Android. Mais bon, ils ont loupe que le protocol Wayland ne definit pas ce qu'est un buffer ID et que sous Android on aurait tres bien pu utiliser Gralloc. Il n'y a rien d'ailleur qui empeche d'ajouter un second protocol a son serveur Wayland pour gerer le protocol de SurfaceFlinger quand on est sous Android.
Il est tres probable que la plus part des implementations de Wayland implemente a terme plus que juste KMS. Ainsi avoir un backend fbcon est necessaire pour etre portable sur les BSD. Un backend XPixmap pour avoir acces au driver proprio NVidia. Donc un backend Android ne sera finalement plus que un backend supplementaire. Pourquoi pas aussi un backend SDL ? Et le code necessaire pour ses backend se limitera a peu de chose pres a gestion de buffer et lecture des inputs. Tout le reste du code etant commun a toutes les plateformes.