Serait-ce pour ça que j'ai dit "on peut presque dire " ? Ce que je voulais dire, c'est que point de vue utilisateur, ça y ressemble ( surtout s'il s'agit d'un jeu qui a implémenté correctement la capture de la souris ), alors qu'en terme de fonctionnement interne, je sais que ça n'a rien à voir. Je ne suis pas bon, mais il y a des limites tout de même :)
Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran. ( je parle du moment de sa création, je sais que c'est maintenant possible )
Ca par contre, c'est un peu faux. ... le windows manager, le composite manager et X ont ete merge ensemble.
Dans la FaQ de Wayland, il est dit qu'un des problèmes de X est la surabondance de fonctionnalités qui ne sont plus utiles à l'heure actuelle, et qu'il est nécessaire d'implémenter si l'on veut prétendre au titre de serveur X.
Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois? ( Je n'émet aucun jugement quant au fait que ce soit une bonne ou une mauvaise chose, hein, je dis juste que c'est possible en peu de lignes. )
Du coup je m'imagine qu'il y a moyen que ça prenne moins de lignes de code de faire un serveur Wayland qu'un serveur X.
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
Je me trompe peut-être, mais Wayland est bien un protocole d'échange entre le serveur graphique et les applications, non? A partir de la, qu'est-ce qui empêcherait d'avoir un mécanisme d'IPC? Ce genre de choses existe depuis bien longtemps, et si Wayland finit par être réellement adopté, je doute que personne ne fera de serveur Wayland sur les autres systèmes.
En fait, je doute que Wayland ne sera implémenté que pour linux sur amd64 ( puisque tu parles du rPI notamment, je serai surpris qu'il n'y ait pas un port dans plus ou moins longtemps ) et à force d'avoir diverses implémentations, peut-être qu'une lib se dégagera?
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
Je n'ai pas creusé très loin, mais il semble que certains essaient.
En plus, même de la diversité non portable, c'est une bonne chose. Je ne vois aucun inconvénient à avoir une alternative à X, qu'elle soit portable ou non.
Pour BSD, vu qu'il y a moyen de faire tourner Wayland sur X je crois, il y aura au minimum cette solution la, même si la personne qui à fait quelques patchs à lâché l'affaire depuis ( je n'ai pas creusé, comme je l'ai dit. ).
Je pense que Wayland est un protocole, et qu'en tant que tel, il est possible de coder ( que ce soit plus ou moins simple en fonction de la cible, c'est évident ) un serveur Wayland sur n'importe quel OS qui ait des périphériques d'entrée pointage+saisie et un périphérique de sortie type écran. Je me trompe peut-être.
[^] # Re: Gestionnaire de fenêtres léger
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
Serait-ce pour ça que j'ai dit "on peut presque dire " ? Ce que je voulais dire, c'est que point de vue utilisateur, ça y ressemble ( surtout s'il s'agit d'un jeu qui a implémenté correctement la capture de la souris ), alors qu'en terme de fonctionnement interne, je sais que ça n'a rien à voir. Je ne suis pas bon, mais il y a des limites tout de même :)
Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran. ( je parle du moment de sa création, je sais que c'est maintenant possible )
Dans la FaQ de Wayland, il est dit qu'un des problèmes de X est la surabondance de fonctionnalités qui ne sont plus utiles à l'heure actuelle, et qu'il est nécessaire d'implémenter si l'on veut prétendre au titre de serveur X.
Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois? ( Je n'émet aucun jugement quant au fait que ce soit une bonne ou une mauvaise chose, hein, je dis juste que c'est possible en peu de lignes. )
Du coup je m'imagine qu'il y a moyen que ça prenne moins de lignes de code de faire un serveur Wayland qu'un serveur X.
Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
Je me trompe peut-être, mais Wayland est bien un protocole d'échange entre le serveur graphique et les applications, non? A partir de la, qu'est-ce qui empêcherait d'avoir un mécanisme d'IPC? Ce genre de choses existe depuis bien longtemps, et si Wayland finit par être réellement adopté, je doute que personne ne fera de serveur Wayland sur les autres systèmes.
En fait, je doute que Wayland ne sera implémenté que pour linux sur amd64 ( puisque tu parles du rPI notamment, je serai surpris qu'il n'y ait pas un port dans plus ou moins longtemps ) et à force d'avoir diverses implémentations, peut-être qu'une lib se dégagera?
Je n'ai pas creusé très loin, mais il semble que certains essaient.
En plus, même de la diversité non portable, c'est une bonne chose. Je ne vois aucun inconvénient à avoir une alternative à X, qu'elle soit portable ou non.
Pour BSD, vu qu'il y a moyen de faire tourner Wayland sur X je crois, il y aura au minimum cette solution la, même si la personne qui à fait quelques patchs à lâché l'affaire depuis ( je n'ai pas creusé, comme je l'ai dit. ).
Je pense que Wayland est un protocole, et qu'en tant que tel, il est possible de coder ( que ce soit plus ou moins simple en fonction de la cible, c'est évident ) un serveur Wayland sur n'importe quel OS qui ait des périphériques d'entrée pointage+saisie et un périphérique de sortie type écran. Je me trompe peut-être.