reno a écrit 3881 commentaires

Ca ne changerait donc pas vraiment sous 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.

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.

En local ça m'étonnerait, en distant: c'est possible.

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.

Toutafé.

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..

On est maintenant passé à une approche 'bitmap'.

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.

pour Wayland, c'est quel intérêt?

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.

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".

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).

(OpenGL, shared memory, ou autre...)

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.

Et le remote display, il disparait avec wayland ?

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"..

Solaris et FreeBSD l'a intégré aussi.
Intégrer un FS aussi compliqué que ZFS ne doit pas être simple mais je pensais au fait que ZFS a sa propre gestion des volumes et de plein de choses et la duplication ne serait pas forcément accepté..

Apparemment tes char sont signés donc toute valeur supérieur a 0x7f est considérée comme négative, et il doit y avoir une conversion char --> int quelque part dans ton programme.

p'is bon, y'en a un qu'est prêt, l'autre qu'est pas mûr...

Oui enfin sauf qu'ils ne sont pas intégrer dans le même OS!
Même s'ils changeaient la license de ZFS aujourd'hui, l'intégrer dans Linux ne serait pas si simple..

Il y a quand même du travail fait sur ce sujet:
http://www.theregister.co.uk/2011/12/07/nvme_scsi_express/

Ayant un problème similaire sur Windows XP, je me permet de conclure que le syndrome de "la souris qui bouge toute seule" peut avoir des causes multiples..