Voici la traduction (avec quelques libertés) d’un article paru sur Phoronix sous licence CC-By-3.0.
Introduction
Un aperçu des problèmes, corrections et fonctionnalités liés à X et Wayland. Écrit par Eric Griffith, avec l’aide de Daniel Stone (développeur X.Org et Wayland). Corrigé et validé par Daniel Stone.
Cet article a été rédigé par un contributeur volontaire de Phoronix en se basant sur des présentations de Keith Packard, David Airlie, Daniel Stone, Kristian Høgsberg ; ainsi que les wikis de X11, X12, Wayland et Freedesktop.org, et des questions‐réponses directes avec les développeurs.
Depuis sa première annonce, il y a plusieurs années, il y a eu beaucoup d’informations, de désinformation, de fausses idées, et du pur FUD à propos de Wayland, le remplaçant de nouvelle génération du système de fenêtrage X. Cette présentation a pour but de clarifier la situation de Wayland.
L’article est très inspiré par la récente conférence technique donnée par Daniel Stone à la conférence Linux australienne linux.conf.au de 2013, à laquelle il constitue une excellente introduction. L’anglais de Daniel Stone est facilement accessible, sa conférence complète excellemment l’article, et ses diapos sont un modèle d’humour. Allez la voir, c’est hilarant, très instructif et puis il est une des rares personnes qui connaît vraiment le sujet.
Elle est disponible au format Ogg vidéo ou sur un site de partage de vidéos bien connu.
Sommaire
-
Les lacunes de X
- Les premières années
- Les 4 mousquetaires des entrées
- La politique ?
- Bibendum
- La composition et la cohérence des fenêtres
- Les polices de caractères
- La gestion des états (ou plutôt son absence)
- L’arborescence des fenêtres
- Le compteur de pixels
- Tout est fenêtre
- Alors pourquoi pas X12, comme suite au vénérable X11 ?
- Les corrections de Wayland
- Quelques idées reçues sur X et Wayland
- Quelques avantages génériques de Wayland
Les lacunes de X
Personnellement, je pense que les bénéfices et le but de Wayland sont mieux compris quand ils sont comparés aux erreurs et lacunes de X. Donc, commençons…
Les premières années
Nous avons passé les 10 dernières années ou presque à « corriger » le serveur X en empilant de plus en plus d’extensions et de greffons. Le problème est que X n’a qu’un système de gestion de versions très limité pour ses extensions.
- La gestion de versions est gérée par client, et non par lien. Donc, si votre application prend en charge une version d’une extension donnée, mais que votre bibliothèque graphique en gère une autre, vous ne pouvez pas prévoir quelle version de l’extension vous allez obtenir.
- Un exemple théorique : Rekonq gère XInput 2.2, KDELibs prend en charge XInput 2.0 et le greffon Flash ne gère que X11 Core… Tous ceux‐là vont se battre pour décider quelle version du système d’entrée Rekonq prend en charge et à la fin, vous aurez une version qui s’occupera de tout le monde… Qui ne sera peut‐être pas la version que tout le monde prend en charge.
- Si vous avez de la chance, vous recevrez la plus basse version prise en charge et tout fonctionnera correctement. Si vous n’avez pas de chance, vous recevrez la plus haute version prise en charge et vous échangerez des données inutiles qui conduiront potentiellement à des erreurs entre le client et le serveur X.
Les 4 mousquetaires des entrées
X a quatre sous‐systèmes d’entrée : Core X11, XInput 1.0, XInput 2.0 et XInput 2.2. XInput 1.0 a été éliminé, mais les trois restants sont plus inter‐dépendants qu’indépendants. Comme Daniel Stone l’a dit : « Il y a à peu près 3 personnes qui comprennent VRAIMENT comment les sous‐systèmes d’entrée tiennent ensemble… Et j’aurais vraiment souhaité ne pas être l’un d’eux. »
La politique ?
Il y a de nombreuses années, quelqu’un a eu une idée : « technique, et non pas politique ». Qu’est‐ce que ça veut dire ? Cela veut dire que X a sa propre API de dessin, il est sa propre bibliothèque graphique, comme GTK+ ou Qt. Il définit les éléments de bas niveau, tels que les lignes, les lignes larges, les arcs, les cercles, les polices rudimentaires, et autres « blocs de construction » qui sont complètement inutiles pris séparément. Note de Daniel : « Histoire drôle : les lignes larges doivent respecter au pixel près la spécification, mais cette dernière les définit moches. »
Bibendum
Le serveur X est énorme et stupide. Avant que nous (la communauté) commencions à lui retirer des morceaux et travailler dessus, c’était presque un système d’exploitation complet.
- Vous ne me croyez pas ? X avait son propre serveur d’impression. Il a été supprimé après que quelqu’un a ajouté la prise en charge de Xprint à glxgears.
- C’était un interpréteur binaire pour ELF, COFF et a.out.
La composition et la cohérence des fenêtres
Composition et cohérence des fenêtres. Les développeurs ont appris à X la composition à travers l’extension Composite. Pour les choses simples, comme le bureau, la composition OpenGL est utilisable. Si vous voulez une couche utilisant l’accélération matérielle (comme la vidéo), cela devient un désastre complet.
Cohérence des médias. Qu’est‐ce que c’est ? En termes simples… Votre fenêtre de navigateur ? C’est une fenêtre. Votre lecteur Flash sur YouTube ? Le lecteur Flash lui‐même, affichant la vidéo, est une sous‐fenêtre. Qu’est‐ce qui garde ces deux fenêtres synchronisées ? Absolument rien. Les événements sont gérés séparément et actuellement vous priez pour qu’ils ne soient pas traités à des moments trop éloignés. Ce qui explique pourquoi quand vous faites défiler une page YouTube, ou un autre site où une vidéo est jouée, parfois tout se sépare en morceaux.
Les polices de caractères
Les développeurs ont essayé d’apprendre au serveur X à utiliser les polices grâce à l’extension STSF. L’idée était de stocker les polices du côté du serveur, et de donner aux clients suffisamment d’informations pour qu’ils puissent générer l’agencement de la police tout seuls. Les informations nécessaires pour ça se sont révélées plus importantes que la taille de la police. Il a donc été décidé d’envoyer la police directement au client et de laisser ce dernier se débrouiller avec.
La gestion des états (ou plutôt son absence)
Absence d’états… En d’autres mots : X ne se souvient de rien !
- « Génère‐moi un fichier de configuration… En fait, utilise celui‐ci. » Pourquoi ? Finalement corrigé en faisant en sorte que le serveur X n’utilise qu’un seul fichier de configuration pour les exceptions, et qu’il connaisse et intègre des options par défaut sensées, ainsi que de l’auto‐détection.
- Qui n’a jamais eu de problèmes avec le multi‐écran sous Linux ? Ou alors, qui n’a jamais vu la configuration de tous ses moniteurs disparaître après un redémarrage ? C’est de la faute de X, sauf si vous sauvegardez votre configuration dans
/etc/X11/xorg.conf.d/50-monitors.conf, et alors il s’en souvient… Mais vous avez probablement dû écrire ça à la main. - Avec un peu d’optimisme, cela sera corrigé par la création de
libkscreen, un « enrobage logiciel » — wrapper — pourxrandrse souvenant de l’emplacement de chaque écran grâce à son EDID qui est unique. - Depuis longtemps, et c’est peut‐être encore le cas, quand vous branchez un moniteur supplémentaire alors que l’écran primaire a une composition, il se peut qu’elle n’apparaisse pas sur celui nouvellement ajouté. Cela peut avoir été corrigé par RandR 1.4, mais l’auteur ne peut clairement affirmer si ce problème est résolu.
L’arborescence des fenêtres
L’arbre des fenêtres est un bazar complet. Avec X, tous les champs de saisie et boîtes de texte sont une fenêtre ayant comme parent la fenêtre contenante. C’est pourquoi personne ne comprend la fonction qui valide l’arbre des fenêtres. Les vraies (par exemple, pas Core X11) boîtes à outils graphiques — toolkits — ont jeté ce fonctionnement par la fenêtre depuis longtemps. Sans jeu de mots.
Le compteur de pixels
C’est un détail, mais aussi un reproche recevable… Avec X11, le compteur total de pixels est de 15 bits. En conséquence, le nombre maximal de pixels autorisé, tous affichages confondus, est de 32 768. À 100 ppp, cela fait un affichage de 8,3 mètres. Super… En comparaison, en revanche, Windows XP a 96 ppp. Mon téléphone a 320 ppp. Ajoutez de plus grandes définitions et des moniteurs multiples, et les choses deviennent vite hasardeuses.
Tout est fenêtre
Tout est fenêtre dans X. Il n’y a pas de différents types de fenêtre, juste « une fenêtre ».
- Votre économiseur d’écran ? C’est une fenêtre qui a dit à X :
- mets‐moi au-dessus de toutes les autres fenêtres, tout le temps ;
- mets‐moi en plein écran ;
- donne‐moi toutes les entrées utilisateur — focus.
- Une fenêtre surgissante — popup — ? C’est une fenêtre qui a dit à X :
- Mets‐moi ici ;
- Donne‐moi toutes les entrées utilisateur — focus.
- Problème ? Pour commencer : les fenêtres se contredisent. L’économiseur d’écran ne s’activera pas tant qu’il y aura une fenêtre surgissante à l’écran, car elles entrent en conflit.
- Votre économiseur‐verrouilleur d’écran n’a probablement pas fait les liens avec toutes les bibliothèques pour gérer les touches multimédia… Le problème vient de la situation suivante : vous êtes en train de travailler chez vous, avec de la musique. Vous fermez le capot de votre portable pour le mettre en veille. Après cette opération, l’écran de verrouillage est la fenêtre active. Quand l’ordinateur est réactivé, la musique reprend aussitôt sur les haut‐parleurs, et il est plus facile pour vous de refermer le capot que de taper le mot de passe, ouvrir le lecteur multimédia pour le mettre en pause ou mettre l’ordinateur en muet.
- Les développeurs ont essayé de corriger ce problème. Ils ont défini une extension, avec une théorie toute prête, mais quand est venu le moment de l’implémenter, ils ont constaté qu’elle briserait le fondement du modèle de X. C’est un problème depuis 26 ans, et ça le restera. Appréciez.
Alors pourquoi pas X12, comme suite au vénérable X11 ?
« Mais, Eric, si X11 est si mauvais, pourquoi ne pas faire X12, plutôt que de définir un nouveau protocole ? » Ils l’ont fait, techniquement, du moins : http://www.x.org/wiki/Development/X12.
Un des principaux problèmes rencontrés en conservant l’appellation X est que quiconque s’occupant de X va vouloir avoir son mot à dire sur la version suivante. En l’appelant Wayland, ils (les développeurs) évitent ce problème. Personne ne s’en préoccupe. Cela peut être un projet différent, ils peuvent faire ce qu’ils veulent avec leur futur serveur d’affichage, les gens se souciant de X peuvent faire X12 de leur côté.
Les corrections de Wayland
Les corrections sont traitées dans l’ordre des « problèmes » de X11 listés ci‐dessus.
Tout le protocole est versionné
Tout le protocole est versionné. Chaque auditeur — listener — reçoit exactement la version qu’il prend en charge, pas plus. Plus d’aléatoire.
La gestion des entrées
Le système d’entrées de Wayland ressemble beaucoup à XInput 2.2, moins toutes les cochonneries d’héritage et moins la relation maître‐esclave entre les entrées. Tout le monde reçoit un clavier virtuel, une souris virtuelle et une interface de tablette non virtuelle. Le cauchemar appelé multitouch (multi‐tactile) sera enfin réglé. Note de Daniel : « En tant qu’un des auteurs du multitouch, je me sens bien qualifié pour dire que c’est de la merde. »
Absence d’API de « dessin »
Wayland n’a aucune API de dessin, évitant ainsi de s’emmêler les pinceaux. Wayland veut recevoir des tampons remplis de pixels de la part des clients et, à part les vérifications de sécurité pour éviter qu’un client n’agisse sur la mémoire tampon — buffer — d’un autre, il se contrefiche de savoir comment les pixels sont arrivés là. Les clients contrôlent quels pixels sont dans quelles mémoires tampon, et ainsi ce qui sera affiché sera exactement ce que le client voulait.
Minimalisme
Wayland est minimal. Il n’y a pas de pseudo système d’exploitation surchargé contrôlant la carte graphique. Il n’y a pas une API vieille de 26 ans qui empêche les évolutions. Les clients se chargent du travail, ce qui est une bonne chose parce que les clients n’ont pas à maintenir une rétro‐compatibilité extrême. Qt5 a laissé tomber les classes de compatibilité avec Qt3, X doit toujours maintenir des choses écrites il y a 26 ans. Et les choses d’il y a 26 ans se mettent en travers du chemin des corrections de problèmes actuels.
Note de Daniel : « Wayland est aussi non bloquant, ce qui fait que votre bureau entier n’arrêtera pas son rendu uniquement parce qu’un client est en train de faire une opération longue. Seul ce client arrêtera son rendu. »
Composition
La composition est requise sous Wayland. Ça ne veut pas dire que tout a besoin d’effets 3D ou de fenêtres molles. La composition veut dire que tout se fait sans scintillement, sans mise en pièce. La devise de Wayland est « chaque image est parfaite ». Chaque pixel est exactement ce qu’il doit être où il doit être, et là quand il doit y être — tel que demandé par le client.
Les polices de caractères
Les logiciels clients s’occupent des polices de caractères, comme ils le font déjà, en fait.
Gestion du multi‐écran
Le multi‐écran est un problème du client. Même chose en ce qui concerne les cartes graphiques multiples (Optimus). Wayland désire uniquement des mémoires tampons remplies avec des pixels, et qu’on lui dise où les afficher. Il ne se tracasse pas de comment ils sont apparus là.
Plusieurs types de fenêtres
À l’inverse de X, dans lequel tout était fenêtre, Wayland gère deux types de fenêtres différents. Les fenêtres de niveau supérieur, qui sont essentiellement des conteneurs de multiples tampons, et les fenêtres de sous‐niveau, principalement pour les lecteurs vidéo.
Néanmoins, tout cela est maintenu cohérent, à l’opposé de X, en évitant les défauts de couleur et autres artefacts générés lorsque vous descendez sur les commentaires d’une vidéo YouTube pendant que celle‐ci est en cours de visionnage.
Un autre système de positionnement de pixel
Wayland ne gère pas les coordonnées globales, du moins, pas publiquement. Il gère des coordonnées relatives pour les surfaces. Le compteur de coordonnées de Wayland fait une taille de 31 bits, cela veut dire que chaque surface (c.‐à‐d. fenêtre) peut avoir une taille de 2 147 483 648 pixels.
Une précaution de sécurité
Pour des raisons de sécurité, votre écran de veille et de verrouillage fait partie du compositeur. Cela a pour effet bénéfique que votre compositeur (par exemple, KWin) comprend les touches multimédia, donc, vous pouvez mettre votre ordinateur en sourdine, même quand votre écran est verrouillé.
Quelques idées reçues sur X et Wayland
X respecte la philosophie UNIX
La philosophie Unix dit qu’il faut faire une seule chose et la faire bien. X gérait l’impression, les mémoires tampon et les polices, il avait sa propre bibliothèque graphique, il était un interpréteur binaire, parmi bien d’autres choses. Quelle est cette chose unique que X faisait et qu’il faisait bien ?
X supporte la transparence réseau
Faux. Ce n’est pas le cas. Core X et DRI-1 supportaient la transparence réseau. Plus personne ne les utilise. La mémoire partagée, DRI-2 et DRI-3000 ne supportent pas la transparence réseau, ils ne fonctionnent pas sur le réseau. De nos jours, X se résume à être un VNC synchrone et appauvri. S’il avait été fait différemment, c’est‐à‐dire asynchrone, alors nous pourrions peut‐être le faire fonctionner. Mais ça n’est pas le cas. Xlib est synchrone (et le mouvement vers XCB est lent), ce qui fait du réseautage un cauchemar.
Les développeurs de Wayland recréent X11 car ils ne l’ont pas compris
Faux. La plupart des développeurs de Wayland sont des ex‐développeurs de X11. Ils savent à quel point il est horrible. Ils savent où sont ses faiblesses. Ils veulent faire mieux que X11.
Wayland nécessite la 3D
Faux. Il nécessite la composition, mais ça n’est pas forcément de la 3D. Rien dans Wayland ne nécessite la 3D, il y a même un rendu logiciel utilisant la bibliothèque de manipulation d’images Pixman.
Wayland ne fait pas de session à distance
Faux. Wayland devrait être meilleur que X pour l’affichage à distance, cela étant en partie dû à sa nature asynchrone par conception. L’affichage distant de Wayland ressemblera probablement à une version plus performante de VNC. Un prototype existe déjà, et cela sans réfléchir sérieusement à la manière de l’améliorer. Nous pourrions sûrement faire mieux si nous avions essayé.
Wayland casse la gestion des bureaux de tout le monde
Toujours faux. Une fois que XWayland sera terminé et intégré, nous devrions avoir plus ou moins une compatibilité ascendante parfaite, parce que chaque application X reçoit son propre mini‐serveur X avec lequel elle peut dialoguer. Il y a un problème connu qui est lié aux transformations de fenêtres, parce que chaque application pense qu’elle est dans le coin supérieur droit de l’écran (youpi les coordonnées globales) et que chaque mini‐serveur X est verrouillé à la taille de la fenêtre de son client.
Quelques avantages génériques de Wayland
Chaque image est parfaite
Le but principal de Wayland est que quelle que soit la charge du système, quoi qu’il se passe, il ne doit pas y avoir de scintillements, de déchirures ou de flashs. Chaque image est présentée dans l’ordre correct et approprié (sauter des images est accepté, mais vous n’aurez pas l’image 199, suivie de la 205, suivie de la 200, parce qu’elles ont toutes été envoyées à peu près au même moment et que le serveur les a prises au hasard). Wayland sait dans quel ordre elles viennent, dans quel ordre il faut les afficher, et quand elles ont été affichées, car tout est associé à un horodatage.
Wayland est minimal
Nous avons appris à la dure ce qui arrive quand vous avez quelque chose qui fait beaucoup de choses et qui doit aussi maintenir la compatibilité ascendante —— nous nous mordons toujours les doigts pour des erreurs commises il y a 26 ans dans X. Laissons les clients gérer les choses, ils peuvent changer, ils peuvent casser autant de choses qu’ils veulent parce que ce sont eux qui doivent gérer les retombées de la casse. Nous aidons à rendre Wayland résistant au futur en réduisant la surface d’attaque des erreurs.
Des back‐ends spécifiques pour chaque matériel
Je suis sûr que certains ont vu que le Raspberry Pi a reçu un back‐end spécifique pour Wayland, et comme cela a permis de mieux tirer parti du matériel. Ce ne sera pas nécessaire à chaque fois, la plupart des matériels ne nécessiteront pas un back‐end spécifique… Mais il est sûr que c’est sympa que ce soit disponible. Cela veut dire qu’on a la liberté, on a le choix de faire des adaptations spécifiques si on le désire. Ou, si on réalise en cours de route que le back‐end principal a des défauts de conception, on peut le changer par un autre qui n’en a pas.
~Fin~
Aller plus loin
- L’article original sur Phoronix : Facts About X vs. Wayland (586 clics)
- Pourquoi Wayland veut remplacer X (743 clics)
- X.Org est mort, vive Wayland ! (354 clics)
- X.Org est mort, vive Wayland ! (2) (191 clics)
# typo
Posté par Sandro Cazzaniga (site web personnel) . Évalué à 2.
son propre, plutôt ?
[^] # Re: typo
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 10.
Comme l'article en sujet est partial, j'ai noté les problèmes suivants que je liste:
1) L'article dit "X a 4 sous-systèmes d'entrée", sauf qu'une version a été éliminée donc un article moins partial dirait "X a 3 sous-systèmes d'entrée", c'est déjà bien trop pas la peine d'en rajouter.
2) X a été presque un OS, c'est vrai certes mais c'est une critique de l'implémentation pas du protocole ce que cet article mélange allègrement: la preuve ce n'est plus vrai et le protocole n'a pas changé!
3) La gestion des fontes, l'article "oublie" de parler de l'extension XRender et de son caches des glyphes, un mécanisme efficace pour avoir des fontes dessinées par le client mais permettant l'affichage de texte en distant en envoyant peu de donnée (beaucoup moins que l'envoi de gros buffers comme Wayland), évidemment ça ne rentre pas dans le parti-pris de l'article donc c'est zappé.
4) Wayland n'a pas d'API de dessin, certes c'est plus simple mais ça peu aussi être moins efficace en distant: soit on envoi des gros buffers (très consommateurs en bande passante plus qu'un film puisque non compressé!), soit on les compresse mais la compression ça prend du temps donc on ajoute encore de la latence (compression et décompression), dommage la latence est le problème numéro 1 en distant!
5) "La devise de Wayland est « Chaque image est parfaite »", bon c'est vrai dans la majorité des cas, mais on peu trouver des cas (rare heureusement) où l'architecture de Wayland va créer un problème: certains écrans bizarre ont des sous-pixels qui sont différents suivant l'emplacement (pas invariant par translation) et Wayland n'indique pas aux programmes où leurs fenêtres vont être affichées du coup les programmes ne peuvent pas exploiter correctement les sous-pixels dans ce cas là.
Quoi c'est tiré par les cheveux?
Bah l'article aussi!
La fin étant spécialement grandiose:
6) Il dit qu'X n'est pas indépendant du réseau car il a des extensions qui ne sont pas indépendantes du réseau, si ça n'est de la mauvaise foi..
7) L'article décris X comme étant synchrone alors qu'XCB est asynchrone, mettre sur le dos d'X la lenteur des toolkits a passé d'XLib à XCB..
8) Pour ce qui est d'être meilleur qu'X a distance, euh ça dépend, pour afficher quoi?
Pas pour afficher du texte à distance en tout cas, cf (3)!
Au cas où certains se poseraient la question: je ne suis pas anti-Wayland, je trouve juste dommage que le minimalisme à tout prix de Wayland va fort probablement réduire les performances pour l'affichage de texte en distant et j'attends de voir comment va marcher une application Gnome/Wayland avec un compositeur KDE/Wayland, à terme je pense que ça fonctionnera bien, mais sur le cours terme l'intégration risque d'être "intéressante"..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 10.
Si ces extensions sont utilisées par les toolkit en local, ça veut dire qu'il faut au final faire 2 backend, un qui utilise des extensions et un autre qui fonctionne sans. Dans ce cas là, autant créer un protocole à par dédier au réseau qui soit vraiment performant pour le réseau.
Est-ce vraiment un point important de l'affichage distant ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 5.
Difficile à dire pour de bon tant que Wayland n'a pas un affichage distant fonctionnel ce qui permettrait de faire des vrais comparaisons, mais je pense que oui: avoir un mécanisme pour envoyer le texte séparément du fond permettrait de bien mieux traiter(compresser) chacun des 2 séparément (compression normal pour le fond et cache "à la XRender" pour les fontes) plutôt qu'une fois que tout a été mis dans un même buffer.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par William Steve Applegate (site web personnel) . Évalué à 9. Dernière modification le 14 juin 2013 à 15:35.
Sauf que… ben, il en a déjà un, en fait. Alors, pour parer aux critiques qui vont inévitablement pleuvoir :
Donc, pour moi, l'argument du « WL sapu sanapas d'affichage distant » est caduc. Passons à autre chose.
edit : je ne me rappelais plus, mais il y a apparemment aussi un back-end SPICE. Vu que la rapidité de SPICE fait souvent l'objet d'éloges, on peut sans doute décréter le problème résolu.
Envoyé depuis mon PDP 11/70
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par lolop (site web personnel) . Évalué à 2.
Pour l'export juste d'une fenêtre d'application via RDP, voir WinConn. L'accès en plus, sur la machine distante, à un répertoire local partagé, est très pratique.
http://stanev.org/winconn/
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Oui, je sais que Windows ≥ (Seven|Server 2008) prend en charge cette fonction (en revanche, je ne connaissais pas de client Linux compatible jusqu'ici. Merci pour le signalement !), ce que j'ignore c'est si le back-end RDP de Wayland fournit la partie serveur du truc. Je pense que non, puisque c'est apparemment le compositeur entier qui envoie sa sortie sur RDP, mais j'ai pas vraiment investigué.
Envoyé depuis mon PDP 11/70
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
En même temps, on est qu'au début. Mais, c'est vrai que ce serait bien que ce soit possible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par CHP . Évalué à 6.
Ca m'est pourtant arrivé dernièrement.
Je travaille en prod. Pour une mise en préprod, le gars qui a fait le dev n'a pas fait de vraie procédure d'install, c'est un peu la merde (non, y'a pas d'IQ. Me demandez pas pourquoi, ni où c'est, j'ai pas le droit de dire du mal de mon client), du coup il est décidé que je ferai la mise en prod en partageant mon ecran avec le dev afin qu'il puisse controler que tout se passe bien, et puisse me guider si (plutot quand) ca merdoie.
Bah dans un cas comme ca, je ne partage que la fenetre putty. Parce que sinon, si je partage toute la session, quand je vais ouvrir keypass pour chercher un mot de passe, bah lui il va le voir, et c'est vraiment pas le but.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
En fait, c'est pas du Microsoft à la base ! Ils ont racheté la technologie à CITRIX à l'époque et le tout est dérivé du T120 utilisé en visio-conférence (H323) pour le transfert des données. Contrairement au H239 actuel, le T120 permettait la prise de contrôle à distance type tableau blanc (si le H239 semble plus basique, il est aussi plus fluide pour le canal des données).
http://en.wikipedia.org/wiki/Remote_Desktop_Protocol
http://en.wikipedia.org/wiki/T.120
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
et x2go et autres avatars de nx alors ? je les préfère de très loin à RDP …
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par karteum59 . Évalué à 4.
Je ne suis pas expert du sujet, mais vu l'approche de Wayland, je m'interroge aussi sur l'envoi de commandes graphiques en vectoriel ("trace une ligne du point A au point B") plutôt que tout le buffer bitmap (plus gourmand en bande passante). X/NX/RDP ont une approche vectorielle, et je comprends que pour faire la même chose avec Wayland (qui a une approche bitmap, comme VNC) il faudrait intercepter les appels aux autres libs en amont (e.g. pour remplacer les appels OpenGL par une sorte de RPC pour que le dessin lui-même se fasse sur le client distant). Me trompe-je ?
N.B. comme on est trolldi, je peux en profiter pour dire aussi: de toute façon l'avenir est aux applications HTML5 non ? :)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 2.
Tu dis que RDP est vectoriel et donc non utilisable avec Wayland. Pourtant, il y a un backend RDP pour Wayland.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Peut être va t'on voir à terme un serveur parallèle vectoriel ? Paraview a un mode distant, Visit a aussi un mode distant. Tu peux même séparer les choses en trois, un serveur de données, un serveur de rendus et l'affichage client. C'est du spécialisé mais sur des gros maillages, cela marche bien.
Il y a aussi l'approche VirtualGL. J'ai pas suivis depuis longtemps celui-ci…
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 3.
Et au WebCL surtout ;-)
Sinon, étant donné qu'en 2013 la moindre puce ARM à 50 euros intègre un chipset graphique capable d'encoder en H264 en temps réel en 1080px30 fps, la pertinence d'envoyer du vectoriel au client se pose.
De ce point de vue je trouve l'approche de Wayland - que l'on peut résumer en "ce n'est pas notre objectif et pas notre problème" - tout à fait pertinente.
Xnest puis Nx étaient quand même de sacrées usines à gaz - et je défie quiconque d'en expliquer le fonctionnement simplement.
L'affichage local ou distant c'est le boulot de la carte graphique. D'où l'importance absolue de disposer de drivers libres.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 3.
Sauf que tu peux déjà acheté un moniteur avec une résolution supérieure..
Et que le 4k va bientôt arriver.
En plus le H264 c'est une compression avec perte pas terrible pour afficher du texte!
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 1.
Le H.264 peut aussi compresser sans perte, mais dans ce cas c'est beaucoup trop lourd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Et c'est pour ça que d'un point "accès à distance" envoyer les commandes de dessin et non pas le buffer a de l'intérêt..
Ceci dit, un écran d'ordinateur ce n'est pas une caméra donc une compression spécifique (comme celle prototypée par Kristian Høgsberg) pourrait être supérieure après ça ajoute toujours de la latence..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 2.
Sinon il y a le VP8 qui est extrêmement efficace pour tous les objets/fonds fixes ( je me demande même s'il les compresse… ).
Traiter séparément le texte les images et la vidéo serait techiquement optimal, mais créerait selon moi une complexité abominable du côté du serveur graphique et des drivers : texte envoyé en vectoriel, images compressées par le CPU, vidéo compressé par le GPU, le serveur graphique qui se charge d'assembler tout ça en gérant les synchronisations avant de l'envoyer à la carte réseau… il faut être masochiste pour programmer ça °_° ( ou avoir programmé X avant, ce qui revient à peu près au même ;-) )
Compter sur les progrès incessants des chipsets graphiques en terme de performances et celles des encodeurs vidéos (H265/VP9) qui les accompagnent me paraît nettement moins risqué.
La première fois que j'ai installé Compiz avec les drivers i915 intel sur mon portable le ventirad a gagné 5 années de vie… Je pense que les puces graphiques sont encore aujourd'hui TRES largement sous-exploitées.
D'ailleurs il me semble que les dernières puces Mali, la série des T600 intègrent l'encodage/décodage hard en VP8, ce qui fait que je suis l'évolution du driver Lima de TRES TRES près en prévision d'un achat futur ;-)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Euh pourquoi?? Tu peux faire un cache des bitmap de glyphes à la XRender.
Ça marche moins bien dans certain cas (traitement de texte qui déforme les caractères suivant leur environnement) mais ça reste très probablement bien supérieur à "je mélange tout" puis j'essaye de compresser le bazar résultant sans être très compliqué..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 1. Dernière modification le 19 juin 2013 à 14:02.
Alors le H.264 sera meilleur, vu que le VP8/WebM est un mauvais copié/collé même pas libre du H.264 Baseline.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 19 juin 2013 à 19:23.
Euh, je ne connais pas H.264 ni VP8 en détail, mais ce n'est pas parce que VP8 serait en grande partie un mauvais copié-collé d'H.264 que VP8 pourrait ne pas se distinguer et tirer son épingle du jeu sur un point anecdotique précis.
Attention, hein, je ne donne pas un avis sur VP8 ou H.264, je pointe juste que le raisonnement est faux.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 0.
Un ersatz H.264 Baseline, qui ne peut pas en bouger parce que c'est ainsi qu'il a été standardisé, je le vois mal faire mieux que le vrai H.264 Baseline (et ce n'est pas le cas). Encore moins avec tout le preprocessing que permet le x264.
Quant au H.264 Main Profile ou High Profile, c'est sans espoir pour le VP8 à moins de casser le standard.
Et de toutes façons : stop talking and show us the benchmark !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Tu n'as pas compris, je ne défends pas VP8, je dis que tu ne montre rien, tu réponds à l'invérifiable par l'invérifiable.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 0.
Je ne crois pas, regarde les sources que j'ai donné, où les standards VP8 et H.264 ont été vérifiés. Et tu peux vérifier les performances des encodeurs toi-même.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 1.
Je suis d'accord pour le benchmark.
A condition de placer les conditions de base - qui correspondent à ce que l'on veut faire :
Et on compare la charge CPU pendant la capture+encodage, la taille du fichier obtenue et la qualité de l'image sur un screenshot après pause.
Es-tu toujours aussi sûr de toi ? Le VP8 a été plutôt optimisé spécialement pour cet usage = tableau blanc partagé+fenêtre de webcam. Le H264 a été optimisé pour l'encodage de films.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 1. Dernière modification le 20 juin 2013 à 10:57.
Le H.264 est généraliste. Le x264 offre même des preset pour les sources qui ne sont pas des films.
Le VP8 d'ailleurs c'était au départ présenté comme un concurrent sérieux au H.264, il suffit de regarder le bullshit de On2 :
http://blog.lib.umn.edu/mcfa0086/discretecosine/142728.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 3.
Hein???
Avec Wayland, les applications
1) envoient les buffers entiers contenant leur fenêtre
2) ne connaissent pas leur coordonnées
donc déplacer une fenêtre peut se faire uniquement coté serveur (modulo les histoires de décoration des fenêtres qui sont gérées elle par le client), pourquoi envoyer un écran complet à un affichage distant lorsqu'on déplace une fenêtre?
C'est une implémentation possible ok mais carrément sous-optimal par rapport à ce que le protocole Wayland te permet..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 1.
On parlait de comparer VP8 et x/H264 sur un cas concret là, pas de Wayland ;-)
Effectivement Wayland devrait le permettre. Sauf que personnellement je m'en moque : toutes mes applications se lancent automatiquement en plein écran via compiz, j'en ai une par bureau virtuel et j'ai 16 bureaux virtuels. Parce que faire glisser des fenêtres à longueur de temps à la souris et les redimensionner toutes les 5 mn je ne supporte pas. Et parce que j'aime travailler ainsi, à grands coups de ctrl+droite et gauche pour passer d'une application à l'autre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 5.
Euh,tu as loupe un gros détails, wayland est base sur de la mise a jour partiel de buffer pour toutes les frames. Plutôt bien adapté pour les codecs vidéo…
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Tu réponds à qui là? Parce que si c'est à moi, je t'invite a relire ce que j'ai marqué, déplacer une fenêtre peut se faire purement coté serveur avec Weston.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 2.
Je repondais a ca:
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Et si tu lisais la suite tu verrais que ta réponse n'a pas grand sens (en tout cas à ce qu'il me semble).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pour le 4k, il faut des écrans de 2m pour voir la différence avec le 2K. J'espère surtout que le 50 ou 60 images par seconde va devenir la norme. Plus l'écran est grand et plus le manque d'image par seconde se voit.
A moins que les écrans 4K, servent à faire de la 3D passive en 1080P de façon propre.
"La première sécurité est la liberté"
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par karteum59 . Évalué à 3.
Je doute que h.264 puisse rendre quoi que ce soit d'utilisable visuellement sur des débits de type modem 56KBits/s (alors que NX s'en accomode sans problème !). Et oui, il y a des cas d'usage (il est très courant de tomber sur des connexions internet lentes ou instables dans de nombreux pays à l'étranger…)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 1.
C'est le cas pour n'importe quel codec ou presque (bon après ça dépend de la résolution et du FPS). 56 kbit/s, c'est de l'underflow (pas assez de débit pour encoder) ou vraiment pas loin.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par karteum59 . Évalué à 4.
Oui donc c'est bien ce que je disais (dans ton cas c'est juste un argument de plus !) : prétendre que du h.264 (ou h.265, ou VP8/VP9, etc.) puisse se substituer à une vraie technologie d'affichage distant (X/NX/RDP), c'est tirer un trait sur la possibilité de faire du remote desktop en bas débit/forte latence.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 2.
Mouais, a part pour le cas tres particulier du urxvt qui tourne dans X, je vois pas trop qu'elle application a distance aura un interet a faire ce genre d'usage. J'en reviens a me demander pourquoi pas juste ssh ? Qu'est-ce que tu gagnes a mettre cette complexite dans Wayland.
Bon, apres d'un point de vue theorique, c'est pas forcement si impossible a pousser dans Wayland. Il suffit d'avoir un nouveau type de surface qui serait un buffer juste de texte et que les toolkits soient capable de l'utiliser pour decoreller le texte du reste. Mais bon, je reste tres dubitatif sur l'utilisation de cette technique pour ce requirement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Batchyx . Évalué à 4.
De toute façon, il faudra gérer les deux cas. Ou bien c'est le client ou bien c'est le serveur. Moi franchement, je ne vois pas le problème à faire ça coté client en planquant ça dans des bibliothèques comme on le fait avec OpenGL.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 3.
Je suis d'accord, mais alors autant vraiment optimiser un protocole pour le réseau et non pas avoir un protocole qui passe pas trop mal par le réseau.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"Est-ce vraiment un point important de l'affichage distant ?"
Avec l'arrivé des notebook voir des tablette, il y avait un créneau à prendre : le gros pc familial que l'on utilise depuis le notebook, si on a besoin de vitesse. Mais c'est vrai qu'en plus du déport des inputs et de l'écran, il faudrait aussi gérer le déport des connecteurs USB et du son.
"La première sécurité est la liberté"
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
Je ne dis pas que l'affichage à distance n'est pas important mais je me demande si séparer le rendu du texte est vraiment un point important.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par akimatsumoto . Évalué à 2.
Pour le son il me semble que pulseaudio peut le transférer par le reseau
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
oui, mais il faudrait un outil de fédération, typiquement pour gérer les autorisations d'accès.
"La première sécurité est la liberté"
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Skydevil . Évalué à 1.
mpd ne permet pas d'envoyer le son déjà ? (Je suis un petit nouveau dans le monde de Linux, donc pataper xD )
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 4.
mpd peut envoyer la liste de lecture qu'il lit par le réseau mais il ne peut pas envoyer les son système ou d'autres applications.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Skydevil . Évalué à 1.
Merci pour l'information =)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Juke (site web personnel) . Évalué à 2.
En fait mpd peut depuis quelques version streamer directement sur http.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 19 juin 2013 à 13:56.
Mais mpd ne sert absolument pas à faire la même chose ! mpd ça sert à controler à travers le réseau une liste de lecture de fichiers multimédia, c'est d'abord un lecteur multimédia, quand bien même il pourrait aussi transporter le son qu'il génère. MPD ne sert pas du tout à transmettre le son généré par une application arbitraire (par exemple un jeu vidéo) vers la carte son.
Et puis bon, les protocoles audio HTTP ne sont pas fait pour transporter du son en temps réel, par conception. Le son en HTTP dans les protocoles utilisés par darkice/icecast/shoutcast et assimilés, c'est le client qui GET, ce qui signifie que le délai n'est pas maitrisable parce qu'on est dépendant de ce que le client réclame, et par exemple il est très fortemenent improbable que deux clients d'un même serveur aient exactement le même délai (rien n'est prévu pour que ce soit possible), en RTP c'est le serveur qui SEND, que le client écoute ou pas.
On pourrait comparer le HTTP et le RTP ainsi : HTTP c'est « envoie-moi le son quand tu peux, et si ça traîne j'attendrai, je mettrai tout ça dans un tampon car il vaut mieux prendre du retard que d'avoir une coupure parce que le tampon serait trop court », RTP c'est « tiens voilà le son maintenant tout de suite, et si t'as pas le temps de traiter ce paquet, oublie-le et passe au suivant sans retard, vite vite, t'as pas le droit de prendre du retard, sous aucun prétexte »
Donc
MPD a été cité dans les commentaires de deux dépêches récentes, ici pour la transparence réseau du son à l'occasion d'un débat sur la transparence réseau du système graphique, et dans l'autre dépêche sur le serveur de son PulseAudio. MPD est hors-sujet dans ces deux débats, c'est un lecteur de musique avec télécommande ip…
[Addendum : d'ailleurs, si tu n'utilises ni dmix ni Pulseaudio (ou similaire) en plus de MPD, ton bureau ne pourra rien jouer pendant qu'MPD joue ta liste de lecture… ce qui montre qu'MPD ne résoud pas le problème d'un serveur de son]
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Maclag . Évalué à 3.
Mouai, à une époque, je pensais à ça aussi, et puis je me suis souvenu que "je" ne suis pas un utilisateur "normal":
Qu'est-ce qui nécessite une machine puissante?
En plus, les netbooks seraient, s'ils n'avaient pas été sauvagement assassinés, de plus en plus puissants, réduisant ainsi encore et toujours les besoins d'avoir des calculs déportés.
Mais aujourd'hui, il ne reste les tablettes d'un côté et les ultrabooks de l'autre. (Les tablettes qui se posent sur un support avec un clavier, ça ne me convainc pas vraiment: on a l'impression qu'un petit coup dans le châssis, et la masse de la tablette va faire plier tout le bordel! Mais c'est un avis personnel).
Conclusion: de toute façon, y'a pu de netbook! snif!
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
A 3Go la moindre application, je ne déploie pas toutes les applications sur les postes utilisateurs… L'affichage distant est fondamental, sans cela, point de salut en entreprise.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Maclag . Évalué à 3.
Je réponds à un commentaire qui parle du créneau du gros PC et des clients légers DANS LA FAMILLE.
Sinon je te dirais que les performances de la couche réseau ne sont sans doute pas critiques dans ton cas, je me trompe?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je gère les serveurs, les postes fixes et les portables de la même manière. C'est un des intérêts de la distribution Debian que j'utilise. C'est le même logiciel qui tourne sur les noeuds de calcul que sur le portable du stagiaire. Je trouve personnellement très bien d'avoir la même distribution partout. J'ai d'ailleurs la même chez moi. Un truc bien conçu peut être bien conçu pour tous ;-)
En pratique, même si notre réseau est pas si mal, il a ses points faibles… notamment pour des raisons de firewall CISCO (belle daube ce truc).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 1.
Exactement - idem pour la place prise par les OS - gaspillage sans fin de ressources et d'énergie juste pour taper du texte et inclure 2/3 images ou vidéos.
Sans compter l'importance du point de vue de la sécurité. c'est surtout sur ce point que l'affichage distant est une quasi obligation en entreprise.
0 données non volatiles sur le poste client, c'est la base de tout projet sérieux de mon point de vue.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Tu connais le partage de fichier en réseau ? Tu centralises les fichiers… et tu décentralise le calcul et le rendu image/son, ça se fait depuis… hum, très longtemps et y a pas besoin d'avoir un serveur avec watmille cœurs et des To de ram pour exécuter tous les programmes de tous les utilisateurs… et rien n'est stocké sur le poste client. De toute manière l'utilisateur a un poste client, qu'il serve au moins à calculer !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . Évalué à 0.
Un poste client qui consomme 200 watts avec une carte réseau utilisée à 0,1%, un GPU utilisé à 0,1% et un taux d'occupation des disque durs < 1%, oui, et c'est aussi ça le problème qu'il faut résoudre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Prosper . Évalué à 3.
Y a le streaming pour ça cf cloud gaming et oui ca marche vraiment pas mal.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Maclag . Évalué à 4.
Est-ce qu'on parle de la même chose?
Je réponds à un commentaire sur l'affichage distant d'une application, la transparence réseau quoi, utilisé sur un gros PC familial et des clients légers.
Tu me réponds qu'il existe des solutions de jeu avec streaming.
Je soupçonne que ces jeux se reposent sur d'autres solutions techniques que la transparence réseau des couches graphiques de Windows, Mac OS, et même X11.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Prosper . Évalué à 3.
Oui
Evidement puisque celles ci sont inefficaces, la solution c'est que le pc distant (dans le cas du cloud gaming c'est plutot une ferme de serveur/gpu ) fasse tout le boulot et streame le résultat , et ca marche très bien , un autre exemple est la nvidia shield .
Bref jouer sur une machine distante genre netbook c'est possible et y a déjà plein de solution qui fonctionnent: onlive ou gakai par exemple.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Maclag . Évalué à 5.
Je vais me répéter encore une fois:
On parle de TRANSPARENCE RESEAU pour une couche graphique.
Un monsieur dit qu'une couche réseau pas assez rapide, c'est une occasion manquée pour avoir un ordi central et les clients qui lancent leurs logiciels dessus.
Je réponds que je ne crois pas à cette solution.
Après, des solutions à base de streaming je n'ai aucun doute que ça fonctionne, parce qu'aucune de mes machines ne peut calculer d'images de films, même avec décalage.
Mais à ce que je sache, les jeux dont tu parles ne sont faits de la même manière que ton démineur que tu lances en local.
Ce ne sont pas des jeux que tu lances à travers une couche graphique sur transparence réseau (ou le contraire, on se comprend). Ce sont des jeux qui reposent sur un fonctionnement entièrement différent.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à 1. Dernière modification le 19 juin 2013 à 15:43.
Afficher une fenêtre isolée texte (terminal…) à distance reste amha important: Au boulot à mon bureau (machine sur une RHEL like) j'ai en permanence des fenêtres de plusieurs machines en lab sur lesquelles j'ai des manips/minicoms/configs locales ouvertes. Dans l'autre sens, j'ai toujours un reverse tunnel ssh ouvert afin de pouvoir passer une connection montante à travers le FW qui bloque le sens lab->bureaux (les cartes avec un drv eth en developpement qui plantent la boit, ca s'est vu!)… pour tirer une fenêtre avec accès à mes sources sous gestion de conf.
Chez moi en télétravail sur laptop/windows: Putty en ssh avec X11 forwarding et Xming sont mes outils de base. Avoir des sessions entières via des VNC, même compressé, à travers le VPN et un accès ADSL c'est juste intenable (vers 1 machine à la limite, au delà c'est inutilisable).
Donc, oui, Wayland doit se préocuper de ces usages qui peuvent paraitre basiques mais restent très utiles. Sous Linux, les madames Michu sont assez minoritaires et tout changement sera bienvenu tant qu'il améliore l'existant, y compris le rxvt de base. Sinon ca ne prendra pas :-/
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
Si c'est un terminal, c'est du SSH qu'il faut faire, ça fait moins de données à transférer pour le plaisir.
Il y a des protocoles beaucoup plus performant que VNC ou X qui se basent quand même sur des bitmap compressés à envoyer).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à 2.
SSH limite à du texte… quand il s'agit de tirer un éditeur (même light, comme nedit) ca le fait pas. En prime c'est ouvrir une multitude de connections SSH avec à chaque fois un mdp ou une passphrase à taper (si on n'a pas un host ou un ssh agent est utilisable).
Ce serait une grosse perte de fonctionnalités et de confort.
Pour les alternatives, encore faut-il qu'elles soient disponibles sur une machine pour laquelle vous n'êtes pas root. Et pour avoir essayé NX par exemple je trouve que tirer X à travers SSH avec la compression à la volée est plus performant (au delà d'une dizaine de fenêtres, ou tirer une IDE un peu complexe, ce ne serait sans doute plus le cas mais les IDE sont peu utilisées en entreprise aux profit de scripts de génération plus propices à automatisation, ou on intègre la gestion de conf et les outils d'intégration continue: build/tests auto…).
Les serveurs SSH et X, eux sont présents et utilisables partout.
Si Wayland devait être une regression comparé à X sur le distant, avec en prime le développement à la mode de shared host à la place des machines de bureau, je pense que ce serait une grosse erreur.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
Non, il est tout à fait possible de multiplexer les connexion SSH. http://www.unixgarden.com/index.php/gnu-linux-magazine/multiplexage-des-connexions-ssh
Ils sont présent partout parce que quelqu'un les a installer. Si, dans le futur, X disparaît, les admin installeront un driver Spice et ce sera la même chose.
Si on fait du Shared Host, je pense qu'il vaut mieux avoir un protocole dédié et optimisé pour le réseau plutôt un protocole qui peut passé par le réseau mais est loin d'être optimisé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à -2.
Tu sais… désormais quand on ouvre un ticket sur un truc qui marche pas ou manque, il est ouvert par HP (en charge de l'infra) au choix en:
-Roumanie,
-Philippines,
-Maroc,
- …
Et à l'usage, c'est pas cher mais ça ne vaut vraiment pas plus:
La résolution est déjà aléatoire sur les pb bloquants. Alors pour demander ce qu'il faut en (nouveaux) protocoles d'accès distant sur des gros shared-hosts de développement/compilation!
X est installé partout car il s'est imposé en standard (les admin ne se posent même pas la question) et ca fait 30 ans que les habitudes d'avoir un serveur pour l'affichage sont prises: AMHA toute alternative incapable de proposer cela en mieux est vouée à un échec cinglant et ne deviendra jamais le standard qu'on est certain de trouver sur tout les unice non limités à un mode texte (rare: On trouve même des machines sans interface graphique/écran ou le serveur X est là, afin de pouvoir utiliser un applicatif standard en distant).
Je pense qu'il y a une grosse erreur en cours sur ce sujet: Il aurait mieux valu développer encore plus le concept afin d'intégrer au minimum le son (en intégrant à wayland les verrues existantes pour pallier à cet oubli de X) en plus de l'affichage.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 3.
Justement en découplant le protocole du serveur d'affichage, on peut avoir quelque chose de mieux. Par exemple, pendant la période de transition, avoir la même technologie pour X et pour Wayland (RDP ou Spice le permettent). Ou permettre la 3D de manière efficace (Red Hat cherche à le développer pour Spice).
Il y a déjà spice qui fait ça. Pourquoi réinventer la roue ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'ai déjà fait tourner une appli avec rendu OpenGL via RDP, j'avais l'impression que ce rendu était fait par la carte graphique locale. Qu'en est-il réellement?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à 1.
Au fait, merci pour le multiplexage des connections SSH… Comme quoi on en apprends encore sur cet excellent outil même après des années d'usage! Je ne sais même pas comment je bosserais sans: Du distant au passage de firewall à sens unique séparant strictement des sous-réseaux semi-isolés… SSH sait tout faire et bien plus.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par NanoTech . Évalué à 2.
Si Wayland n'a pas d'API de dessin, cela signifie-t-il que pour dessiner un rectangle 1000x1000 blanc uniforme, il faut utiliser un memset (très consommateur en CPU), ou passer par OpenGL (problème de qualité des pilotes)?
Soit on utilise du Software pur, soit du hardware accéléré 3D?
Pas de place pour l'accélération 2D?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 6.
C'est le même problème actuellement avec X, sauf qu'on reporte ça sur le serveur (quand on utilise l'API de dessin).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 1.
Certes, note qu'en distant avec Wayland si tu utilise OpenGL, le client va écrire dans la mémoire locale de son GPU puis recopier en RAM pour l'envoyer par le réseau (ta carte Ethernet ne peut pas accéder à la VRAM) à la RAM du serveur d'affichage qui va ensuite le transférer dans la mémoire de son GPU , alors qu'avec X le client envois la commande au serveur d'affichage qui va utiliser OpenGL pour écrire directement dans la mémoire du GPU.
Alors avec les écran haute résolution qui devraient finir par se démocratiser, Wayland plus efficace qu'X en distant?
Hum, j'ai un gros doute.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Patrick Nicolas . Évalué à 2.
Du coup Wayland est plus flexible: il peut dans le cas du réseau conserver la ou les dernières images, appliquer une compression différentielle et pourrait même adapter en fonction du débit disponible. Les données sur le réseau ont diminué !
Tout ceci n'est que supposition, je ne connais pas assez les détails du fonctionnement, je ne fais que lire ce qui est disponible. Mais actuellement et certainement pour longtemps les copies de VRAM à RAM et inversement sont insignifiantes par rapport à la latence sur le réseau.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 0.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si tu as plusieurs plan de pixel de composition qui bougent, tu peux faire le diff d'affichage uniquement à partir des plans qui ont été modifié ou pas.
"La première sécurité est la liberté"
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Pierre Tramonson . Évalué à 2.
C'est beaucoup utilisé à distance X.org ?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 6.
La question est plutôt de savoir si la transparence réseau de X est beaucoup utilisé ou si on lui préfère d'autres solutions.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Dans mon laboratoire, on l'utilise beaucoup.
En pratique, avec la 3D, cela merde selon les config sans trop savoir pourquoi (il faut dire que par exemple Ansys Workbench est une merde en boite).
Donc, on enrobe X dans NX (ou X2Go, ce sont les mêmes bibliothèques) et là, c'est que du bonheur.
Bref, tout ça c'est très bien mais c'est dommage que NX n'est jamais été intégré dans X depuis le temps alors que No-Machine avait joué la carte du logiciel libre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
Et NX ou X2Go, c'est le protocole X ou ça pourrait très bien être appliqué à Wayland ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je ne sais pas. Keith Packard après un gros travail avait dis que c'était inutile de tenter d'améliorer la transparence réseau car il n'obtenait rien de mieux qu'un ssh -CX, en gros gzip suffisait et No-Machine est arrivé 3 mois après avec NX qui marche d'enfer, il faut l'avouer.
De ce que j'en ai compris, NX est une bidouille grandiose qui met en place une espèce de cache proxy à chaque extrémité.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Babelouest (site web personnel) . Évalué à 1.
J'ai une question de néophyte, mais j'ai l'impression qu'une bonne partie du débat vient du fait que X et Wayland utilisent un modèle client/serveur.
Ma question est la suivante: est-ce que j'ai compris de travers, ou est-ce que quand on est uniquement en local, le serveur X passe quand même par une couche réseau qui rajoute du traitement pour rien ? (C'est une vraie question au fait)
Si j'ai rien compris techniquement, je m'en excuse…
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par dinomasque . Évalué à 2.
Non, heureusement. X ne passe pas par le réseau en local.
BeOS le faisait il y a 20 ans !
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 8.
C'est un des mythes tués dans la conférence en vidéo. Xorg fait tellement d'aller-retours pour l'affichage des fenêtres en permanence que le sur le réseau il est hyper lent. S'il évitait tous ces allers-retours d'informations il serait à peine au niveau de VNC !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par moi1392 . Évalué à 5. Dernière modification le 14 juin 2013 à 19:29.
Petite rectification, le client va utiliser OpenGL 1.1 pour dessiner son carré blanc.
T'en connais beaucoup des applis qui dessinent des carrés blancs toi ? Pour moi, s'il n'y a pas de shaders, pas de vbo, pas de fbo et d'autres joyeusetés, OpenGL, ça sert vriment juste à faire de jolis cubes qui tournent.
Et tout ça, c'est au minimum OpenGL 1.5, mais honnetement, avant OpenGL 2.0, c'est juste pour dire que c'est là.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
OpenGL 1.1 permets de faire de des choses sympatiques :-)
Aujourd'hui beaucoup de développeurs ne savent plus faire avec le vieux pipeline, c'est normal, mais ça ne veut pas dire qu'il se limite aux carrés blancs!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Michaël (site web personnel) . Évalué à 2.
Du site newtonaventure:
amener, utiliser → amenée, utilisée
Pour trouver le bon accord, on remplace le verbe conjugué par un verbe du troisième groupe, qui fait aussi entendre l'accord du féminin:
Pour la première phrase cela donne une clef qui doit être prendre ou une clef qui doit être prise et la seconde la gravité doit aussi être prendre ou la gravité doit aussi être prise.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Merci pour ces remarques!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
C'est une question intéressante..
Je sais que pour le Raspberry Pi ils ont utilisé l'accélération spécifique 2D de la carte à la place d'EGL, maintenant ça ne répond pas forcément à ta question je ne sais pas car je ne sais pas où ils ont utilisé l'accélération 2D: c'est peut-être uniquement dans le serveur et ta question est pour la communication client -> serveur d'affichage, le client peut-il préparer les buffers en utilisant de l'accélération 2D?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 4.
De ce que j'ai compris, le client fait ce qu'il veut. S'il veut utiliser l'accélération 2D de la carte graphique, il peut le faire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Batchyx . Évalué à 7.
Moi je discuterai plutôt de la pertinence de vouloir de l'image parfaite à tout prix. Parce que si c'est ce que je pense, ça veut dire que si la machine est chargée, on va préférer geler l'affichage tant que l'image ne sera pas calculée correctement plutôt que d'afficher des versions imparfaites mais néanmoins manipulables.
Parce que si avoir des images imparfaites est moche, avoir des freezes est bien pire, ça donne une forte impression de lenteur (comme Windows) et c'est super-énervant. C'est peut-être plus joli en général, mais pour ceux qui font bosser leur machine, c'est franchement pas justifié.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Oui sur le redimensionnement des fenêtres Weston attend la fenêtre complète calculée par le client avant de l'afficher, donc si le client est lent ça peut saccader, ce qui sera bien pénible en effet!
Après je crois que KDE veut gérer la décoration des fenêtres coté serveurs d'affichage donc il est possible qu'ils gardent la technique actuelle 'fluide mais parfois moche' plutôt que 'parfait mais saccadé'.
Au moins pour déplacer les fenêtre Weston le fait tout seul donc ça devrait être fluide, c'est toujours ça!
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . Évalué à 5. Dernière modification le 14 juin 2013 à 17:16.
Actuellement X s'occupe tellement d'afficher le rendu (des résultats incomplets moches et qui servent à rien) que quand tu redimensionnes une fenêtre avec beaucoup de widgets (chaque widget étant une fenêtre) t'as un temps d'attente notable avant d'avoir le résultat.
En vidéo :
http://www.youtube.com/watch?v=6t2cap1tZzE&feature=youtu.be
Wayland ne peut pas faire pire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par letsyl . Évalué à 10.
Ton raisonnement part du principe que X est utilisé comme à son origine.
Aucun toolkit moderne n'utilise X pour dessiner un rectangle, tout est dessiné dans un buffer par le toolkit et "transmis" au serveur X.
Après tu ne peux pas séparer X de son écosystème, l'article est une vision pragmatique de la manière dont X est utilisé actuellement (pas de la théorie sur le protocole).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 0.
Mauvais toolkits, problème d'X??
C'est un peu la même problématique que pour XCB, XLib était pourri OK donc les devs X ont créer XCB (1ère version en 2001, Wayland a été commencé en 2008 et Qt5 va supporter les deux en même temps, chercher l'erreur??) mais les toolkits ne l'adoptent pas, c'est de la faute d'X??
Ma remarque sur les écrans haute définition qui arrivent bientôt (très bientôt même si le 4K prend) s'applique, et là soit on pourra augmenter la compression de buffer à Wayland (dommage pour la latence), soit .. revenir à un système à la X (enfin en supposant que les toolkits fassent bien leur boulot).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par letsyl . Évalué à 5.
Ils sont pas très malins aussi ces développeurs de toolkits, hein ? :)
Pourquoi en est-on arrivé là ? (Pourquoi les toolkits n'utilisent plus X pour dessiner le contenu des fenêtres ?)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à -1.
Pour GTK le manque de main d'oeuvre est criant, pour Qt il y a un mode XRender (mais ce n'est pas le mode par défaut), un jour où je serai a la retraite (dans 25 ans) ça pourrait m'amuser de comparer les performances en réseau entre ces 2 modes.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Crao . Évalué à 8.
Tellement criant qu'ils ont justement passé du temps à enlever les appels à X pour tout dessiner côté client dans GTK 2.18 : https://live.gnome.org/GTK+/ClientSideWindows
Le fait est que faire appel à X pour dessiner le contenu des fenêtres n'amène que des contraintes, donc tout le monde a arrêté depuis des années.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par nud . Évalué à 3.
Wayland est aussi extensible, on pourrais très bien voir apparaître dans le futur une extension "vectorielle" (SVG?) qui permettrait au client de déporter le dessin sur le serveur… L'avantage vis à vis de l'approche du protocole X c'est qu'il s'agirait d'une extension dont on pourrait se débarrasser quand on n'en a plus besoin plutôt qu'une partie du cœur.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 2.
Techniquement c'est possible, quoique pas si simple:
1) il faut pouvoir 'synchroniser' l'envoi d'une image normale et d'une image vectorielle superposée, il me semble que dans leur modèle de dessin de "subsurface" les subsurfaces sont disjointes (pas sûr)..
2) il faut trouver le 'bon' jeu d'instructions vectorielles: SVG me parait beaucoup, beaucoup trop gros!
Maintenant comme ça ne rentre pas dans la philosophie du "tout client" je doute que ça ait une chance de rentrer dans le protocole 'standard'.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Et de l'openGL? ou tout autre transcription très proche comme WebGL peut l'être? Enfin ça c'est pour le coté "jeu d'instruction", parce que cela ne règle pas le coté "tout client".
Parce qu'on peut se mettre à imaginer des trucs de fous, genre l'appli utilisé à distance, au lieu de générer les buffers à destination de Wayland/Weston, elle génère des json de code WebGL qui sont envoyés en realtime via WebRTC à un navigateur web, qui interprète ce code en direct.
Et hop, une connection distante à l'aide d'un simple navigateur web moderne (pas IE).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Ignatz Ledebur . Évalué à 9. Dernière modification le 14 juin 2013 à 15:17.
Tu oublies "Wayland casse la gestion des bureaux de tout le monde" : ceux qui utilisent un simple WM (dwm, pekwm, fluxbox, openbox, awesome, etc. ) vont effectivement l'avoir dans le baba. :\
Sachant qu'écrite un compositeur est beaucoup plus lourd qu'écrire un WM, la solution qui se dessine est d'implémenter les WM en tant que plugins pour Weston. Ce revient à lier le destin de chaque WM a celui d'un compositeur particulier (au lieu qu'aujourd'hui c'est un simple client X).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par manawy (site web personnel) . Évalué à 7.
La vidéo donnée dans l'article répond à nombre de ces points.
Pour faire court :
même si en théorie ça pourrait être mieux, en pratique X n'est plus humainement maintenable.
Une de leur principale préoccupation c'est de prévoir une solution qui continuera à être maintenable au cours du temps.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Oui c'est assez dommage de lire ces critiques (tout de même nettement moins trollesques que sur lwn.net) alors que j'ai pris soin d'ajouter la conférence de Daniel Stone - qui connait parfaitement le sujet, et pour cause!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 9.
Vu les performances de XRender, je doutes qu'il y ait encore beaucoup de toolkit qui l'utilisent… A part xterm et probablement urxvt, il ne doit meme pas y avoir beaucoup de terminaux qui l'utilisent encore directement.
Vu l'echec de l'API de dessin de Wayland, c'est une bonne chose que de ne pas mettre un truc inutile dedans et de completement le decoreller en se reposant entre autre chose sur OpenGL/EGL.
Est-ce qu'il y a un seul toolkit qui utilise juste xcb ? La reponse est non pour une seule raison, il n'y a pas de support de XCB pour OpenGL de disponible avec la majorite des drivers (En fait, je ne sais meme pas si il y en a un qui le propose). Sur le papier xcb, c'est bien, mais au final, tu dois de toute facon avoir xlib, donc les toolkits se tappent une double stack qui n'apporte pas suffisament pour justifier l'effort.
J'avoue que j'ai du mal a comprendre cet objectif, si je veux juste du texte a distance, j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Dring . Évalué à 2.
J'imagine que tu voulais dire l'API de dessin de X ?
Le texte, c'est aussi dans ton traitement de texte, dans ton tableur, dans ton logiciel de messagerie, dans…
A noter que je suis plutôt pro Wayland; pour moi l'intérêt principal c'est de recréer une pile complète "from scratch", propre et exempte des N couches de compatibilités, et qui attire une nouvelle génération de contributeurs.
Après, nul doute qu'en 30 ans, X a identifié et corrigé, d'une façon ou d'une autre, tous les problèmes rencontrés. Mais à quel prix en terme de maintenabilité ?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 3.
Ah ah ah ! Oui :-)
Sauf que dans le cas du traitement de texte, tu vas vouloir avoir un controle tres fin du rendu, et il est peu probable que tu t'appuie sur le serveur graphique. Si tu veux avoir un resultat a peu pres proche de la sortie imprimante et du resultat sur Windows/MacOs, tu veux avoir le meme moteur de rendu… Donc je parie que tu ne passes pas aujourd'hui par XRender.
Sans compter que en terme de performance, c'est du texte que tu veux lire, donc tu n'es pas a vouloir le faire defiler a grande vitesse. Ca implique que au final, tu as des images tres statique avec de petit motion vector. Donc le rendu avec des sous-surfaces qui sont deplace donnera de bonne performance et laissera les choses tres utilisable. Ce sera probablement le cas pour les tableurs et les logiciels de messagerie aussi.
Il n'y a que les terminaux qui on un besoin de performance et de debit reseau reellement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 1.
Ça dépend beaucoup du traitement de texte(!), pour pas mal de notepad et consort chaque caractère a un rendu unique où le "glyph cache" fonctionnerait très bien.
Faux, on passe aussi pas mal de temps à faire défiler rapidement du texte qu'on ne veut pas lire pour arriver à la section qui nous intéresse..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par ariasuni . Évalué à 2.
Je ne crois pas non, vu que tous les jours j’ai de magnifiques clignotements, à peines perceptibles certes, mais quand même présent lorsque . Ainsi que divers bugs graphiques qui ne n’apparaissent pas si j’utilise les effets de bureau mais ils sont désactivés chez moi (mais la composition est quand même activée).
Bref, j’ai aussi d’autres petits bugs graphiques comme ça assez souvent, et j’espère vraiment qu’ils vont complètement disparaitre avec Wayland parce qu’à l’heure actuelle c’est quand même assez ridicule comme problème!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . Évalué à 1.
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
Oui en local utiliser XRender n'a pas de sens, en distant par contre c'est le contraire: se restreindre a envoyer des gros buffer (et avoir soit une grosse utilisation de bande passante, soit une latence dégradée à cause de la compression) est sous-optimal.
Je pense effectivement que c'est ce qui va se passer, les utilisateurs qui avaient l'habitude d'exporter leur terminal passeront par ssh à la place.
Ça ne me pose pas de problème particulier, mais c'est juste un peu pénible d'entendre des Wayland fanboy, dire X c'est tout pourri(vrai), Wayland c'est génial: presque vrai mais uniquement dans 90% des cas, ce n'est pas être contre Wayland que de dire Wayland c'est génial sauf pour exporter du texte en distant ou là (à priori) il vaudra mieux utiliser ssh ou NX (donc X).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . Évalué à 5.
J'ai juste dis performance. Et en ADSL avec NX (donc en echange de buffer compresse moins efficace que ce que peux faire Wayland), j'ai des performances meilleurs qu'en utilisant X avec des toolkits faisant du Xrender. Et aujourd'hui, la plus part des toolkits ont abandonnees de fait Xrender. Je ne connais pas de cas ou j'ai eu une meilleur utilisation avec Xrender. Bon apres, ca c'est peut etre ameliorer depuis qu'on a tue notre backend, il y a 2 ans, mais les performances ont toujours ete abyssal, en local et en distant.
NX fait de la compression de buffer tres efficacement qd tu exportes de l'export display et ca marche tres bien pour des terminaux qui n'utilisent pas Xrender. Donc si tu peux utiliser NX, tu pourras utiliser Wayland pour le meme usage.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à 0.
Le ssh -XC est extrêmement utilisé et pas que pour tirer des terminaux X. Devoir multiplier les connections ssh pour être bloqué à des usages textes seuls et à travers un terminal de qualité inégale selon le host (putty sous windows par exemple), c'est juste inacceptable pour pas mal de monde en milieu pro.
Zapper cela, c'est s'exposer à des conséquences similaires à ce que connait gnome 3 pour la RHEL 7: Exit le gnome-shell, revenez à la raison les mecs on vends pas du win8, par défaut ce sera le mode classique ala gnome 2 résultat de 3 décennies d'évolution d'un bureau productif pour des machines de bureau qui n'iront jamais au tactile (trop de boulot aux femmes de ménage!).
Là ce serait carrément ne pas être dans la distrib la plus utilisée en milieu pro car cela va hurler aux premières présentations commerciales d'une future RHEL 8 qui s'y essaierais en entreprise. Ce qui voudrait dire pour Wayland ne pas devenir le standard remplacant X.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 4.
Gnome shell sera bien présent dans RHEL7, c'est juste que les extensions du mode classique seront backporté de la 3.8 à la 3.6.
Ça m'étonnerait beaucoup que Wayland arrive par défaut dans RHEL8, peut-être la 9.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à 1.
RH est un gros contributeur de Gnome, je ne sais s'il est directement à l'origine de ce mode classique en 3.8, mais il est probable qu'ils aient quand même bien pesé dans ce sens. Gnome Shell en entreprise, c'était du suicide et passer à KDE de base ou XFCE (qui donne l'impression de revenir 10 ans en arrière) posait de gros pb de migration.
Pour X/Wayland, probable qu'ils suivent cela attentivement tant les impacts seront grands… mais le choix est parti pour rester car X continue son développement. Peut-être que des distrib grand public pourront aller sur un Wayland amputé sur le distant sans dommage, mais je doute que les distrib pro s'y risquent si on y perds de ce côté. Surtout que les environnements resteront hétérogènes pendant des années.
Problème: Linux en desktop chez Mr tout le monde c'est environ 1%. Pas de quoi imposer un standard, on en revient là, si les distrib pro devaient refuser Wayland.
Maintenant, on verra à l'usage… Mais attention à ne pas faire l'erreur de Microsoft (et dans une moindre mesure Gnome), qui apprends ce qu'il en coute de changer brutalement les habitudes de ses utilisateurs.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 5.
Gnome Shell sera en entreprise. Il y aura juste des extensions en plus, mais ce sera bien le même gnome shell que dans Fedora (par exemple).
Vu que Red Hat mise sur les protocoles d'affichage dédiés au réseau (Spice), je pense que Wayland aura plusieurs solutions de qualité d'affichage distant.
Je ne vois pas bien ce que tu veux dire, Windows 8 se vend plutôt bien sur PC si on prend en compte que les gens préfèrent les tablets au PC et que donc on vend naturellement moins de PC (si c'était Windows 8 le problème, les vente de Mac et de PC sous Linux auraient explosées).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par loste . Évalué à -1.
Gnome Shell sera sans doute là… caché derrière un bureau résultat de 4 décennies de maturation qui restera longtemps encore le standard le plus productif sur une machine de bureau ou le tactile n'a aucun intérêt (on patouille son smartphone, pas son 22").
Pour les autres protocoles (que j'avoue ne pas connaitre), encore une fois si ça oblige à tirer tout le clicodrome d'un bureau complet (ala VNC en mieux) j'ai du mal à percevoir ce qu'on y gagne: Merdoiements de différences de résolution… Avoir sa fenêtre intégrée à l'environnement graphique de la machine utilisée, que ce soit avec un Xming sous windows, une solaris ou un linux, cela reste quand même de très loin le plus naturel et le moins sujet à problèmes.
Sans compatibilité/isofonctionnalité, qui porte la tétrachiée d'applicatif existant? On fout tout à la poubelle?
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par claudex . Évalué à 3.
Gnome shell étant responsable de l'affichage du bureau, j'ai du mal à comprendre comment il sera caché.
RDP permet l'affichage d'une seule fenêtre si le serveur le supporte.
Non, on fait tourner X dans Wayland pour les applications qui n'auront pas migré.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Compteur de pixels
Posté par Sébastien Koechlin . Évalué à 10.
Ça n'a pas de sens. Le nombre de pixel d'un écran en 640x480 est déjà de plus de 300 000. Il ne s'agit pas du nombre maximal de pixel mais de la dimension maximal de l'affichage. On ne peut pas dépasser 32768x32768. Avec un affichage ayant une densité de 100 pixels, si on aligne 32 738 pixels, on arrive effectivement à 8.3 mètres. En 300ppp, on descends à 2,7 mètres.
[^] # Re: Compteur de pixels
Posté par windu.2b . Évalué à 3.
Merci pour cette explication : je ne comprenais rien du tout ça ce passage…
# Merci
Posté par ʭ ☯ . Évalué à 10.
Merci pour cette longue traduction. C'est un régal à lire, et permet de se tenir au courant de cette grosse évolution de fond qui se fait loin des utilisateurs pour l'instant.
Pour ma part, certains défault sont quotidiens :
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Merci
Posté par Okki (site web personnel, Mastodon) . Évalué à 5.
Je viens de tester avec Gnome 3.8, verrouiller la session, et les touches multimédia continuent de fonctionner (volume, pause, piste précédente/suivante…)
[^] # Re: Merci
Posté par nwrk2 . Évalué à 3.
J'imagine que c'est parce que ça passe par d-bus et qu'il y a un support spécifique dans gnome-screensaver. Mais je ne pense pas que ce soit une bonne solution au problème.
[^] # Re: Merci
Posté par wismerhill . Évalué à 1.
En ce qui me concerne, vu que j'ai associé à plusieurs touches «multimedia» le démarrage de programmes, ça m'arrange bien qu'elles soient bloquées comme les autres!
[^] # Re: Merci
Posté par vv222 (site web personnel) . Évalué à 6.
Et le bug devint feature.
L'écran de veille n'est d'ailleurs pas le seul à souffrir de ce défaut : impossible d'utiliser mes touches multimédia dans XFCE pendant que je navigue dans le menu des applications (ce qui arrive bien plus souvent qu'on ne pourrait le penser), ou lors de l'utilisation de certaines applications qui capturent toutes les entrées clavier en plein écran.
# Une fois de plus
Posté par Alex_Parker . Évalué à -10.
C'est impressionnant de voir à quel point certains se démènent pour tenter de fourguer à tout prix leur ancienne nouvelle solution de la mort qui tue qui va tout casser mais qui fatalement se révèlera tout aussi bancale et sera au final poussée vers la sortie par une autre méga super ancienne nouvelle solution de la mort qui tue qui va tout casser mais qui fatalement se révèlera être…
Et pendant ce temps, on attend toujours que les applications actuelles soient enfin stabilisées et fassent vraiment ce qu'on leur demande.
Non la fuite en avant n'est pas une excuse, ni la course au kicestkialeplusgroskiki genre Firefox/Chrome qui en sont déjà à la version quarante douze avant la quarante treize le lendemain, mais toujours aussi buggée.
Et pendant ce temps là, les utilisateurs servent de cobayes aux petites expérimentations de ces messieurs.
[^] # Re: Une fois de plus
Posté par laparn . Évalué à 10.
Pour le coup, s'il y a un logiciel sur lequel le libre s'est acharné pour faire quelque chose de stable c'est bien X. Il y a eu une rupture entre X11R6 et X.org pour déjà dépasser certaines limitations du logiciel.
Le problème c'est qu'X est architecturalement très vieux. Aucun système graphique aujourd'hui n'est aussi vieux. Il me semble que par exemple windows 3 est apparu après X11 (à vérifier). Je ne parle même pas de cocoa. Donc X a intégré des contraintes très anciennes qui aujourd'hui n'ont plus aucun sens et qui nuisent à l'évolutivité et à la stabilité. X a été inventé alors qu'openGL n'était même pas dans les limbes.
Donc il est logique que les développeurs disent : on repart de 0 et on utilise l'expérience que l'on a sur le sujet pour faire quelque chose qui tient la route. Et surtout, on fait quelque chose de beaucoup plus petit, plus maintenable et dont les fonctions sont strictement celles nécessaires pour les toolkits d'aujourd'hui.
Donc c'est pas une fuite en avant, au contraire, c'est plutôt un hard reset nécessaire.
[^] # Re: Une fois de plus
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Il sont pas tout jeune tous les deux ;-)
[^] # Re: Une fois de plus
Posté par dinomasque . Évalué à 4.
Oui, NextSTEP n'est pas tout jeune.
Mais il avait une avance technologique sidérante à l'époque avec son DisplayPostscript.
Même BeOS 10 ans plus tard n'était pas aussi avant-gardiste en matière de serveur d'affichage !
BeOS le faisait il y a 20 ans !
[^] # Re: Une fois de plus
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Quoi de plus simple à imprimer que du DisplayPostScript. Si mes souvenirs sont bons, Mac est passé au PDFDisplay mais c'est bien pareil.
Je ne vois pas ou est le mal de vouloir imprimer via l'affichage. Au contraire, je trouvais xprint plutôt élégant dans la forme (jamais regardé le code). C'était un backend particulier que Mozilla à utiliser pendant quelques temps. D'ailleurs, à l'époque, on en disait le plus grand bien.
[^] # Re: Une fois de plus
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
manque plus que le HTMLdisplay ! Ah non pardon, il y a deja chromeOS
[^] # Re: Une fois de plus
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
J'aime aussi cette idée.
Je dis peut-être une connerie, mais il me semble qu'avec WayLand, c'est bien plus facile à implémenter. Il suffit d’utiliser poppler / ghostscript / what else pour développer le PostScript / PDF généré par l'application et le transmettre à WayLand sous forme de buffers. Tu t'évites le passage par les primitives X.
Ça laisse aussi la possibilité d'implémenter une transparence réseau de plus haut niveau et indépendante du système d'affichage distant, en envoyant directement tes ordres PDF/PS via le réseau.
[^] # Re: Une fois de plus
Posté par vv222 (site web personnel) . Évalué à 10.
Tu as raison, pourquoi continuer à développer de nouvelles applications/fonctionnalités alors qu'on en a déjà ?
D'ailleurs je suppose que tu n'as jamais mis ton noyau à jour depuis 1991 ?
[^] # Re: Une fois de plus
Posté par Maclag . Évalué à 8.
Je me demande bien quelle application est instable ou incomplète dans les distros dites "stables" (Debian Stable, LTS, etc.).
Je me demande bien aussi en quoi le développement de Wayland empêche le développement de ces applications.
Ou alors KWin et autres sont ces fameuses applis incomplètes et instables? A moins que ce soit xorg? Il ne fait pas ce que tu veux?
Hmm je ne vois pas non plus. Je regarde la liste des logiciels de Debian Stable (celle-là, encore) et pas la moindre trace de logiciel expérimental.
[^] # Re: Une fois de plus
Posté par Prae . Évalué à 2.
Compte créé le jour même de la publication. Soit c'est un troll, soit c'est un p'tit nouveau, soit c'est un mec qui manque de bolox pour publier sous son vrai compte :)
PS: je viens de voir la bannière "Do not feed the troll!" quand on tente de répondre, Énorme! Comment cela s'active ? c'est par rapport au -10, par rapport à un karma ou bien par rapport à la date de création du compte ? ou autres ?
[^] # Re: Une fois de plus
Posté par ariasuni . Évalué à 2.
C’est par rapport à la note, ça le fait pour -10 et peut-être pour -9 et -8 mais je n’en suis pas sûr…
Écrit en Bépo selon l’orthographe de 1990
# Combat ?
Posté par modr123 . Évalué à 1.
je vois pas ou est le combat….
[^] # Re: Combat ?
Posté par claudex . Évalué à 6.
Il suffit de lire les commentaires.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Combat ?
Posté par reno . Évalué à 2.
Pas d'accord:dire que c'est un combat, c'est rentrer dans le jeu de l'article/troll…
Quand on choisit entre plusieurs solutions on regarde tout les avantages et inconvénients, quand on ne regarde que les inconvénients de X et les avantages de Wayland, bah c'est bien du Phoronix..
[^] # Re: Combat ?
Posté par claudex . Évalué à 3.
J'insinuais que le combat était dans les commentaires et non pas entre X et Wayland.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Combat ?
Posté par ariasuni . Évalué à 1.
ou ≠ où
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Combat ?
Posté par Prae . Évalué à 7.
j'ai bien une idée… mais tu vas pas apprécier…
# Applications, toolkits, gestionnaires de fenêtres
Posté par Dreamkey . Évalué à 2.
Je profite de cette news pour demander comment l'imbrication se passe.
Si j'ai bien compris, un toolkit permet de dialoguer avec le serveur d'affichage pour afficher ce que l'application demande. Par contre, d'après l'article de Wikipédia, le gestionnaire se place entre les deux lors de la création de fenêtre pour dessiner les bordures : est-ce que ça change quelque chose avec Wayland, car j'ai entendu dire que c'est au client de se dessiner son cadre ?
Sinon je n'ai pas compris le début de l'article, quand ça parle de « gestion de versions […] par client, et non par lien », puis « Tout le protocole est versionné. Chaque auditeur (listener) reçoit exactement la version qu’il prend en charge ».
Je n'arrive pas à me représenter ce que ça change entre X11 et Wayland.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par claudex . Évalué à 4.
Ça dépend, au début Wayland voulait que les applications dessinent elles-même les décoration, c'est donc le comportement de Weston (le compositeur de référence). Par contre, les développeurs de Kwin ont dit qu'ils voulaient dessiner les décorations eux-même. Il y aura donc deux comportement en fonction du compositeur utilisé.
Dans l'exemple donné, Rekonq, kdelibs et flash vont recevoir la même version de l'extension, même si ce n'est pas celle qu'ils sont demandé. Avec Wayland, chacun recevra la sienne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Ignatz Ledebur . Évalué à 10. Dernière modification le 15 juin 2013 à 15:54.
C'est un peu plus compliqué en fait, car X11, contrairement à Wayland, sait dessiner. N'importe quel client X peut donc créer une fenêtre et dessiner dedans avec les "primitives" de X (rectangle, arc, texte, etc. )
C'est également X qui à la base dessine la bordure de fenêtre (qui est un "Window Attribute"). Cependant, tout ce qu'on obtient par ce moyen c'est une bordure de couleur unique de n pixels tout autour de celle-ci. C'est pour cela que la plupart des WM "reparentent" les fenêtres de chaque application : ils créent une fenêtre dont la fenêtre de l'application devient l'enfant. La première pouvant bien entendu être de dimension différente de la seconde, cela permet de dessiner à l'intérieur les barres de titre, boutons, etc.
Les toolkits, quant à eux, sont nés du fait que dessiner avec X est très verbeux. Pour avoir des "widgets" un peu élaborés (avec bouton, listes déroulantes, etc) il a donc fallu créer un couche supplémentaire. À cela est venu s'ajouter le fait que dessiner avec X n'est pas très efficace, c'est pour cela que les toolkits modernes prennent généralement cette fonctionnalité en main, créant des images que X se contente d'afficher dans les fenêtres (enfin, c'est ce que j'ai cru comprendre, mais ça expliquerait le parti-pris de Wayland à ce sujet).
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Dreamkey . Évalué à 4.
D'accord, je viens de comprendre pourquoi les « non-parenting window manager » comme Awesome ne permettent pas d'avoir des cadres élaborés, je croyais que c'était lié avec la fonctionnalité de tilling.
Par contre les ombrages qui sont créées avec un logiciel comme compton, comme ça se passe ? Est-ce que c'est une fenêtre créée (pour avoir de la place pour faire l'ombre), avec ensuite l'application placée dedans en tant qu'enfant ?
Et ça me fait penser, un menu contextuel, est-ce aussi une sous-fenêtre de l'application ?
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Ignatz Ledebur . Évalué à 4.
Je suis loin d'être un spécialiste de X, j'ai juste un peu bricolé avec Xlib, ce qui m'a permis de saisir certains mécanismes fondamentaux. Donc ce que je dis là est un peu au doigt mouillé, car la programmation X ne m'est pas franchement évidente* et j'ignore totalement la cuisine interne des toolkits qui sont au-dessus.
Pour l'ombre, ça dépend si elle c'est une propriété de ton WM. Si compton (que je ne connais pas) est a peu près la seule à faire ça, on ne peut pas parler de re-parenting. C'est la fenêtre de l'application, qui se dessine à l'intérieur comme elle veut (avec ou sans utiliser d'enfants, impossible à dire).
Pour le menu contextuel, c'est plus simple : l'enfant d'une fenêtre ne peut sortir de son parent. Si par ex. je réduis la fenêtre de firefox au maximum et que je fais clic-droit, le menu déborde du cadre, je suis donc sûr que ce n'est pas un enfant de la fenêtre principale. Je dirais donc dans ce cas-là que c'est une fenêtre de premier niveau (ie. un enfant de la fenêtre racine) créée avec l'attribut override_redirect, qui indique au WM de ne pas chercher à gérer cette fenêtre (c'est pourquoi elle se créée à l'endroit voulu, aux dimensions voulues et sans décoration autour).
* J'ai même un fichier qui commence par cette citation du Unix-Hater's Handbook : «Programming X Windows is like trying to find the square root of pi using roman numerals». C'est dire s'il est des choses qui m'échappent.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par erdnaxeli (site web personnel) . Évalué à 3.
Je rajoute deux questions : qu'est-ce qu'un compositeur ? Où se place-t-il par rapport au gestionnaire de fenêtres ?
Actuellement (avec X11) écrire un gestionnaire de fenêtre est relativement simple (je suis moi-même en train d'écrire un tiling manager minimaliste). On reçoit une MAP REQUEST, on fait nos manipulations (redimensionnement, position, reparentage, etc), et on map la fenêtre (plus la gestion des événements provenant du clavier ou de la souris pour déplacer une fenêtre, la réduire, etc). Qu'en sera-t-il avec Wayland ?
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par claudex . Évalué à 7.
Le gestionnaire de fenêtre est le compositeur. Faire son gestionnaire de fenêtre sera plus compliqué mais il sera possible soit de partir d'un compositeur existant (KWin, Weston), soit d'étendre un compositeur existant (il est possible d'utiliser des scripts dans KWin pour le transformer en gestionnaire de tiling par exemple).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par erdnaxeli (site web personnel) . Évalué à 1. Dernière modification le 16 juin 2013 à 14:40.
Ok, je comprends mieux, merci.
Je viens de trouver un tiling manager pour wayland (https://github.com/detomastah/adwc). Rien que le fichier adwc.c fait plus de 5000 lignes. De l'autre côté pour X11 on a plein de petits gestionnaires de fenêtres très correctes qui font moins de 1000 lignes de code.
Coder pour wayland m'a l'air beaucoup plus compliqué, et je trouve ça un peu dommage. Le mainteneur de Plasma chez KDE (Martin Gräßlin) dit la chose suivante :
Mon anglais n'est pas exceptionnel, mais je pense comprendre qu'il préférerait que les petits gestionnaires de fenêtres ne migrent pas sur wayland. J'avoue que j'ai du mal à m'expliquer pourquoi il pense ceci (à part le fait qu'il aimerait surement que tout le monde utilise KDE).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par claudex . Évalué à 7.
Ce n'est pas le mainteneur Plasma mais le mainteneur de Kwin.
Non, il dit qu'il ne s'attend pas à ce que les petits gestionnaires de fenêtres migrent vers Wayland, il ne dit pas ce qu'il veut.
Justement, parce que c'est plus compliqué que pour X. Mais on n'est qu'au début de Wayland. Peut-être qu'un compositeur facilement extensible va apparaître et simplifier le travail de ces gestionnaires de fenêtre minimalistes.
Justement, ce n'est pas du tout sa pensée. Il écrivait encore récemment sur son blog sur les extensions de Wayland propre à KDE qu'il fallait bien faire attention à pouvoir utiliser Kwin sans KDE ou KDE sans KWin (même si ça voulait dire des fonctionnalités désactivées).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Ok, je avais tout compris de travers. Merci pour tes rectifications.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par gouttegd (site web personnel) . Évalué à 4.
Il ne dit pas qu’il préférerait mais qu’il s’attend (“expect”) à ce que les petits gestionnaires de fenêtres ne migrent pas sur Weyland. C’est une prévision, pas un souhait. Et sans plus de contexte, on ne sait pas s’il le déplore, s’il s’en félicite ou même si ça ne le concerne pas plus que ça.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Ignatz Ledebur . Évalué à 3.
Me posant il y a peu les mêmes questions, j'ai trouvé ce fil sur la ML de awesome. Ça laisse entendre qu'il "suffit" de coder une alternative au fichier shell.c de Weston (env. 5000 lignes).
Personnellement, ce qui m'inquiète le plus c'est que la doc pour manipuler tout ça n'a l'air guère plus abondante que pour X (sur Xlib, ce qu'on trouve est vieux, sur XCB, c'est moins que parcellaire). Sauf que sous X on peut se dépêtrer grâce à tout le code disponible, là ça risque d'être beaucoup plus dur, surtout s'il y a une phase importante de stabilisation (X est un cauchemar, mais au moins c'est le même depuis des années).
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Intéressant ce fil. Effectivement l'auteur de Wayland a l'air de dire que Weston est pensé pour que l'on puisse déporter le window manager (actuellement dans shell.c). C'est bon à savoir.
Par contre je ne suis pas d'accord avec toi concernant la stabilisation de Wayland. Je pense qu'au moment où on commencera vraiment à l'utiliser c'est que ça sera plutôt stable. Il est cependant vrai que les premiers devront se débrouiller sans beaucoup de code disponible.
Pour ce qui est de la doc XLib ou XCB, je te rejoins totalement, c'est une horreur (surtout pour la doc XCB qui est inexistante).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par claudex . Évalué à 4.
En même temps, on n'est qu'au début de Wayland. Quand il commencera à être vraiment utilisable et utilisé (c'est à dire, pas avant Qt5 et KDE5, pour KDE), on pourra commencer à avoir de la doc avec des retours d'expérience. Avant ça, ça reste très expérimental.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par Ignatz Ledebur . Évalué à 1.
Oui, vous avez raison, il est trop tôt pour paniquer… disons que je me base sur une "tradition X11", dont sont issus les développeurs de Wayland et que rien n'indique devoir être remise en cause, mais qui vivra verra (et il faut effectivement déjà que Wayland passe du stade expérimental à l'utilisation en conditions réelles, qui ne manquera certainement pas de soulever son lot de problèmes)…
[^] # Re: Applications, toolkits, gestionnaires de fenêtres
Posté par claudex . Évalué à 3.
Ce que vous dites est vrai pour Weston mais pas pour KWin ou Enlightment qui pourraient aussi très bien servir de base pour un autre compositeur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Serveur X vs Apache
Posté par jeyuntu . Évalué à 3.
Si X permet de gérer l'affichage des applications à distance, pourquoi ne pas remplacer le client X par un serveur apache ? Il resterait plus qu'à faire des applications web. On n'aura plus de problèmes d'affichage à distance tout en gardant un certain confort d'utilisation (reactivité de la souris,clavier…) pour l'utilisateur situé au bout du reseau des reseaux. En plus, on gère le multitouch en html 5.
Inutile de rajouter au client web un serveur X.
[^] # Re: Serveur X vs Apache
Posté par thecat . Évalué à 10.
<croisement_de_doigts>
… pourvu que ce soit de l'humour, pourvu que ce soit de l'humour, pourvu que ce soit de l'humour …
</croisement_de_doigts>
[^] # Re: Serveur X vs Apache
Posté par ChickenKiller . Évalué à 1.
Compte spécialement créé le jour du commentaire… je pense que c'est de l'humour/troll.
[^] # Re: Serveur X vs Apache
Posté par mackwic . Évalué à 4.
Et l'ambiguïté étant levée, c'est une excellente blague ! :D
# Merci!
Posté par FantastIX . Évalué à 4. Dernière modification le 17 juin 2013 à 12:09.
… beaucoup pour ce travail de traduction. J'ai en effet vu (et écouté) la vidéo du développeur sur Wayland. C'est vraiment très instructif. Et cette traduction éclaircit quelques points restés nébuleux. J'ai hâte d'utiliser Wayland et je suis son évolution à travers les articles de Phoronix.
Je ne connais pas X et je n'ai jamais capté le concept de client-serveur en ce qui concerne la gestion du graphisme. Pour info, j'ai développé 10 ans sous Windows où ce concept m'était inconnu (je ne l'ai jamais vu clairement mentionné dans la documentation sur GDI). J'ai surtout du mal à comprendre ce qu'est le serveur et ce qu'est un client. Quelqu'un pourrait éclairer ma lanterne? (Ça ne m'empêche pas de dormir mais je suis curieux.)
Pour l'accès à distance, je connais par exemple la bibliothèque Spice, utilisée par Qemu/KVM; elle a l'air très efficace en termes de performance. Les développeurs de Wayland ont-ils prévu de l'utiliser? Ou de se servir d'autre chose?
EDIT: Désolé… j'avais apparemment loupé ça (j'ai honte).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.