parce que tu crois que chaque application inclut Xorg dans ses sources ?
Je pense qu'il faut prendre 'application' au sens large (application ou toolkit) dans son post pour comprendre son point.
On va dire 2 ans pour stabiliser Wayland, 2 ans pour que les toolkits l'exploitent bien: à l'horizon 2015 si tu dépends d'X pour les accès distant en WAN, il y aura de quoi être nerveux: l'histoire d'XCB l'a montré les toolkits essayent vraiment de supporter X "a minima".
Il me semble avoir lu un démenti d'Interpol qui niait avoir transmis ce dossier, c'est dans le cadre d'un accord de coopération entre les 2 pays qu'il aurait été arrêter: les théocratie s'entraident..
Pour ce qui est de Sarko, je ne l'aime pas mais dans le cas présent je ne lui en veut même pas: c'est un homme politique "pur jus" qui diras tout et son contraire quand c'est utile, pouvoir acheter le pétrole Saoudien est utile.
Est-ce que c'est réglable application par application?
Le mode native parait adapté a une application affiché en distant et les 2 autres pour l'affichage local.
Pour (1) imagine par exemple qu'on a rendu un paragraphe de texte avec Cairo dans un pixmap. Pour le compositing OpenGL, on va avoir besoin de lire ce pixmap depuis OpenGL, ce qui necessite de l'interpreter comme une texture.
J'avais bien compris, mais ce que je ne comprends pas c'est pourquoi il y a une différence, pour moi les deux ce sont des buffers dans un GPU.
Mais la bonne facon de resoudre ca est de continuer d'etendre OpenGL pour couvrir ces besoins (la 2D, c'est dur).
Hum, dernièrement OpenGL a eu tendance à se simplifier en retirant les machins obsolètes qui ne correspondait plus au mode de fonctionnement des cartes, donc j'ai comme un doute sur l'extension OpenGL sur ce point là ait un grand avenir..
Pour (3), Wayland a été décrit comme "violently asynchronous" par Kristian Høgsberg, alors je ne suis pas sûr que ça soit beaucoup plus simple..
Ton poste est un peu du n'importe quoi, si on ferme les yeux tout se ressemble OK, mais bon dire ça ne fait pas beaucoup avancer les choses..
Une petite évolution ou une révolution qui change totalement les caractéristiques réseaux du système je ne trouves pas que ça revient au même!
Quelque chose me dit que tu ne dois pas avoir besoin de l'affichage distant autrement tu ne penserais pas ça..
Tu ne peux pas appeler Wayland X12 pour la même raison que tu ne peux pas appeler (Quartz + VNC) X12: même si l'incrémentation du numéro de version signifie "incompatible" il faut quand même que:
1- cette incompatibilité soit limitée
2- le nouveau système reste dans l'esprit X: l'esprit initial était de faire un système avec la transparence réseau donc efficace en utilisation de bande passante, d'abord tout le rendu coté serveur, puis quand ça a posé des problèmes on est passé a un équilibre entre le client et le serveur avec XRender (les fontes sont rendues sur le client et cachées sur le serveur par exemple Glyphset), dommage cependant que la possibilité de compression des bitmap pour le fond ait été ajouter dans NX mais pas dans X..
Le système de Wayland d'avoir l'application qui rend toute la fenêtre et tant pis pour la bande passante utilisée me parait totalement différent de l'esprit X: si tu veux vraiment résoudre les problèmes d'X et avoir à la fois un système efficace en local et en distant tu n'obtiens pas Wayland, tu obtiens un mélange X(XRender), de NX (compression des pixmap, diminution du nombre de RTT) et de Wayland (passage de buffer dans la mémoire du GPU entre le client et le serveur).
Par contre si tu veux résoudre les problèmes de l'embarqué (rien à faire de la transparence réseau, mais il faut que ce soit efficace en local) alors là oui, tu obtiens Wayland.
Hum si: la gestion des fenêtres se fait par le processus compositeur (Weston) sur Wayland.
Sur X la gestion des fenêtres se fait par un processus séparé.
Et par défaut les 2 ne font pas tout a la même chose car sur Wayland par défaut c'est le client qui dessine ses décorations de fenêtres.
Pour (1) pourquoi y a t'il besoin de convertir les pixmap et les textures OpenGL? C'est une question de format?
Pour (2), l'intérêt d'XRender c'est que ça permet d'utiliser efficacement le réseau, mais effectivement en local c'est probablement moins efficace que le modèle a la Wayland.
Pour (3), si je me souviens bien X était une "amélioration" de W qui lui était synchrone: je ne vois pas trop comment avoir des erreurs synchrone sur un protocole asynchrone, ni comment un protocole synchrone pourrait être efficace en distant.
Pour (4), ça parait être principalement un problème OpenGL donc il me semble que tu peut avoir exactement le même problème avec Wayland.
Les toolkits modernes (Qt, gtk, fltk, ...) se contentent d'écrire dans un buffer et de le transmettre à X.
Hum, ce qu'il dit me parait être un grand raccourci: regardes les GlyphSet d'XRender, X permet au toolkit d'envoyer du texte en distant de manière assez efficace (une fois que tu as transmis une glyphe tu peux la réutiliser..) et une recherche Qt GlyphSet m'a donné quelques résultats: donc apparemment ils utilisent ce mécanisme).
On a donc un pixmap non compressé qui est transféré au serveur X
Pour le texte regarde plus haut, pour le fond effectivement envoyer les pixmap non compressé c'est pas terrible, mais c'est pour ça que NX compresse les pixmap il me semble(*), avec Wayland un buffer contiendrait à la fois le fond et le texte, donc si on essayait de compresser le buffer ce serait bien pire!
Pour le cas local, je ne vois pas pourquoi ce serait impossible d'ajouter a X des références vers de la mémoire du GPU de la même manière que la "shared memory" lui a été ajouté..
j'ai du mal à comprendre qu'on ne leur fasse pas plus confiance.
Et bien si les justifications de Kristian étaient plus convaincantes ça aiderait!
Quand LibreOffice a du code mort, ils le virent, ils ne changent pas totalement la conception..
*: personne n'a dit qu'X était idéal pour le réseau, NeWS ou Berlin/Fresco étaient meilleurs coté réseau (paix à leurs âmes), mais vu que Wayland sera pire de ce coté là, ce n'est pas un argument pour Wayland, c'est un argument pour intégrer NX à X.
Mais si une partie du serveur graphique est intégrable dans NewOS j'y vois un gros avantage en perf car ça n'arrivera jamais avec Linux.
C'est le cas? Coté doc je n'ai rien trouvé..
Sinon pour répondre à ta question: avec le Linux 'standard' non, mais qui t’empêche de faire ton propre patch?
C'est du travail bien sûr, mais créer/porter tout les autres drivers à mon avis ça réprésente bien plus de travail..
Bien supporté par XRender (qui dans X). Et note que l'approche 'bitmap' peut utiliser bien moins de bande passante quand tu envoie d'un coté le texte (GlyphSet), de l'autres les "images de de fond" plutôt qu'un buffer qui contient une image de la fenetre (va essayer de compresser ça sans induire de retard!).
Wayland est né de ce constat : X n'est plus adapté à l'utilisation qu'en ont les applications.
Bof, c'est une justification foireuse: du même constat tu pourrait dire, faisons X12 qui vire tout le code mort/inutilisé (draw stippled line) mais qui garde XRender.
Pour les toolkits, ça changerait même moins de chose!
Je le répète la vrai justification de Wayland c'est d'avoir un rendu local plus performant pour l'embarqué.
Pour la situation b), il faudrait sur le client un serveur wayland qui écrit dans un un buffer à lui et qui envoie les buffers par le reseau.
Coté serveur, un client proxy qui ne fait que transmettre les buffers au vrai serveur.
Ca ressemble furieusement à du Vnc ou rfb :)
Oui.. Note qu'à l'heure actuelle Wayland ne transmet que des fenêtres complètes entre le client et le serveur donc ça ne sera pas très efficace, mais en LAN ça doit passer..
Pour la situation c), il me semble que le serveur wayland exisant sait déjà quasiment le faire puisque il peut s'utiliser en tant que client X.
Oups, tu as raison j'avais oublié ça, un comble puisque c'est comme ça que Wayland a bootstrappé!
mais il présente a posteriori un défaut d'architecture en séparant le compositeur et le serveur.
Ce n'est pas le seul: il faudrait aussi ajouter un mode ou les clients puissent envoyer une référence vers un buffer dans la mémoire du GPU (et non plus seulement en mémoire principale partagée).
Ce défaut ne peut-il être corrigé dans X ?
Techniquement tout est possible, c'est au niveau de la main d'oeuvre/volonté que ça pèche.
En quoi lancer Wayland résoudrait ce problème ?
Pour X en rien, qui te dis que les développeurs de Wayland veulent résoudre les problèmes d'X??
Ils veulent résoudre leur problème qui est de faire un système d'affichage efficace en local pour l'embarqué.
Au final, dire que X est sous-utilisé ressemble fortement à la rage...
Hein? Personne n'a dis ça, tu as lu de travers. L'article dit juste qu'X a plein de fonctionnalité non-utilisée car obsolète, ce qui complique la maintenance du serveur X.
Augmenter les performances en local.
Ce projet vient de l'embarqué: ça répond très bien à leurs besoins.
vu que wayland est quand même présent en tant que serveur lorsque l'on souhaite en utiliser un autre que Weston
Pff, tu pourrais faire un peu plus attention en lisant les descriptions..
Wayland c'est une interface, une API (comme X), qui sera accessible a partir de librairie qu'utiliseront les clients et les serveurs (Weston et autres).
Dans le système Wayland, il y aura un seul processus serveur qui fait compositeur et gestionnaire de fenêtre.
ça risque peut-être de coincer lorsque l'on voudra utiliser une appli Qt/KDE hors de celui-ci
En théorie oui, mais en pratique les devs Qt/KDE ont bossé pour que tu puisse utiliser une appli Qt/KDE sous GNOME sans que tu voie trop la différence (et vice versa), donc je pense qu'il y aura la même chose avec Wayland.
Et si j'ai bien compris, wayland aura quand même besoin de X pour pas mal de cas donc il faudrait que les deux tournent simultanément.
Pour la compatibilité et la transparence réseau "efficace" oui. Si tu n'utilise pas ça non.
Je plains d'avance les distribs qui choisiront wayland pour essuyer les plâtre. (ubuntu?)
Probablement Ubuntu oui: ils visent l'embarqué.
Le seul avenir (lointain) que je peux voir pour Wayland serait un serveur d'abstraction pour plusieur environnement (X ou autre)
Hum, ta boule de crystal est plantée, une fois que l'application a rendu son image dans un buffer c'est trop tard pour X! Enfin techniquement tu peux, tu as juste des performances réseau pourrie..
OK pour une solution de repli, mais il faut espérer que peu d'utilisateurs seront dans ce cas car il se peut que leur système soit alors moins performant qu'avec X!
Je l'ai lu moi et il me semble que ça n'existe pas non.
Il y aura juste une API pour que le client indique ou se trouve le bouton pour fermer la fenêtre afin qu'un serveur puisse tuer un client non-réactif, c'est tout.
En effet quitte à pousser un desktop libre autant pousser Haiku qui est conçu pour cela
Un desktop Haiku restera certainement beaucoup plus réactif qu'un desktop Linux (même avec Wayand), mais Haiku a fait l'énorme erreur d'utiliser un noyau (NewOS) très peu utilisé plutôt que Linux ou FreeBSD alors non merci: à cause de ce choix, il est quasiment sûr qu'Haiku n'atteindra jamais la "masse critique".
Les développeurs de Wayland n'ont pas fait cette erreur eux..
Ce n'est pas très clair : Wayland intègre son gestionnaire de fenêtres mais les fenêtres doivent elles-mêmes dessiner leurs décorations ?
Oui, c'est le comportement par défaut.
Ça semble un peu idiot,
Non: aucune solution n'est idéale, c'est un compromis.
L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.
ça promet un beau bordel bien disparate,
Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
La synchro se fera par du EWMH j'imagine.
la résistance à Wayland promet d'être féroce.
Il y a des raisons de ne pas aimer Wayland:
-non portabilité actuelle sur les *BSD
-un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.
Bah, ça vraiment c'est le problème le plus mineur et le plus simple a résoudre..
Il existe déjà sous X pour tout ce qui n'est pas la décoration de la fenêtre d'ailleurs: en pratique ça n'est pas un problème car les toolkits sont assez souple et configuré par les distributions pour que le "look n'feel" soit homogène (enfin à peu près).
Non! Pour que Wayland soit utile, il faut utiliser une API qui permette de partage la mémoire du GPU entre le client et le compositeur (GEM il me semble), autrement tu te retrouves avec le cas suivant: le client utilise le GPU pour rendre son application dans un buffer du GPU puis il faut lire le buffer du GPU pour le mettre en mémoire principale (lent) et ensuite le recopier de nouveau sur le GPU pour le "composer" et l'afficher: autant utiliser X car ça tue les performances..
Sinon d'accord avec toi, il n'y a pas d'API entre le serveur d'affichage et le compositeur: le serveur d'affichage est le compositeur.
Dommage d'ailleurs que ça n'ai pas été fait pour X: rien dans X n'impose d'avoir le serveur d'affichage et le compositeur séparé, certes c'est plus modulaire mais à mon avis dans ce cas là ce n'est pas une bonne chose.
Ça permettra aux applications X de continuer à tourner, c'est déjà ça.
Euh non, ça permettra aux applications GTK, Qt (etc) de tourner, mais pour les applications pure X (il y en a peu OK) il faut installer un serveur X/client Wayland pour la compatibilité: pas de problème ça existe déjà.
Pour ta seconde question, il n'y a pas actuellement l'équivalent de KMS sur les *BSD (pas sûr pour les autres API), mais je pense que ça viendra: ne serait-ce que pour pouvoir éviter d'avoir X en tant que root c'est intéressant.
La réponse est compliquée:
1) en LAN, il y a plusieurs solutions:
a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.
b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".
c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).
2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
Mais pour les autres cas, la bande passante utilisée sera trop élevée.
Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..
[^] # Re: Mauvaise foi
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Je pense qu'il faut prendre 'application' au sens large (application ou toolkit) dans son post pour comprendre son point.
On va dire 2 ans pour stabiliser Wayland, 2 ans pour que les toolkits l'exploitent bien: à l'horizon 2015 si tu dépends d'X pour les accès distant en WAN, il y aura de quoi être nerveux: l'histoire d'XCB l'a montré les toolkits essayent vraiment de supporter X "a minima".
# Interpol a dementi il me semble
Posté par reno . En réponse au journal Un journaliste menacé de mort pour blasphème interpellé avec l'aide d'interpol. Évalué à 4.
Il me semble avoir lu un démenti d'Interpol qui niait avoir transmis ce dossier, c'est dans le cadre d'un accord de coopération entre les 2 pays qu'il aurait été arrêter: les théocratie s'entraident..
Pour ce qui est de Sarko, je ne l'aime pas mais dans le cas présent je ne lui en veut même pas: c'est un homme politique "pur jus" qui diras tout et son contraire quand c'est utile, pouvoir acheter le pétrole Saoudien est utile.
[^] # Re: Mauvaise foi
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Est-ce que c'est réglable application par application?
Le mode native parait adapté a une application affiché en distant et les 2 autres pour l'affichage local.
[^] # Re: Comment X penalise Firefox / Linux
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
J'avais bien compris, mais ce que je ne comprends pas c'est pourquoi il y a une différence, pour moi les deux ce sont des buffers dans un GPU.
Hum, dernièrement OpenGL a eu tendance à se simplifier en retirant les machins obsolètes qui ne correspondait plus au mode de fonctionnement des cartes, donc j'ai comme un doute sur l'extension OpenGL sur ce point là ait un grand avenir..
Pour (3), Wayland a été décrit comme "violently asynchronous" par Kristian Høgsberg, alors je ne suis pas sûr que ça soit beaucoup plus simple..
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Ton poste est un peu du n'importe quoi, si on ferme les yeux tout se ressemble OK, mais bon dire ça ne fait pas beaucoup avancer les choses..
Une petite évolution ou une révolution qui change totalement les caractéristiques réseaux du système je ne trouves pas que ça revient au même!
Quelque chose me dit que tu ne dois pas avoir besoin de l'affichage distant autrement tu ne penserais pas ça..
Tu ne peux pas appeler Wayland X12 pour la même raison que tu ne peux pas appeler (Quartz + VNC) X12: même si l'incrémentation du numéro de version signifie "incompatible" il faut quand même que:
1- cette incompatibilité soit limitée
2- le nouveau système reste dans l'esprit X: l'esprit initial était de faire un système avec la transparence réseau donc efficace en utilisation de bande passante, d'abord tout le rendu coté serveur, puis quand ça a posé des problèmes on est passé a un équilibre entre le client et le serveur avec XRender (les fontes sont rendues sur le client et cachées sur le serveur par exemple Glyphset), dommage cependant que la possibilité de compression des bitmap pour le fond ait été ajouter dans NX mais pas dans X..
Le système de Wayland d'avoir l'application qui rend toute la fenêtre et tant pis pour la bande passante utilisée me parait totalement différent de l'esprit X: si tu veux vraiment résoudre les problèmes d'X et avoir à la fois un système efficace en local et en distant tu n'obtiens pas Wayland, tu obtiens un mélange X(XRender), de NX (compression des pixmap, diminution du nombre de RTT) et de Wayland (passage de buffer dans la mémoire du GPU entre le client et le serveur).
Par contre si tu veux résoudre les problèmes de l'embarqué (rien à faire de la transparence réseau, mais il faut que ce soit efficace en local) alors là oui, tu obtiens Wayland.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Hum si: la gestion des fenêtres se fait par le processus compositeur (Weston) sur Wayland.
Sur X la gestion des fenêtres se fait par un processus séparé.
Et par défaut les 2 ne font pas tout a la même chose car sur Wayland par défaut c'est le client qui dessine ses décorations de fenêtres.
[^] # Re: Un peu d'info
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Note que l'article sur The H et l'article ici reprennent tout les deux les mêmes "explications" fournies par le projet Wayland/par Kristian.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
En local ça m'étonnerait, en distant: c'est possible.
[^] # Re: Comment X penalise Firefox / Linux
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Pour (1) pourquoi y a t'il besoin de convertir les pixmap et les textures OpenGL? C'est une question de format?
Pour (2), l'intérêt d'XRender c'est que ça permet d'utiliser efficacement le réseau, mais effectivement en local c'est probablement moins efficace que le modèle a la Wayland.
Pour (3), si je me souviens bien X était une "amélioration" de W qui lui était synchrone: je ne vois pas trop comment avoir des erreurs synchrone sur un protocole asynchrone, ni comment un protocole synchrone pourrait être efficace en distant.
Pour (4), ça parait être principalement un problème OpenGL donc il me semble que tu peut avoir exactement le même problème avec Wayland.
[^] # Re: Mauvaise foi
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Hum, ce qu'il dit me parait être un grand raccourci: regardes les GlyphSet d'XRender, X permet au toolkit d'envoyer du texte en distant de manière assez efficace (une fois que tu as transmis une glyphe tu peux la réutiliser..) et une recherche Qt GlyphSet m'a donné quelques résultats: donc apparemment ils utilisent ce mécanisme).
Pour le texte regarde plus haut, pour le fond effectivement envoyer les pixmap non compressé c'est pas terrible, mais c'est pour ça que NX compresse les pixmap il me semble(*), avec Wayland un buffer contiendrait à la fois le fond et le texte, donc si on essayait de compresser le buffer ce serait bien pire!
Pour le cas local, je ne vois pas pourquoi ce serait impossible d'ajouter a X des références vers de la mémoire du GPU de la même manière que la "shared memory" lui a été ajouté..
Et bien si les justifications de Kristian étaient plus convaincantes ça aiderait!
Quand LibreOffice a du code mort, ils le virent, ils ne changent pas totalement la conception..
*: personne n'a dit qu'X était idéal pour le réseau, NeWS ou Berlin/Fresco étaient meilleurs coté réseau (paix à leurs âmes), mais vu que Wayland sera pire de ce coté là, ce n'est pas un argument pour Wayland, c'est un argument pour intégrer NX à X.
[^] # Re: Fenêtre
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à -1.
Toutafé.
[^] # Re: Migrations libres
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
C'est le cas? Coté doc je n'ai rien trouvé..
Sinon pour répondre à ta question: avec le Linux 'standard' non, mais qui t’empêche de faire ton propre patch?
C'est du travail bien sûr, mais créer/porter tout les autres drivers à mon avis ça réprésente bien plus de travail..
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 6.
Bien supporté par XRender (qui dans X). Et note que l'approche 'bitmap' peut utiliser bien moins de bande passante quand tu envoie d'un coté le texte (GlyphSet), de l'autres les "images de de fond" plutôt qu'un buffer qui contient une image de la fenetre (va essayer de compresser ça sans induire de retard!).
Bof, c'est une justification foireuse: du même constat tu pourrait dire, faisons X12 qui vire tout le code mort/inutilisé (draw stippled line) mais qui garde XRender.
Pour les toolkits, ça changerait même moins de chose!
Je le répète la vrai justification de Wayland c'est d'avoir un rendu local plus performant pour l'embarqué.
[^] # Re: remote display
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 4.
Oui.. Note qu'à l'heure actuelle Wayland ne transmet que des fenêtres complètes entre le client et le serveur donc ça ne sera pas très efficace, mais en LAN ça doit passer..
Oups, tu as raison j'avais oublié ça, un comble puisque c'est comme ça que Wayland a bootstrappé!
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Ce n'est pas le seul: il faudrait aussi ajouter un mode ou les clients puissent envoyer une référence vers un buffer dans la mémoire du GPU (et non plus seulement en mémoire principale partagée).
Techniquement tout est possible, c'est au niveau de la main d'oeuvre/volonté que ça pèche.
Pour X en rien, qui te dis que les développeurs de Wayland veulent résoudre les problèmes d'X??
Ils veulent résoudre leur problème qui est de faire un système d'affichage efficace en local pour l'embarqué.
Hein? Personne n'a dis ça, tu as lu de travers. L'article dit juste qu'X a plein de fonctionnalité non-utilisée car obsolète, ce qui complique la maintenance du serveur X.
[^] # Re: Pourquoi?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Augmenter les performances en local.
Ce projet vient de l'embarqué: ça répond très bien à leurs besoins.
Pff, tu pourrais faire un peu plus attention en lisant les descriptions..
Wayland c'est une interface, une API (comme X), qui sera accessible a partir de librairie qu'utiliseront les clients et les serveurs (Weston et autres).
Dans le système Wayland, il y aura un seul processus serveur qui fait compositeur et gestionnaire de fenêtre.
En théorie oui, mais en pratique les devs Qt/KDE ont bossé pour que tu puisse utiliser une appli Qt/KDE sous GNOME sans que tu voie trop la différence (et vice versa), donc je pense qu'il y aura la même chose avec Wayland.
Pour la compatibilité et la transparence réseau "efficace" oui. Si tu n'utilise pas ça non.
Probablement Ubuntu oui: ils visent l'embarqué.
Hum, ta boule de crystal est plantée, une fois que l'application a rendu son image dans un buffer c'est trop tard pour X! Enfin techniquement tu peux, tu as juste des performances réseau pourrie..
[^] # Re: Vous pouvez m'éclairer ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
OK pour une solution de repli, mais il faut espérer que peu d'utilisateurs seront dans ce cas car il se peut que leur système soit alors moins performant qu'avec X!
[^] # Re: Fenêtre
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 4.
Je l'ai lu moi et il me semble que ça n'existe pas non.
Il y aura juste une API pour que le client indique ou se trouve le bouton pour fermer la fenêtre afin qu'un serveur puisse tuer un client non-réactif, c'est tout.
[^] # Re: Migrations libres
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 6.
Un desktop Haiku restera certainement beaucoup plus réactif qu'un desktop Linux (même avec Wayand), mais Haiku a fait l'énorme erreur d'utiliser un noyau (NewOS) très peu utilisé plutôt que Linux ou FreeBSD alors non merci: à cause de ce choix, il est quasiment sûr qu'Haiku n'atteindra jamais la "masse critique".
Les développeurs de Wayland n'ont pas fait cette erreur eux..
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
Oui, c'est le comportement par défaut.
Non: aucune solution n'est idéale, c'est un compromis.
L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.
Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
La synchro se fera par du EWMH j'imagine.
Il y a des raisons de ne pas aimer Wayland:
-non portabilité actuelle sur les *BSD
-un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.
[^] # Re: Fenêtre
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Pas forcément si simple: comment Kwin connaîtrait les décorations que tu as dessiné si le client envoi juste un buffer?
Pour moi, le plus simple est qu'il y ait une extension du serveur qui dise "ne dessine pas les décorations de la fenêtre".
[^] # Re: Fenêtre
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Bah, ça vraiment c'est le problème le plus mineur et le plus simple a résoudre..
Il existe déjà sous X pour tout ce qui n'est pas la décoration de la fenêtre d'ailleurs: en pratique ça n'est pas un problème car les toolkits sont assez souple et configuré par les distributions pour que le "look n'feel" soit homogène (enfin à peu près).
[^] # Re: Vous pouvez m'éclairer ?
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Non! Pour que Wayland soit utile, il faut utiliser une API qui permette de partage la mémoire du GPU entre le client et le compositeur (GEM il me semble), autrement tu te retrouves avec le cas suivant: le client utilise le GPU pour rendre son application dans un buffer du GPU puis il faut lire le buffer du GPU pour le mettre en mémoire principale (lent) et ensuite le recopier de nouveau sur le GPU pour le "composer" et l'afficher: autant utiliser X car ça tue les performances..
Sinon d'accord avec toi, il n'y a pas d'API entre le serveur d'affichage et le compositeur: le serveur d'affichage est le compositeur.
Dommage d'ailleurs que ça n'ai pas été fait pour X: rien dans X n'impose d'avoir le serveur d'affichage et le compositeur séparé, certes c'est plus modulaire mais à mon avis dans ce cas là ce n'est pas une bonne chose.
[^] # Re: Wayland / X
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 4.
Euh non, ça permettra aux applications GTK, Qt (etc) de tourner, mais pour les applications pure X (il y en a peu OK) il faut installer un serveur X/client Wayland pour la compatibilité: pas de problème ça existe déjà.
Pour ta seconde question, il n'y a pas actuellement l'équivalent de KMS sur les *BSD (pas sûr pour les autres API), mais je pense que ça viendra: ne serait-ce que pour pouvoir éviter d'avoir X en tant que root c'est intéressant.
[^] # Re: remote display
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 9.
La réponse est compliquée:
1) en LAN, il y a plusieurs solutions:
a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.
b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".
c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).
2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
Mais pour les autres cas, la bande passante utilisée sera trop élevée.
Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..