Voici une dépêche pour expliquer le fonctionnement de Wayland et pourquoi les développeurs pensent que le X Window System, l'environnement graphique historique du monde Linux, n'est plus adapté à l'utilisation actuelle. Elle est basée, entre autres, sur la présentation de Kristian Høgsberg, le créateur de Wayland, au Fosdem dont la vidéo est disponible.
NdA : merci à Nÿco, reno, baud123, Yves Bourguignon, Jarvis, Hell Pé, Stéphane Aulery et Benoît pour leur aide lors de la rédaction de cette dépêche.
Sommaire
Tout d'abord, il faut savoir que Kristian Høgsberg, le créateur de Wayland, a été développeur X ; il a contribué à ajouter les compositeurs 3D à AIGLX, alors qu'il travaillait pour RedHat. Il commençait alors à développer Wayland pendant son temps libre en 2008. Il n'est donc pas opposé à X mais pense que son architecture n'est plus adaptée à l'usage qu'on en fait actuellement.
Pour la petite histoire, Wayland vient de la ville Wayland, MA situé aux États-Unis dans le Massachusetts. Kristian Høgsberg traversait cette ville quand les principes sous-jacents de Wayland ont été définis.
Principes de fonctionnement de Wayland
Le projet MeeGo, développé principalement par Intel, a été le premier à déclarer vouloir utiliser Wayland à la place de X.Org pour son système d'exploitation. Kristian Høgsberg travaille dorénavant à plein temps sur Wayland chez Intel. Wayland est une nouvelle architecture pour un serveur d'affichage. Il intègre un serveur, un gestionnaire de fenêtre et un compositeur.
Il n'y a pas d'API pour le rendering, les applications écrivent directement dans un buffer. Le compositeur est l'application qui se charge de regrouper les différents buffers graphiques des applications en un seul buffer affichable sur un écran (par exemple, il faut que la fenêtre au premier plan soit entièrement visible et non pas cachée par un bout d'une autre fenêtre).
Dans le monde Linux, les compositeurs ont été popularisés par les bureaux en cube 3D ou les fenêtres en flammes à la sauce Compiz. En dehors de cela, ils apportent une véritable amélioration : déplacer ou redimensionner une fenêtre ne provoque plus un clignotement de celle-ci (risque d'épilepsie réduit de 50 % !), c'est-à-dire qu'ils évitent une phase intermédiaire durant laquelle la fenêtre est blanche puis redessinée.
Le serveur d'affichage de Wayland est en fait le compositeur et les applications dialoguent directement avec lui. Le but n'est pas vraiment de gagner des performances mais d'avoir une architecture simple et plus adaptée à l'utilisation actuelle.
Avec X :
Avec Wayland :
(Schémas tirés de la documentation de Wayland)
Avec Wayland, c'est aussi le compositeur qui va lire les informations des périphériques d'entrée et les distribuer aux applications concernées. Wayland est donc le protocole qui va permettre aux applications d'envoyer leur buffer au compositeur et au compositeur d'envoyer les événements d'entrée aux applications.
Pourquoi X n'est plus adapté
X dispose d'une API pour le rendering qui n'est plus utilisée par les applications car elles génèrent l'image à afficher en local et l'envoient toute prête au serveur graphique. Par exemple, X peut faire du rendu de police mais aucune application ne l'utilise aujourd'hui. [Commentaire: cet exemple est discutable: l'ancien rendu de police d'X n'est plus utilisé mais avec l'extension XRender les applications peuvent envoyer sur le serveur une image contenant leur fonte (GlyphSet) ce qui permet d'afficher du texte avec une bande passante réduite par rapport à l'envoi de l'image du texte entre un client et le compositeur.]
De plus, X possède un système complexe de sous-fenêtres, tombé en désuétude, qui était utilisé pour éviter de repeindre toute la fenêtre lors d'une modification ou pour gérer les événements du curseur (il existe une extension XDamage pour faire cela maintenant). Sa maintenance est un poids mort car peu nombreux sont ceux qui en maîtrisent les arcanes.
L'interface des pilotes n'est pas plus adaptée. L'architecture est prévue pour un pilote par périphérique alors qu'evdev¹ (géré par le noyau) est quasiment le seul utilisé.
Au final la tâche principale assurée par X est la distribution les événements d'entrée vers les applications concernées, mais comme il ignore quelle fenêtre doit recevoir l'information — rôle délégué au compositeur — il ne peut pas le faire correctement.
Dans ces conditions, l'argument principal pour l'abandon de X réside dans l'usage très partiel qu'en font les applications, tellement faible qu'il ne justifie pas les efforts nécessaires pour maintenir les nombreuses autres fonctionnalités inutilisées.
X "works" for us today, because we've built a different display system on top of it.
X "marche" pour nous aujourd'hui, parce qu'on a construit un système d'affichage différent par dessus.
(citation tirée des slides la conférence Wayland au Fosdem)
¹ : Evdev est un pilote générique pour les différents systèmes d'entrée (claviers, souris…) gérés par le noyau Linux. Il s'occupe d'extraire les informations des pilotes spécifiques aux divers matériels pour les présenter sous une forme générique.
Déroulement de la migration
Pour le serveur
Comme différents composants de X ont été éclatés un peu partout, les compositeurs vont pouvoir les réutiliser : KMS pour l'affichage, EGL/GLES2² pour le rendu et lire les événements d'entrée via evdev.
Il existe déjà un compositeur de référence pour Wayland qui répond au doux nom de Weston : il fait moins de 10 000 lignes de code et fait tourner la présentation de Kristian høgsberg au Fosdem. Néanmoins il est possible d'utiliser les compositeurs de X (mutter, kwin, enlightenment…) avec Wayland, moyennant des adaptations.
Pour les clients
La plupart des applications passent par l'intermédiaire de bibliothèque graphiques (GTK, Qt, EFL, SDL…) pour accéder aux fonctionnalités de X, il suffit donc de porter ces bibliothèques. Il y a cependant quelques différences avec X :
- Les applications ne peuvent pas monopoliser les touches. Avec X, une application pouvait demander à ce qu'elle soit la seule à recevoir les notifications du clavier, ce n'est pas possible dans Wayland. Mais les développeurs se sont rendus compte que c'était très peu utilisé, le cas d'utilisation principal est le menu déroulant car les applications veulent le faire disparaître si on clique ailleurs. Les développeurs préfèrent que l'application notifie le serveur que c'est un menu déroulant et le gérer en conséquence ;
- Les décorations de fenêtre sont à la charge des clients plutôt qu'au serveur³;
- Les applications ne peuvent recevoir que les coordonnées relatives dans la fenêtre et non pas les coordonnées globales sur l'écran. Le but est de résoudre le problème qui se pose lorsque le compositeur effectue une transformation sur la fenêtre. Par exemple, il peut lui faire subir une rotation de 45° ou l'appliquer sur une sphère. Encore une fois, cela peut poser des problèmes lors de l'affichage de menus qui pourraient sortir de l'écran mais le problème est connu et les développeurs réfléchissent à une solution. Cela posera problème si X est utilisé en tant que client de Wayland.
² : EGL et GLES2 sont une surcouche à OpenGL qui permettent d'accélérer le rendu.
³ : Il s'agit du comportement de Weston, mais pour les autres compositeurs le choix pourrait être différent (KDE a prévu de faire son propre compositeur http://blog.martin-graesslin.com/blog/2011/08/kwin-at-desktop-summit/)
Pour les pilotes
Weston, le compositeur de référence, a besoin de KMS et d'une pile EGL qui sont fournis par Linux et Mesa donc les pilotes basés sur Mesa et KMS.
Concrètement, les pilotes libre pour les cartes Intel, AMD et nVidia, fonctionnent avec Wayland. Pour les pilotes propriétaires, cela reste une inconnue.
Planning
Une première version de Wayland (0.85) est sortie le 9 février 2012. Kristian Høgsberg a fait part des buts à atteindre pour sortir une version 1.0, prévue fin 2012, comme la prise en charge des GPU multiples et l'affichage déporté.
Cette version assurera une stabilité des API (pas de retrait ni de modification de fonction) mais devrait sans doute nécessiter des ajouts. En parallèle, les compositeurs et les bibliothèques écrits originellement pour X vont continuer leur mutation pour pouvoir utiliser pleinement Wayland.
Après cette sortie, Wayland pourra être sérieusement intégré dans nos distributions GNU/Linux favorites.
L'utilisation éventuelle de Wayland par les *BSD serait plus difficile : Wayland utilise des APIs présentes uniquement dans Linux actuellement.
Aller plus loin
- Wayland (892 clics)
- FAQ sur Wayland concernant Ubuntu (313 clics)
- Une introduction à Wayland (384 clics)
- Conférence de Kristian Høgsberg au Fosdem (88 clics)
- Le premier article sur Wayland (106 clics)
- Wayland sera dans Ubuntu (336 clics)
# remote display
Posté par M . Évalué à 2.
Et le remote display, il disparait avec wayland ?
[^] # Re: remote display
Posté par ʭ ☯ . Évalué à 10.
Cherche "affichage déporté" dans cette belle depêche en français ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: remote display
Posté par Bruce Le Nain (site web personnel) . Évalué à 8.
Juste pour être sûr, ce qui est appelé Affichage déporté c'est ce qui s'appelle X forward dans certains clients SSH (ou l'option -Y de ssh) ?
[^] # Re: remote display
Posté par reno . Évalué à 9.
La réponse est compliquée:
1) en LAN, il y a plusieurs solutions:
a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.
b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".
c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).
2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
Mais pour les autres cas, la bande passante utilisée sera trop élevée.
Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..
[^] # Re: remote display
Posté par LaBienPensanceMaTuer . Évalué à -7.
Et il n'y a pas que la réponse ;)
Un comble pour un logiciel qui a pour objectif de "simplifier" les choses ;)
[^] # Re: remote display
Posté par delio . Évalué à 2.
Pour la situation b), il faudrait sur le client un serveur wayland qui écrit dans un un buffer à lui et qui envoie les buffers par le reseau.
Coté serveur, un client proxy qui ne fait que transmettre les buffers au vrai serveur.
Ca ressemble furieusement à du Vnc ou rfb :)
Pour la situation c), il me semble que le serveur wayland exisant sait déjà quasiment le faire puisque il peut s'utiliser en tant que client X.
[^] # Re: remote display
Posté par reno . Évalué à 4.
Oui.. Note qu'à l'heure actuelle Wayland ne transmet que des fenêtres complètes entre le client et le serveur donc ça ne sera pas très efficace, mais en LAN ça doit passer..
Oups, tu as raison j'avais oublié ça, un comble puisque c'est comme ça que Wayland a bootstrappé!
[^] # Re: remote display
Posté par reno . Évalué à 3.
C'était trop beau: je viens de lire un message d'un développeur Wayland que Weston était bien client X, mais uniquement en local.
Donc "presque" mais pas encore non.
[^] # Re: remote display
Posté par Gof (site web personnel) . Évalué à 2.
Est-ce que tu utilise tellement que ça le "remote display" ? Avec quelle type d'application.
Il sera toujours possiblie d'utiliser des trucs comme VNC or remotedesktop
Pour rappel, les toolkit come Qt par example, n'exporte que un seul "widget" X par fenêtre. Une grosse image, dont tout le rendu est fait par l'application Qt. Qt surveille aussi le mouvement de la souris, et à chaque fois que la souris bouge d'un pixel, Qt regarde où dans la fenêtre est le curseur, et ajuste le curseur de la fenêtre en fonction de l'endroit du pointeur.
Pourquoi? Parce que les styles actuels ne sont plus adapté a l'architecture de X pour laquel chaque petit élément à l'écran est sa propre fenêtre et ou le client envoit des opération de painting au server.
Donc, je crois que si il est vrai que wayland n'a pas vraiment le cas du remote display come cas d'utilisation principale, je ne crois pas que ça va être tellement pire qu'avant.
[^] # Re: remote display
Posté par jyes . Évalué à 10.
Personnellement, je ne sais pas comment ça fonctionne, mais je me sers tous les jours d’affichage déporté avec accélération graphique et ça marche ! C’est à dire que c’est la carte graphique de l’ordinateur qui affiche la fenêtre qui effectue le rendu. Cas typique d’utilisation, visualisation de résultats intermédiaires de simulation sans rapatrier les données, alors que la simulation tourne encore sur la machine de calcul.
Je ne vois pas comment Wayland pourra faire ça.
Après, peut-être que cette fonctionnalité n’est pas jugée primordiale, mais je ne vois pas l’intérêt d’enlever toutes les fonctionnalités de nos distributions Linux pour qu’elles ne fassent plus que ce que font les autres OS. Au début, j’étais très intéressé par Wayland, mais plus j’en apprends sur le projet, plus j’ai l’impression que ses concepteurs vont à contre-courant de ce que j’apprécie le plus au quotidien.
Autre exemple (pas une limitation forte de Wayland, mais ça montre l’état d’esprit de ses développeurs) : les décorations de fenêtres. Si ce sont aux fenêtres de dessiner elles-mêmes leur décoration, les différentes boites à outils graphiques produiront un résultat encore plus disparate à l’écran que le mélange FLTK/GTK/Qt d’il y a quelques années, dont l’allure générale était au moins unifiée par le gestionnaire de fenêtres. Et les fonctionnalités avancées de certains gestionnaires de fenêtres seront perdues aussi.
[^] # Re: remote display
Posté par claudex . Évalué à 7.
J'imagine très bien une couche intermédiaire entre le réseau et Wayland, c'est ce que fait Spice et il me semble que le rendu par la carte graphique locale est prévu.
« 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: remote display
Posté par Sébastien Koechlin . Évalué à 10.
Toutes les installations LTSP utilisent massivement l'affichage déporté puisque c'est le principe même de LTSP.
On installe beaucoup ça dans les écoles, dans les associations; il n'y a plus qu'un seul serveur à gérer et les besoins d'administration chutent vertigineusement.
[^] # Re: remote display
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Tout les jours, avec ssh ! Le truc que je fais le plus souvent c'est "ssh host terminator", une fois que j'ai un terminal sur une machine distante je peut ouvrir moultes shelles en ouvrant simplement des onglets ou en divisant la fenetre, sans demander une nouvelle connexion ssh !
Mais je fais aussi de la bureautique (firefox,
openlibreoffice...), J'ai aussi des petits utilitaires comme gsmartcontrol (parce que la sortie texte de smartctl j'ai un peu de mal), on peut faire sans en pure texte, mais pourquoi se priver si le remote display fonctionne ?Pour configurer un cups en le laissant écouter seulement sur localhost je n'ai qu'à faire un "ssh host midori http://localhost:631" ça marche ne lynx mais c'est moins pratique, on peut ouvrir à l'extérieur aussi, mais ça fait une ou plusieurs règles de fw à gérer (qui fait quoi).
Et avec les options Forward-machin-chose du ssh_config je n'ai pas à préciser le -X
Et encore, mon usage est assez limité à coté de celui avec qui je travaille, 95% de ses fenêtres n'appartiennent pas à des programmes exécutées sur sa machine (il doit rester le panel en fait).
Ah oui, souvent je fais du XDMCP aussi, ce qui ne m'empêche pas d'avoir en même temps des tas de fenêtres d'autres machines, ce qui fait que le serveur X est exécuté la machine sur le bureau, le gestionnaire de fenêtre et quelques fenêtres exécutés sur un serveur, et au milieu de tout ça d'autres fenêtres d'autres machines. C'est donc un joyeux bazar, mais ça marche et c'est super pratique.
(troll: j'ai pas trouvé le sélecteur XDMCP dans gdm3, y a quelqu'un qui sait où c'est ?)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: remote display
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Et sur les windows j'utilise Xming+putty ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: remote display
Posté par paipai62 . Évalué à -1.
Cela dit remplacé le vieux XDMCP par SPICE serait une grande avancée!
[^] # Re: remote display
Posté par spider-mario . Évalué à 1.
Ce n’est vrai qu’avec le système graphique raster de Qt, qui n’est pas le système par défaut.
[^] # Re: remote display
Posté par Gof (site web personnel) . Évalué à 5.
C'est le système par défaut maintenant, sur toute les platformes. Bienvenue en 2012 :-)
Et même avant: les fenêtres ne sont plus composées de widgets individuels depuis Qt 4.4 (2008)
# Migrations libres
Posté par ʭ ☯ . Évalué à 5.
Encore une fois, le libre va montrer qu'il sait abandonner des cathédrales devenues inutiles, pour passer à des outils plus adaptés à l'informatique du moment.
Chez la concurrence, cela s'est fait au prix de la perte forte de logiciels : chaque fois que Windows a changé profondément son système d'affichage, beaucoup d'anciennes applications cessaient de fonctionner. Et comme c'est propriétaire, elles sont mortes. J'en ai quelques CD-ROMs pour les dubitatifs.
Dans le libre, l'ecosystème suit mécaniquement : le code est là, prêt à être adapté. Seuls les logiciels propriétaires pour Linux laissent le doute, avec des abandons brutaux comme pour le pilote propriétaire ATI qui en 2008 a jeté le support des modèles de cartes graphiques encore vendus (X1250, expérience personnelle) pour le dernière version de X.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Migrations libres
Posté par Zenitram (site web personnel) . Évalué à 9.
Le fait que ce soit libre ne veut pas automatiquement dire que tu pourras l'utiliser ton logiciel.
Quand une sous-couche change, on a :
- proprio : si le développeur est intéressé de continuer, il adaptera
- libre : si un développeur est intéressé de continuer, il adaptera. Un utilisateur non développeur qui ne veut pas payer des milliers d'Euros pour payer un développeur car personne n'est intéressé pour le faire gratos, son appli mourra aussi (il y a un paquet de logiciels libres abandonnés au fil des versions de distros car personne n'est motivé pour les maintenir). Il y a un peu plus de chances de trouver un développeur que le développeur, mais ça ne garantit rien.
De plus, les logiciels libres peuvent très bien tourner chez la concurrence : chaque fois que Windows a changé profondément son système d'affichage, beaucoup d'anciennes applications libres peuvent très bien être aussi adaptées. Quel avantage de Linux? Aucun : les logiciels proprios ont du mal, les logiciels libres peuvent être adapté. Aucune différence entre un OS libre ou pas libre, seule la licence de l'application est importante, et du proprio peut très bien être sur Linux (donc casse) et du libre être sur Windows (donc s'adapte). Dans les deux cas d'OS tu perds autant, la licence de l'OS n'a pas d'importance. Au final, en pratique, si un logiciel est encore utilisé et qu'il vaut le coup, il sera porté, qu'il soit proprio ou libre, le libre ajoutera une infime part de logiciels qui n'ont pas d’intérêt pour l'auteur original mais un intérêt pour un autre développeur, mais ça restera l'exception.
Ton commentaire n'est pas particulièrement faux, mais il sous-entend "avec Linux tout est génial" plus que la réalité, donc je me permet de mettre quelques bémols : oui, le libre c'est mieux, mais non tout ne se fait pas par magie et la concurrence OS fermé ne change pas grand chose sur l'adaptation des applis. Il y a aussi plein d'applis proprios sous Linux et elles dépendront de la bonne volonté de leur auteur, il y a plein d'applis libres qui ne trouveront aucun développeur intéressé par le portage, ça cassera aussi, pas beaucoup moins que sous Windows. Casser une API est toujours problématique.
[^] # Re: Migrations libres
Posté par zul (site web personnel) . Évalué à 8.
Tu parle d'une solution qui va réduire / détruire tout l'écosystème Unix en dehors de Linux là ? :D Mais sinon, l'analyse est hum... pertinente :D (on me souffle qu'il n'existe rien en dehors de l'écosystème Linux, tout s'explique ...)
[^] # Re: Migrations libres
Posté par coïn . Évalué à 10.
On perd la portabilité, on va patcher à mort les toolkits et donc créer une période d'instabilité pendant 2 ans minimum. On perds probablement les drivers "proprio" qui ont quand même le bon gout d'exister quand les drivers libres mettent presque 10 ans avant d'arriver (comme nouveau)
Tout ça pour quoi ? un nouveau système linux-only, qui ne sera pas plus rapide. Et alors qu'il reste des tonnes de chantiers ouverts pour avoir un desktop libre correcte.
Désolé, mais parfois, le bazaar est juste désespérant.
[^] # Re: Migrations libres
Posté par fredix . Évalué à 8.
En effet quitte à pousser un desktop libre autant pousser Haiku qui est conçu pour cela, et vivement qu'il intègre une gestion des paquets.
[^] # Re: Migrations libres
Posté par reno . Évalué à 6.
Un desktop Haiku restera certainement beaucoup plus réactif qu'un desktop Linux (même avec Wayand), mais Haiku a fait l'énorme erreur d'utiliser un noyau (NewOS) très peu utilisé plutôt que Linux ou FreeBSD alors non merci: à cause de ce choix, il est quasiment sûr qu'Haiku n'atteindra jamais la "masse critique".
Les développeurs de Wayland n'ont pas fait cette erreur eux..
[^] # Re: Migrations libres
Posté par fredix . Évalué à 2.
Pour un OS desktop, NewOS n'aurait pas des avantages ? Bon c'est sur un terme de drivers c'est plutôt mort face à Linux. Mais si une partie du serveur graphique est intégrable dans NewOS j'y vois un gros avantage en perf car ça n'arrivera jamais avec Linux.
[^] # Re: Migrations libres
Posté par reno . Évalué à 2.
C'est le cas? Coté doc je n'ai rien trouvé..
Sinon pour répondre à ta question: avec le Linux 'standard' non, mais qui t’empêche de faire ton propre patch?
C'est du travail bien sûr, mais créer/porter tout les autres drivers à mon avis ça réprésente bien plus de travail..
[^] # Re: Migrations libres
Posté par fredix . Évalué à 4. Dernière modification le 21 février 2012 à 14:04.
Dans les In-Progress features je vois GUI ce qui laisse supposer des choses. Pour les drivers je suis d'accord avec toi, il faudrait avoir le retour d'un dev de haiku pour juger de la pertinence de ce noyau. Sinon lorsque j'ai testé Haiku je l'ai trouvé exploitable, avec navigateur web, client IRC graphique, etc. Il me semble très avantageux pour le libre qu'il existe des alternatives basées sur d'autres technos.
[^] # Re: Migrations libres
Posté par nud . Évalué à 5.
Alors plusieurs petites choses:
Par contre oui, y'a des applications qui attaquent directement X pour certains trucs, en particulier en Gtk (apparemment la pratique est très rare avec Qt, probablement parce que les gens qui font du Qt s'intéressent davantage à avoir une application portable). Et oui, les drivers X11 propriétaires seront probablement pétés. J'imagine que les drivers propriétaires qui vont directement dans le noyau seront épargnés?
[^] # Re: Migrations libres
Posté par gato . Évalué à -3.
Ce Sidi, ils viennent de supprimer le serveur X dans Mac OS 10.7 ... histoire d'enfermer un peu plus leurs utilisateurs.
[^] # Re: Migrations libres
Posté par spider-mario . Évalué à 4. Dernière modification le 21 février 2012 à 21:13.
Ce que j’ai compris, c’est qu’ils vont enlever leur X11.app (basée sur XQuartz) de l’installation par défaut et encourager l’utilisation directe de XQuartz à la place.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Coquille
Posté par lolop (site web personnel) . Évalué à 1.
"vouloir utiliser Wayland à la place de X.Org pour son système d'exploitation" ou alors je n'ai pas compris ce qu'est wayland :-)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Vous pouvez m'éclairer ?
Posté par Paul Chavent (site web personnel) . Évalué à 4.
Bon, de ce que je comprend de tout cela, c'est que Wayland désigne le protocole entre les clients et le serveur, c'est ça ? Mais aussi l'API avec les compositeurs.
On aura plusieurs implémentations possibles de compositeurs.
Est-ce que les flèches 1 et 4 sont définies par le protocole wayland ou seulement les flèches 2 et 3 ? Je suppose quand même que ces flèches sont imposées par l'api de l'os. Du coup pourquoi ne pas les brancher sur les compositeurs... Du coups wayland serait plus portable, charge au compositeur de faire l'interface avec son hôte.
En gros on a quand même un truc comme ça ?
[^] # Re: Vous pouvez m'éclairer ?
Posté par Corentin Chary (site web personnel) . Évalué à 3.
Non pas du tout. Le protocole wayland est utilisé en (2) et (3), le compositeur est en fait un "serveur wayland". (1) et (4) sont les API Linux/Unix "normales". Ce qu'il manque par contre ici c'est l'API utilisée pour partager les buffers entre client et compositeur (OpenGL, shared memory, ou autre...)
[^] # Re: Vous pouvez m'éclairer ?
Posté par reno . Évalué à 2.
Non! Pour que Wayland soit utile, il faut utiliser une API qui permette de partage la mémoire du GPU entre le client et le compositeur (GEM il me semble), autrement tu te retrouves avec le cas suivant: le client utilise le GPU pour rendre son application dans un buffer du GPU puis il faut lire le buffer du GPU pour le mettre en mémoire principale (lent) et ensuite le recopier de nouveau sur le GPU pour le "composer" et l'afficher: autant utiliser X car ça tue les performances..
Sinon d'accord avec toi, il n'y a pas d'API entre le serveur d'affichage et le compositeur: le serveur d'affichage est le compositeur.
Dommage d'ailleurs que ça n'ai pas été fait pour X: rien dans X n'impose d'avoir le serveur d'affichage et le compositeur séparé, certes c'est plus modulaire mais à mon avis dans ce cas là ce n'est pas une bonne chose.
[^] # Re: Vous pouvez m'éclairer ?
Posté par Corentin Chary (site web personnel) . Évalué à 3.
Pourquoi "Non !" ? Oui, si t'a une méthode accélérée et zero copy, c'est mieux, mais il se trouve que toutes les cartes ne sont pas supportées pour l'instant, et donc la mémoire partagée au moins ça marche toujours, surtout si en plus tu fais le rendu en software avec uniquement le CPU :).
[^] # Re: Vous pouvez m'éclairer ?
Posté par reno . Évalué à 2.
OK pour une solution de repli, mais il faut espérer que peu d'utilisateurs seront dans ce cas car il se peut que leur système soit alors moins performant qu'avec X!
# Wayland / X
Posté par lolop (site web personnel) . Évalué à 9.
C'est dommage pour le libre.
Ça permettra aux applications X de continuer à tourner, c'est déjà ça.
Wayland est-il limité au niveau portabilité par l'utilisation de services spécifiques du système Linux, ou bien simplement par l'utilisation d'API spécifiques à Linux pour des services qui existent ailleurs avec d'autres interfaces de programmation ?
Dans le second cas un effort d'abstraction serait je pense bienvenue, afin que les applications "natives Wayland" ne soient pas cantonnées à Linux.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Wayland / X
Posté par claudex . Évalué à 2.
Ça dépend notamment de KMS qui n'existe, pour le moment que sous Linux. Mais je pense qu'on pourrait imaginer un compositeur qui utilise autre chose mais il faudrait que quelqu'un le développe.
« 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: Wayland / X
Posté par zul (site web personnel) . Évalué à 10.
En même temps, ça fait malheureusement un certain temps que les *BSD ne sont plus capable de faire tourner X avec une carte graphique "moderne" (quelque soit le constructeur), car les drivers libres supportant ces cartes modernes nécessitent des API obscures linux-only (KMS, TTM, GEM, DRIx, et tous les autres acronymes que j'oublie) (obscures parce que sans spécifications / documentations). On a donc beau jeu de critiquer le monde propriétaire quand il livre des immondices sans specs : l'éco système linux fait la même chose, le signe qu'il sera bientôt prêt pour le desktop ? :D
Y'a k'a fo k'on qu'ils diront :D
[^] # Re: Wayland / X
Posté par goom . Évalué à 6.
il me semble que nvidia fournisse toujours des drivers, proprio, pour freebsd et pour les cartes graphiques les plus récentes de ce constructeur.
Certes c'est pas libre mais c'est à jour
[^] # Re: Wayland / X
Posté par LaBienPensanceMaTuer . Évalué à 5.
C'est ici que réside la différence entre un développeur bénévole et un développeur rémunéré: le bénévole ne fera que ce qui l'intéresse (et on voit rarement des développeurs aimer la doc), le salarié lui fera ce pour quoi il est payé, doc comprise ...
[^] # Re: Wayland / X
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Ça marche aussi dans l'autre sens : un bénévole fera ce qui l'intéresse avec passion, alors qu'un salarié fera souvent juste ce qu'il faut pour être payé. Le cas typique, ce sont les extensions de protocole (SMTP, XMPP…) : un bénévole les implémentera volontairement parce que son but est de faire un logiciel qui roxxe, alors qu'un salarié les implémentera si son patron lui demande, ce qu'il ne fera lui-même que si un client lui demande.
[^] # Re: Wayland / X
Posté par LaBienPensanceMaTuer . Évalué à 10.
Juste une petite précision ...
Être professionnel et rémunéré pour du code n'est pas incompatible avec être passionné ...
Quand je développais en tant que salarié, mon "amour du travail bien fait" ne me quittait pas en rentrant au bureau hein :)
En résumé, tout les salariés ne font pas que "juste ce qu'il faut pour être payé".
[^] # Re: Wayland / X
Posté par ckyl . Évalué à 2.
En même temps si personne ne le demande c'est peut être que tout le monde s'en fou ? Donc le bénévole aura volontairement implémenté un truc totalement inutile. Cool !
Bref c'est la même chose quoi. Si tes intérêts d'utilisateurs ne sont pas les même que ceux de celui qui défini le produit, bin au final ca répond pas à tes besoins... Le bénévolat n'a rien de magique.
[^] # Re: Wayland / X
Posté par zul (site web personnel) . Évalué à 5.
KMS le premier développeur c'est Intel
TTM le première développeur c'est VMWare/tungstengraphics ...
Donc ce sont des gens payés pour faire ça. Mais bon, ce ne sont pas des philanthropes, ils en ont probablement rien à faire du reste de l'écosystème Unix. Linux n'est plus depuis longtemps un noyau de hobbistes.
[^] # Re: Wayland / X
Posté par glisse . Évalué à 6.
Les API soit disant obscures ... sont on ne peut plus simple, et le code est la meilleur documentation. Vraiment n'importe qui capable de faire un driver GPU peut comprendre tous ces API en moins d'une journee en lisant le code. Et rien n'oblige *BSD a utiliser les memes.
TTM & GEM c'est des memory manager, leur API c'est un id u32 pour identifier chaque buffer, pas besoin d'ecrire une doc pour ca.
KMS c'est xrandr dans le noyau, tu prends la docs d'xrandr et voila.
DRI* c'est un protocol propre au server X qui permet a une application d'utiliser directement le buffer d'une pixmap pour faire son rendu. C'est utiliser principalement par OpenGL. Ca permet a une application de faire le rendu opengl directement (d'ou Direct Rendering Infrastructure) au lieu d'envoyer les commandes opengl au serveur X (indirect opengl rendering). DRI* encore une fois c'est simple en gros c'est comment obtenir le u32 qui identifie de maniere unique un buffer avec le kernel memory manager (TTM/GEM).
Voila la doc tu l'as, maintenant faut plus pleurer !
http://www.youtube.com/watch?v=vQDCUnXNJrA
[^] # Re: Wayland / X
Posté par zul (site web personnel) . Évalué à 9.
C'est pas vraiment ce que j'appelle une spécification. Une spécification, c'est un truc qui indique un peu clairement les pré-conditions, les post-conditions, les effets de bords, les types d'erreurs, et les états possibles dans lesquels on peut se retrouver en cas d'erreur. Mais bon, si c'est un u32 pour identifier chaque buffer, ça va, on est sauvé :) (u32 n'est même pas un type C valide, je suppose que tu veux dire uint32_t comme introduit dans C99 ?).
Bof, le code te montre une implémentation, et ne définit pas ce qui devrait être implémenté. En voyant le code, tu ne peux pas savoir si typiquement les structures utilisés ont un impact fort sur le comportement escompté ou si c'est juste "une façon de l'implémenter". Tu ne peux pas savoir si ils ont oublié des cas d'erreurs (vu qu'il n'y a pas de specs), ... Non, le code ne vaut pas une spécification. Et puis en plus y'a l'aspect GPL infection pour tout le code qui traîne dans le noyau, faut pas trop regarder de peur de s'y brûler les yeux, et prendre un procès entre gens du libre.
C'est vrai, on pourrait proposer des supers nouvelles interfaces, et puis réécrire tous les drivers pour les réutiliser. C'est tellement efficace comme approche, surtout vu comment c'est simple d'écrire un driver pour une carte graphique moderne. Le dernier patch pour le support des cartes Intel dans FreeBSD, il ne fait que 2Mo (de patch). Une bagatelle ...
[^] # Re: Wayland / X
Posté par glisse . Évalué à 8.
On peut jouer a ce jeux longtemps ;) Moi j'aime bien jouer :)
Ecrire des specifications comme par exemple celle d'opengl ou du c99 pour TTM/GEM/KMS ... n'a aucun sens. Fondamentalement le coeur de TTM/GEM/KMS n'a pas cesse de changer. Mais l'interface expose est toujours la meme. Un simple uint32_t (et voila je peux meme plus faire le feignant et utiliser u32) qui identifier de maniere unique un buffer pour TTM/GEM et un moyen de mmap a partir de cette uint32_t. C'est tout ce que demande l'userspace.
Sincerement je crois que tu as passe trop de temps a faire du management de projet et autre truc .... (je me censure).
Par ailleur je tiens a preciser que tout le code TTM/GEM/KMS est double license GPL/BSD. Donc oui vous pouvez regarder le code et meme le copier.
Vraiment demander une doc c'est de la mauvaise foi. C'est pas dure a comprendre tous ce code. Le probleme c'est que le memory management des *BSD est different et qu'il faut une personne qui comprenne le code gerant la memoire dans le noyau *BSD (a propos elle est ou la doc pour ca ?)
Faut pas avoir peur de la taille du code des drivers GPU. Le modesetting prend bcp de
place et c'est pas complique.
Je soutiens qu'une personne capable d'ecrire un driver GPU n'aura aucun mal a porter vers un BSD et qu'aucune documentation au monde ne servira. Vraiment ecrire la doc prendrer plus de temps que d'ecrire le code.
[^] # Re: Wayland / X
Posté par zul (site web personnel) . Évalué à 3.
Parfait, je veux bien te croire, je n'ai parcouru que très superficiellement le code de drivers/gpu/... Mais connaissant quelques développeurs X, et vu comment les projets BSD ont du mal à arriver à merger un driver pour une carte graphique moderne, j'ai quand même tendance à penser qu'il y'a un problème quelque part (évidemment, on peut supposer que les développeurs BSD sont des gros nuls, mais je ne suis pas convaincu par cette hypothèse).
C'est vrai :) C'était une pique gratuite pour les fois où j'essayé de debugger les drivers des cartes wifi intel. Dans le cas des interfaces gpu, ils ont eu le bon goût de garder un peu de cette bonne vieille license BSD.
Sinon, la doc des interfaces noyal mémoire de NetBSD est sur http://netbsd.gw.com/cgi-bin/man-cgi?memoryallocators+9+NetBSD-current (et ses copains uvm(9), pmap(9), vmem(9) ...). C'est clairement pas aussi précis que ce qu'on pourrait espérer mais c'est toujours bien mieux que "rien" ("prendre un uint32_t et magie" :)).
[^] # Re: Wayland / X
Posté par glisse . Évalué à 5.
Le probleme viens principalement du fait que ttm/gem a de gros besoins sur comment marche le memory management du noyau linux a des api pour tous ces trucs. La derniere fois que j'ai regarde un noyau bsd (5 ou 6 ans maintenant). Il y avait presque rien c'etait vraiment pas concu pour marcher comme on le veut. Bref il semblait necessaire de devoir d'abord travailler sur le corps du noyau bsd avant de pouvoir implementer un des memory manager. Mais je pense que le travail qui a ete realise pour avoir les driver nvidia a probablement bcp change les choses.
En gros on a besoin de tous ce qui est decrit dans ce mail et probablement un peux plus parcequ'on fait certaine chose differement de nvidia.
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
[^] # Re: Wayland / X
Posté par Guillaume Knispel . Évalué à 2.
Euh c'est en fait pire que ça. Le monde propriétaire à bien souvent l'habitude de livrer des immondices certes, mais habituellement AVEC specs.
[^] # Re: Wayland / X
Posté par zebra3 . Évalué à 0.
Il n'y a pas que les BSD, rien que sur Linux ça peut être problématique : pour les cartes non prises en charge par KMS (comme les S3 et les via), on fait comment ? Parce qu'au moins avec X, toute carte peut fonctionner même si elle n'a pas d'accélération graphique.
C'est l'avantage d'utiliser des couches (serveur X vs compositeur) plutôt que des outils unifiés, et c'est aussi pour cela que je n'aime pas btrfs par rapport à LVM/Device Mapper/Cryptsetup/Ext3/NFS.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Wayland / X
Posté par claudex . Évalué à 2.
Il suffira d'utiliser un compositeur qui ne nécessite pas de KMS.
« 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: Wayland / X
Posté par zebra3 . Évalué à 0.
Question idiote : c'est prévu ?
Nan parce que les « il suffit », ça reste des promesses.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Wayland / X
Posté par claudex . Évalué à 2.
Il faut attendre de voir les premiers portages massifs d'application avant d'avoir une idée un peu plus précise de ce qui va réellement se passer. Il me semble que le premier proof-of-concept de Wayland était un client X, ça ne devrait pas être trop compliqué en tout cas. Mais pour l'instant tout ce qui est prévu, c'est une version 1.0 implémentée par Weston mais ce n'est qu'une première étape.
« 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: Wayland / X
Posté par zebra3 . Évalué à 2.
Oui, il va déjà falloir attendre la 1.0. Peut-être que tous ces choix vont évolués de toute manière.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Wayland / X
Posté par reno . Évalué à 4.
Euh non, ça permettra aux applications GTK, Qt (etc) de tourner, mais pour les applications pure X (il y en a peu OK) il faut installer un serveur X/client Wayland pour la compatibilité: pas de problème ça existe déjà.
Pour ta seconde question, il n'y a pas actuellement l'équivalent de KMS sur les *BSD (pas sûr pour les autres API), mais je pense que ça viendra: ne serait-ce que pour pouvoir éviter d'avoir X en tant que root c'est intéressant.
[^] # Re: Wayland / X
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Pour FreeBSD, il y a des choses, en chantier : [http://wiki.freebsd.org/Intel_GPU]
# Fenêtre
Posté par Anonyme . Évalué à 4.
J’ai peut-être mal compris, mais depuis que j’entends parler de WayLand, j’ai l’impression qu’il s’agit d’un système ou chaque application dessine elle-même sa propre fenêtre.
Du coup, j’ai l’impression qu’on va se retrouver comme sous Windows ou il n’y a aucune intégration entre les applications (même les applications du système ne sont pas intégré entre-elle).
Dites moi que je me trompe !
[^] # Re: Fenêtre
Posté par Frank-N-Furter . Évalué à 10.
Tu te trompes.
Depending on the time of day, the French go either way.
[^] # Re: Fenêtre
Posté par Corentin Chary (site web personnel) . Évalué à 7.
Les "client side decoration" font en effet partit du plan, mais c'est censé être uniformisé/standardisé par les toolkits, reste à voir ce que ça va donner.
[^] # Re: Fenêtre
Posté par Anonyme . Évalué à 9.
Si c’est à la charge des toolkit, GTK va encore faire de la merde et n’être compatible avec rien et, alors, Qt devra se retaper la compatibilité…
[^] # Re: Fenêtre
Posté par claudex . Évalué à 9.
Pour les décorations, ça dépendra du compositeur. Je cite la dépêche:
Pour l'intérieur de la fenêtre, chaque application fait déjà ce qu'elle veut avec X.
« 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: Fenêtre
Posté par jeberger (site web personnel) . Évalué à -6.
C'est génial, ça veut dire que si je veux que mon appli soit utilisable sous Weston, il faut que je dessine les décorations moi même, mais ensuite si l'utilisateur fait tourner l'appli sous KDE elle aura les décorations en double (les miennes plus celles de KDE). Trop cool!
[^] # Re: Fenêtre
Posté par claudex . Évalué à 3.
Non, ça veut dire que Kwin ne mettra pas les décorations que tu as dessiné mais les siennes.
« 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: Fenêtre
Posté par reno . Évalué à 2.
Pas forcément si simple: comment Kwin connaîtrait les décorations que tu as dessiné si le client envoi juste un buffer?
Pour moi, le plus simple est qu'il y ait une extension du serveur qui dise "ne dessine pas les décorations de la fenêtre".
[^] # Re: Fenêtre
Posté par claudex . Évalué à 2.
Je ne connais pas le protocole mais à mon avis, il y une api pour dire "voilà mes décorations" et une autre pour dire "voilà le contenu"
« 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: Fenêtre
Posté par reno . Évalué à 4.
Je l'ai lu moi et il me semble que ça n'existe pas non.
Il y aura juste une API pour que le client indique ou se trouve le bouton pour fermer la fenêtre afin qu'un serveur puisse tuer un client non-réactif, c'est tout.
[^] # Re: Fenêtre
Posté par claudex . Évalué à 2.
La version 1 n'est pas encore sortie non plus.
« 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: Fenêtre
Posté par Jux (site web personnel) . Évalué à 8.
Ca ne risque pas de changer d'après les dicussions sur la liste de développement :
http://lists.freedesktop.org/archives/wayland-devel/2011-May/000988.html
Pour résumer, d'après les dev Wayland, c'est plus simple de laisser les applications dessiner les bordures de fenêtres.
Ils citent l'exemple de Gimp qui a dû revenir à une seule fenêtre car les window manager ne permettaient pas de bien gérer les multiples fenêtres. Ils disent aussi que Chrome et divers jeux vidéos / lecteurs multimédia ont leurs propres décorations sur Windows et que ça n'embête pas les utilisateurs. Ceci dit, il semble que le serveur pourra dire au fenêtre de dessiner ou non les décorations (donc on peut implémenter un WM tiling qui dira simplement "ne dessinez rien").
Maintenant, à mon avis, c'est une connerie de laisser les applis dessiner leurs décorations, particulièrement sous Linux où la culture des différents WM est bien implantée (contrairement à Windows et Mac). Mais bon, on verra..
[^] # Re: Fenêtre
Posté par Olivier LAHAYE (site web personnel) . Évalué à 4.
Pour moi, Wayland est une connerie tout court. On réinvente la roue carré au lieu d'améliorer le pneu....
o Quid des applications qui plantent? On ne peut plus bouger la fenêtre......
o Quid de l'optimisation des SPANS pour tracer les pixels dans la carte graphique de manière optimisée est en droppant les doublons?
o Quid du protocole asynchrone qui permet de dropper les évènements redondants ou inutiles (genre afficher un texte derrière un élément graphique ou encore 2 paints de suite dans 2 couleurs différentes (comme par exemple le tracé des fenetres sous WinXP qui quand on le fait ramer permet de constater qu'il trace 3 fois la fenêtre quand on l'active. une fois en bleu, puis il écrit le titre, une fois en gris et il réécrit le titre et une nouvelle fois en bleu! Yes! ça c'est performant.
En même temps on s'en fout, on a des CPU hexacoeurs dans nos PC avec des cartes 3D digne d'un simulateur de l'arméee américaine des années 2000... alors...
o Quid de l'uniformité de la décoration des applications. Genre sur PC, on a itunes avec sa déco mac, winamp avec ses thèmes, des trucs plus ou moins farfelu, et ça, c'est dans un environnement qui ne favorise pas ce genre de truc. Ici sous linux, on voi tout de suite le délire de chanque développeur plus axé sur le DeZigN! que sur l'application elle même.... J'imagines même pas....
o Quid du remote display qui meme s'il est possible N'EXISTE PAS et RESTE A DEVELOPPER.
o Quid de l'impact de travail ENORME reporté sur les développeurs d'application et qui devront PORTER leur application.. Temps perdu en portage et debuguage au détriment de nouvelles fonctionalités.....
Tout ça me fait penser au projet Berlin......(http://sourceforge.net/projects/berlin/)
Quelle perte de temps!
Alors qu'il eut été si simple de faire X12 compatible X11 avec abandon des trucs inutiles....Mais non, il faut réenventer en faisant moins bien et différent pour montrer qu'on a fait un truc...
Enfin bon, pas grave, d'ici à ce que ce soit répendu avec les applications portées, on aura tous des iPad LOL. Perdez votre temps à réinventer la roue, pendant ce temps vos concurents avancent....
[^] # Re: Fenêtre
Posté par houra . Évalué à 5.
Quid des applications qui plantent sous X obligeant à relancer le serveur X ?
Je pense en particulier à World of Warcraft lorsqu'on essaie de switcher sur une appli non OpenGL et de revenir sur l'application OpenGL.
Les utilisateurs de soft 3D gros bouffeurs de cartes graphiques sont les premiers concernés par les limites actuelles de X. Que faire pour corriger le problème, dans l'état actuel des choses ?
Dans laquelle des 2 cartes graphiques ? Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature " ... Faut voir.
Bonne question. Je suppose qu'il y a matière à réfléchir. Tu parles des fenêtres tracées par le toolkit, celui-ci se bornant à envoyer des pixels à X, ou de celles de plus en plus rares tracées par X ? Ou alors comme j'ai pu le constater à plusieurs reprises, le dessin des bordures de fenêtres fait par X ( avec le " thème " de X ), redessiné par Gnome-2 par dessus ( avec le thème par défaut ), puis redessiné par le compositeur ? Ou pire, sur Ubuntu 11.10, si on fait une connerie en tentant de remettre Compiz, on se retrouve avec une fenêtre sans barre, un bureau vide ( ! ) et aucune action possible par les raccourcis claviers ? Tu me diras, ça, c'est de l'administration, pas de l'usage, et je suis d'accord à 100% , n'empêche que ce genre de problèmes de chevauchement des différents compositeurs actuels et des coquilles graphiques est de plus en plus problématique.
Alors le tout-venant, il peut pas jouer en 3D, il peut pas modifier son bureau, il peut pas utiliser son PC disposant de deux cartes graphiques. Continuons.
Ben je suppose que Gnome-3.X pour Wayland utilisera les mêmes standards que Gnome-3.X aujourd'hui. Enfin, il me semble, hein... Pour l'instant, on peut rien dire.
Dans l'état actuel des choses, X fonctionne parfaitement. Je suppose que lorsqu'Ubuntu utilisera Wayland par défaut, la question se posera, ou pas, parce que ça existera.
J'imagine que le serveur d'applications distant n'utilisera pas Wayland avant très très longtemps, hein... Et je suppose que dans les " c'était mieux à vent ", des rigolos vont permettre d'installer X sous Linux et des distributions Linux utilisant X et non Wayland vont exister en concurrence de celles qui n'utiliseront que Wayland+ X en tant que client de Wayland.
Je suppose.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé. Les applications ont-elles cessé de fonctionner du jour au lendemain ? Non !
Certaines applis utilisent encore la XLib, c'est certain. Et pour celles-ci, c'est mal barré. Mais ce n'est pas le cas de la très grosse majorité des applications existantes, fort heureusement. D'autant plus que la XLib aurait de toutes façons dû disparaître pour être remplacée par XCB ( mort-né ? ).
moui quelle perte de temps. 10 ans que les applis OpenGL plantent, 4 ans que les premiers ordis OPTIMUS sont sortis, 2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 4.
_Quid des applications qui plantent sous X obligeant à relancer le serveur X ? _
Elles claqueront pareil sous Wayland, a moins que l'on modifie complètement toute l'architecture sous-jacente DRI/Pilote graphique. Ce n'est pas un problème de Xorg/XFree, encore moins un problème de X11R6 - c'est juste que les cartes graphiques grand public ne sont pas prévue pour gérer les switch de context autrement qu'à la sauce windows. Après la carte graphique se bloque, et X ne peut plus rien y faire.
Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature "
X11R6 incompatible par nature avec la gestion de plusieurs applis chacune sur carte graphique différente, voire plusieurs machine différentes ? Faut le dire vite à SGI. La force de X11R6 est justement qu'on peut gérer chaque sous fenêtre d'une appli depuis une source différente, du moment que ça peut pondre un "drawable" ça marche. Et sinon c'est pas les extensions de bypass et d’accès direct qui manquent.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
Tu es passé à coté du problème. Bien sur la mise à jour ne vas pas se faire en trente secondes, mais il y a quand même un vrai problème : si il est acceptable que Wayland puisse pendant une période de transition utiliser un wrapper X11, c'est un luxe que ne vont pas trop pouvoir se payer les logiciels de prise de main à distance, à moins de vouloir rendre leur code très complexe. Donc soit on lance un serveur Wayland complet pour chaque prise de main, soit il faut que les applis elle même soient bi-compatibles X/Wayland. J'y crois moyen. Pendant tout un temps on aura des prises de main à distance sauce wayland pour lancer des applis wayland et des prises de main à distance sauce X11 pour lancer des applis X11. Ca me fait saliver d'avance.
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé.
Ou comme quand Fleury Michon a mis moins de sel dans son jambon à l'os ou comme quand Pluton n'a plus été considéré comme une planète...
Tu as idée de la différence de surface qu'il y a entre X11R6 et ses différentes révisions/implémentation et le EXA ? Tu ne vois pas la différence qu'il y a entre "certains pilote libre n'auront plus d’accélération graphique" et "Il faut recompiler toutes les applications graphiques en mettant à jour toutes les libs grpahiques et en priant pour qu'il n'y ait pas trop de code à réécrire."
Non sincèrement. Toutes les autres applications que tu cites sont optionnelles. Si je ne veux pas m'en servir, ben je m'en sers pas et ça roule pareil qu'avant. Si vraiment je veux absolument utiliser DBus au lieu de /proc ou EXA au lieu de XAA j'ai un endroit dans le code à modifier pour le faire (si mon code est propre).
Avec Wayland, une application graphique doit gérer la souris, la saisie, les décorations de fenêtres, les buffers Wayland etc. Le tout en cassant tout le code d'affichage précédent. Je n'ai pas vu de système de gestion de souris ou de gestion de décoration de fenêtre dans GTK. Donc même si mon code GTK aujourd'hui est très très propre (grosso-modo je n'ai pas un seul widget perso, pas une surcharge de (pseudo)classe, pas un accès direct à des buffers vidéos), il faudra quand même que je recode le tout. Et personnellement je doute fort que GTK2 et QT3 passe à Wayland, et pourtant j'ai pleins d'applis GTK2 et QT3 que j'aime bien.
Certaines applis utilisent encore la XLib
Oui quelques unes. XLib, XMotif ou TK, ca doit faire quoi 75/80% du parc existant grand maximum. Une paille. Il y a pas que le Desktop de hobbyiste dans la vie.
moui quelle perte de temps. 10 ans que les applis OpenGL plantent
Et 20 ans que SGI ne s'en est pas rendu compte.
4 ans que les premiers ordis OPTIMUS sont sortis
Ca c'est l'argument qui tue. C'est clair, dès que le Desktop Linux va passer sous Wayland, NVidia va libérer les specs des hold buffers. Mais attention elle ne va les libérer que pour Wayland, interdiction de les utiliser pour xorg.
2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien
C'est clair que Wayland a reçu le soutien massif des devs X11 et du X consortium en général. Bon la plupart des devs X11 et des membres du X Consortium sont chez Intel c'est pour ça que ça se voit pas trop. Mais c'est massif comme mouvement.
[^] # Re: Fenêtre
Posté par houra . Évalué à 3.
euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Un patch pour X un jour ou ... pas ?
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes, ya moyen de corriger ce problème ou " toujours pas " ( par exemple en utilisant quelque chose comme screen en version graphique ) ? Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Rappel ma question était :
Non ! Le sera-t-il un jour ?
Non !
Tout le monde sait que X est capable d'utiliser 1 serveur par application, et même une fenêtre par " élément dessinable " comme un onglet Firefox ou une zone Flash dans une page Web. Tout le monde sait que l'élément " serveur X " peut utiliser l'une ou l'autre des 2 CG , et avec le patch " fenêtre ", chaque " fenêtre " peut faire de même.
C'est juste que c'est pas utilisé par la grande majorité des gestionnaires de bureau actuels. ( Est-ce que ça le sera un jour ? ). Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Ceci est l'une des raisons premières et historiques du choix Wayland.
Euh non, ça fait 100% du parc existant. Toutes les distributions Linux existantes utilisent la XLib dès qu'y est installé Xorg.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
2 % ? 1 % ?
Sachant que FreeDesktop avait marqué du sceau de l'obsolescence la XLib qui aurait dû être remplacé par XCB, de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 7.
euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Euh, ils peuvent aussi acheter des cartes pro. Et là ça marche très bien. Les cartes graphiques grand public n'ont qu'une seule idée en tête faire plus de fps que la concurrente sous le dernier jeu à la mode. Mes vieilles FireGL font très bien framebuffer + bi écran+switch fullscreen/fenetre+rendu video dans une texture en même temps. Sans plantage.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Tu as déjà vu Quartz accepter un context switch ? Et si oui le reveil a pas fait trop mal à la tête le lendemain ?
Il est impossible de bypasser quartz, tous les rendus de Xquartz/X11.app se font dans des textures avec 0 ou presque accélération. Et malgré tout il y a quand même des carte ATI qui vont te geler ton mac quand tu vas passer l'application X11 en fullscreen. Sous Mac OSX si tu veux faire de l'OpenGL accéléré tu es obligé de faire appel à quartz et d'utiliser le context de quartz tel quel.
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes
Comme sous tous les autres systèmes. Et encore sous X les applis ont une "seconde chance" si elles n'utilisent pas une lib synchrone comme XLib, une appli qui utilise XCB et qui ne voit pas revenir ses tokens peut encore lancer des sauvegardes d'etat en urgence. Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct, sous Mac c'est freeze ad vitam, sous Linux si tu as un autre contexte prêt (par exemple une console qui n'est pas en frame buffer) ton système peut être récupérable.
Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Oui le problème sera toujours là, ou pour être exact quand il sera résolu sous Wayland, on pourra le résoudre aussi sous X11 et réciproquement. Il ne s'agit pas du tout de l'architecture X11, mais bien de la carte graphique qui sort de l'etat 1 sans parvenir à rentrer dans l'etat 2. Ca peut être un problème de pilote, d'ACPI, de concurrence entre plusieurs contextes etc. Mais la seule façon d'éviter le soucis avec wayland c'est de faire comme quartz : on interdit tout context switch. Si le mec veut passer en plein écran dans une résolution différente on zoom sa texture dans le contexte existant et c'est marre.
Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Oui la XLib est une bouse. On est d'accord. XCB est bien mieux, mais aucune des grosses bibliothèque n'a suivi, il y a vaguement pango comme appli en pur XCB, et les EFL. En XCB on a accès à tout le protocole X11 sous-jacent, et donc faire tout ce que tu annonce.
De toute les façons les libs GPGCU ont démontrés que Linux savait parfaitement gérer plusieurs GPU et demander des calculs différents à chacun d'eux avant de mélanger les résultats. Ce qui bloque c'est XLib. Pas la gestion de mémoire, ni X11 ni même l'implémentation xorg.
Euh non, ça fait 100% du parc existant.
Je parlais bien entendu des applis écrites directement en XLib ou en TK ou en XMotif. Ces applis représentent aujourd'hui encore l'écrasante majorité des applis métier.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.
de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Oui mais on aurait changé un truc. A savoir le système de messagerie entre les applis et le serveur X. Là on se retrouve à tout changer et à tout devoir recoder. Et quand je vois le mal qu'a eu Rasterman pour migrer les EFL sous XCB. Ca a pris quatre ans ! Pour une lib qui n'était utilisée par quasiment personne, qui pouvait très largement se permettre de tout casser et qui avait l'objectif de passer en XCB dans ses priorités. (Et en plus Rasterman est loin d'être un manchot quand il s'agit de gérer le protocole X11 à la mano, On peut pas en dire autant de tous les devs d'applis graphiques). Ceci étant si les grosses libs avaient vraiment suivi (i.e fait du XCB pur) on aurait pu avoir un système plus faible aujourd'hui, avec pour les applis qui utilisent ces libs des recettes sur "comment faire ci ou ça dans la nouvelle version de la lib." Mais même ça, ça n'a pas marché.
Avec Wayland on fout à la poubelle les libs de haut niveau, les libs de bas niveau, le système de message, le paradigme d'affichage tout entier etc. C'est cent fois plus dur.(Ce qui ne veut pas dire que ça ne se fera pas, tout dépend une fois de plus du degré d'implication des grands acteurs, et aussi de la qualité de la doc)
Mais Wayland ne permet rien que X11R6 ne puisse faire. Il promet de dégraisser le mammouth et de passer sur un paradigme plus adapté aux besoins d'aujourd'hui. Ce n'est pas une mauvaise chose, et ça peut même être très positif. Mais ça demande un effort colossal de l'ensemble de la communauté.
[^] # Re: Fenêtre
Posté par nud . Évalué à 3.
Sauf que les choses en question sont normalement gérées par le toolkit. Par exemple, à cette heure, Gtk+ génère des événements "virtuels" pour les "client-side windows", càd pour l'émulation côté client des anciennes fenêtres X. Il y a aussi une branche pour les "client-side decorations"... qui a priori devraient être identiques pour toutes les applications qui utilisent Gtk+ et devraient réutiliser le thème gnome-shell.
Donc, en fait, non. À moins de faire des trucs tordus avec la Xlib directement (ce qui a toujours été découragé), il ne faudra pas toucher les applications Gtk+3. Pas plus que les applications Qt4 par ailleurs.
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 1.
Sauf que les choses en question sont normalement gérées par le toolkit.
Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events. Sauf que là on aura plus de message X11, donc deux solutions :
- a) On créé un "serveur" dont le but est de passer générer les évènements attendus par l'appli. En d'autres termes on fait un mini serveur de messages dans chaque appli. C'est ce qui est conforme à l'architecture Wayland après tout. Mais la ce pose un problème avec les plugins. Supposons que mon appli principale ai besoin demande à accéder seulement à certains évènements - je ne vais pas compiler mon appli pour capter tous les messages possibles et imaginables - Sauf que si j'ai un plugin qui a besoin d'évènements en plus que l'appli principale, je fais quoi ? Je compile un second serveur pour chopper les évènements "en plus", au risque d'avoir des incohérences (par exemple des raccourcis clavier qui ne marchent plus si le plugin a le focus) ?
- b) On rajoute quelques lignes de codes, notamment dans les callback des plugins pour éviter à gimp de se fader 27 serveurs de messages au bout de deux heures d'utilisation ? On modifie légèrement la portée de certaines RPC pour qu'elle puisse surcharger le serveur d'évènements ?
Il y a aussi une branche pour les "client-side decorations"
Plusieurs même, une qui est utilisée principalement par Compiz, et une autre par Gnome 3. Or toutes les applications GTK ne sont pas des applis soit Compiz soit gnome 3. Et comme des décorations de fenêtre coté client existe, on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent (en fait il faudrait que le compilo s’assure du besoin ou non de rajouter des décoration fenêtre par fenêtre - c'est pas impossible, mais ça peut être complexe). En plus les solutions de décorations client s'appuient massivement sur GConf (donc Gnome) pour chopper les éléments graphiques dont elles ont besoins (on pourrait inclure les éléments en dur dans l'application, mais bonjour les changements de thème). Donc sur ce point là je ne vois pas comment on peut se passer de réécrire, au moins en partie le code.
Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres. Le code pour se rattacher à ce serveur serait inclus de base dans les libs et limiterait pas mal le code à réécrire pour fonctionner complètement sous Wayland. Mais là aussi ça demande un gros effort et ca ferait double emploi avec pas mal de fonctionnalités de Gnome. Wait and see donc, mais je parie sur de la réécriture de code dans toutes les applis ou presque.
[^] # Re: Fenêtre
Posté par nud . Évalué à 3.
C'est en fait GDK qui fait cela, et les événements sont les mêmes quelle que soit la plateforme. Si la plateforme a des messages différents, Gdk s'occupe de faire la traduction ou le remplissage, comme sous OSX ou Win32.
Et je ne vois pas de quoi tu parles quand tu parles de plugins et de multiplication de "serveurs de messages". La plupart des plugins des applications Gtk+ sont in-process (ce n'était pas forcément le cas avec bonobo mais ça a disparu il y a longtemps) et de toute façon la partie génération/émulation/gestion des messages du système de fenêtrage est géré par Gdk et inaccessible pour l'application. Elle ne verra aucune différence et tu peux d'ailleurs le vérifier dès aujourd'hui avec les applications Gtk+ que krh utilise dans Wayland.
Ouvre les yeux. C'est le protocole wayland qui va dire à l'application si oui ou non le compositeur veut que tu dessines tes propres décorations. Si tu n'es pas en wayland, tu ne les dessines pas, point. Et de toute façon, dessiner soi-même les décorations est déjà possible avec X11 même si pas supporté au niveau du protocole.
Il n'y a pas besoin d'un tel serveur RPC. La création des messages est faite par Wayland, l'émulation des anciens messages X11 pour les widgets virtuels (qui étaient avant des fenêtres X mais n'en sont plus depuis un certain temps) est faite par le toolkit. Les décorations peuvent être faites par le compositeur s'il le souhaite, sinon je suppute que les décorations seront un peu différentes pour chaque toolkit (comme les décorations de chromium sont déjà différentes par ailleurs) mais il est fort possible d'avoir une spécification fd.o pour un thème de décorations.
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 0.
Je suis au courant de tout celà, mais ce n'est pas la question. La question est faut-il oui ou non nécessairement aller modififer du code ailleurs que dans la lib pour que les applications GTK fonctionnent correctement.
Tous les exemples que j'ai donné sont donc dans le cadre "comment peut-on faire pour que ce soit fait automagiquement et qu'il n'y ait qu'à mettre à jour la lib et recompiler".
Évidemment si on passe mon post dans le contexte générique "comment fonctionner avec Wayland" il ne veut plus rien dire.
Pour résumer ce que je disais :
X envoyait du prémaché comme message. Wayland devrait envoyer des trucs un peut plus bruts de fonderie, et certaines API ne sont pas compatibles. Il va falloir porter les applis sous Wayland et pas seulement recompiler.
Et je ne suis pas le seul à le dire :
http://wayland.freedesktop.org/gtk.html
[^] # Re: Fenêtre
Posté par nud . Évalué à 3.
Ben en fait le lien que tu cites dit exactement cela: au risque de me répéter, le backend wayland va fonctionner out of the box, sauf si on utilise du X11 directement (les appels gdkx11*). Donc si ton appli ne fait pas appel à X11 directement mais n'utilise que l'API Gtk+, ce sera transparent (et c'est le cas pour la plupart des applications Gtk+). Donc tu ne devrais même pas avoir de les applications, surtout que dans gtk+ 3 les backends sont dynamiques.
Les seules API non compatibles sont les APIs qui permettaient d'aller chipoter directement dans les entrailles de X11. C'est normal, et elles ne sont pas accessibles directement sous win32 par exemple...
Les autres mentions sont des bugs du backend Wayland.
[^] # Re: Fenêtre
Posté par nud . Évalué à 1.
Un mot est resté dans mon clavier.
Il fallait lire: "Donc tu ne devrais même pas avoir besoin de recompiler les applications."
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 0.
Les seules API non compatibles sont les APIs qui permettaient d'aller chipoter directement dans les entrailles de X11.
Oui, et les bind ou les create de display sans compter un certain nombre de périphériques un peu exotiques qui sont pour l'instant laissés de coté. On ne parlera pas non plus de cairo-gl qui nécessite encore aujourd'hui que l'on fasse les includes qui vont bien à la main.
De façon générale tout le code de rendu de GTK est en pleine phase de nettoyage, donc si ca se trouve il y aura moyen de faire d'une pierre deux coups, à savoir à partir de de GTK 3.x, avec x à définir, toutes les applis pourront utiliser aussi bien du Wayland que du X11. Mais pour les applications existantes je n'y crois pas une seule seconde.
et elles ne sont pas accessibles directement sous win32 par exemple...
Certes, mais si il suffisait de ne pas se servir des API XLib ou du namespace X pour que ça fonctionne nickel sous tous les systèmes, il n'y aurait pas besoin d'autant d'efforts de portage pour faire fonctionner des applis comme Gimp ou Abiword sous divers systèmes. Même si les disparités sont connues et que GTK évolue pour les réduire, il reste des différences structurelles qui font qu'on est obligé de mettre les mains dans le code de temps en temps.
Ce sont ces différences qui vont casser les pieds entre Wayland et X.Org.
[^] # Re: Fenêtre
Posté par CrEv (site web personnel) . Évalué à 6.
Je suis pas sur de "context switch" mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial. Enfin si, l'écran clignote un peu, et ensuite tu as juste une petite popup qui vient de dire que ton driver a merdé et qu'il a été redémarré (en gros).
Pas d'écran bleu ni de pertes d'applications. Sous X, tout aurait été embarqué avec le driver au final, et tu perds toutes tes applications.
[^] # Re: Fenêtre
Posté par reno . Évalué à 2.
Note que le comportement de Windows dépend probablement de quelle partie du pilote de la carte a un problème: si c'est la partie intégré dans le noyau un écran bleu parait probable, si c'est la partie en espace utilisateur alors Windows peut redémarré le pilote.
Actuellement oui, mais c'est un problème avec le protocole X ou un problème d'implémentation de Linux/du serveur X/des toolkits/des applications?
Je croit que c'est un problème d'implémentation de Linux&des couches basses(pas capable de redémarrer un pilote) et des toolkits (qui n'essayent pas de se reconnecter à un serveur X s'il redémarre), donc c'est un peu agaçant quand on dit que c'est un problème d'X.
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 9.
mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial
Ca dépend beaucoup de comment le driver part en couille, et de pourquoi.
Grosso modo on peut définir trois grands cas :
Le pilote se vautre tout seul comme un grand, il y a un bug quelconque dans le pilote, il envoie une série de commande à la carte graphique, la carte graphique répond "beurk", mais reste dans un état parfaitement valable et initialisé, l'application qui est à l'origine de la série de commande fautive se prend une notification d'erreur et suivant les cas réessaye, se vautre ou se ferme proprement. Sous Linux si c'est X11 l'application fautive il va y avoir une série de lignes dans le log et peut-être une fenêtre qui n'aura plus de père. Sous Windows si c'est explorer desktop, il va gentiment mémoriser les fenêtres et les params, se fermer et se relancer. Pas de clignotement écran dans ce cas là, juste la fermeture et la réouverture de la barre des taches et de certaines infobulle et autres icônes de notifications
La carte graphique envoie une réponse qui n'a rien à voir avec ce qui a été demandé. Défaut du pilote ou de la carte, difficile à savoir sans mettre les mains dans le cambouis, toujours est-il qu'il y a un problème. Soit l'erreur est minime et on ferme l'appli, soit l'erreur est plus grave et on tente le double context switch à la sauce windows :
1 - On passe la carte graphique dans un mode non accéléré, éventuellement avec une résolution moindre. (l'écran s'éteint et se rallume)
2 - On valide qu'en mode non accéléré le système graphique repart bien (généralement c'est le cas)
3 - On décharge tout ou partie du pilote de la carte graphique (c'est la partie que Linux ne sait pas faire, X11 peut mais l'archi au niveau kernel ne suit pas)
4 - On recharge un pilote propre et on réinitialise la carte graphique (l'écran s'éteint)
5 - On repasse en mode graphique précédent avec accélération (l'écran se rallume dans).
Parfois il y a des étapes en plus, notamment si il faut décharger tout le pilote, pas juste la partie accélération (comme dans une mise à jour) dans ce cas windows Vista/7 vont passer par un pilote de compatibilité ce qui peut pousser le nombre d'extinction/rallumage à quatre.
[^] # Re: Fenêtre
Posté par reno . Évalué à 5.
Je ne réponds qu'à certains de tes points car ton post est un peu long:
Oui.
Qt5 devrait aussi supporter XCB.
Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU? Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non?
Je croyais que c'était un problème d'implémentation de X.Org..
Je suis d'accord avec nud et Kaane: je pense que les décorations clients seront gérées par les toolkits, à moins que l'appli veuillent faire sa propre décoration ce qui n'est pas une bonne idée (l'appli apparaîtra différente des autres).
Pas 100% vrai ça: avec Wayland une application peut passer une adresse de buffer mémoire du GPU au serveur d'affichage (Weston) pour qu'il l'utilise, ce qui doit être très efficace en local (si le GPU a une mémoire séparée), X11R6 ne permet pas ça.
Changer totalement l'écosystème pour cette raison ne me parait pas justifié pour autant: une extension de X pourrait faire ça, mais bon ce n'est pas moi qui bosse sur Wayland..
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 0.
Qt5 devrait aussi supporter XCB.
Ca serait une excellente chose.
Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU?
Même si le protocole X11R6 est assynchrone à 99%, la XLib ne fonctionne quasiment qu'en mode synchrone. Donc pour tout un tas d'opérations elle ne peut gérer qu'une seule carte à la fois et bloque tout le reste tant qu'elle n'a pas reçu de réponse. Donc forcément en cas de plantage d'un des pilotes avant que XLib n'ait eu sa réponse, tout le monde est gelé.
Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non
Avec XCB il n'y a pas le problème en effet. De façon générale on peut parfaitement gérer plusieurs rendus/GPU/surfaces/écrans en mélangeant allègrement en X11.
Je croyais que c'était un problème d'implémentation de X.Org..
Je n'ai jamais dit que c'était un problème d'implémentation X.Org. Mon seul message est que tout ce qui est possible avec Wayland est possible avec X11R6. Si on était en langage de programmation on dirait que X11R6 et Wayland sont tous les deux turing-complet mais ne relèvent pas du même paradigme.
Je suis d'accord avec nud et Kaane
Le problème est que Kaane n'était pas complètement d'accord avec nud et que je suis Kaane. Donc soit j'ai encore réussit à faire comprendre exactement l'inverse du message que je ne voulais pas donner, soit il y a un soucis.
je pense que les décorations clients seront gérées par les toolkits
CF mon post, ça pose de nombreux problèmes. Le premier et que l'on peut cascader les compositor et donc créer un compsitor pour les décorations (un wm quoi). Le second est que certaines applis ont déjà de décorations gérées par le client (les applis compiz et les applis Gnome3 au moins), charge donc au toolkit de reconnaitre ces applis pour ne pas recoller une couche de déco par dessus. Charge ensuite au wm si il y en a un de reconnaitre tout ça pour ne pas faire de même. Sinon une appli gtk/compiz sous un wayland avec un compositor wm va se retrouver avec 3 décos...
Se pose ensuite le problème de la gestion des évènements sur ces décos. C'est pas insoluble du tout, mais comme je l'ai dit précédemment il y aura des lignes de code à corriger dans quasiment toutes les applis.
Pas 100% vrai ça: avec Wayland une application peut passer une adresse de buffer mémoire du GPU au serveur d'affichage (Weston) pour qu'il l'utilise, ce qui doit être très efficace en local (si le GPU a une mémoire séparée), X11R6 ne permet pas ça.
Sous X11R6 il y a des tonnes d'équivalents. Je dis d'équivalents parce que comme X11R6 ne fait pas de composing, il n'y a aucun intérêt à lui retransmettre les buffers directs. On lui signale juste qu'on les prend et on dessine dedans. Pour les plus courant on peut citer les extensions overlay(un peu morte),DBE(pas toutes les implémentations), XAA, EXA, DRM, DRI (et dans une certaine mesure XRender même si c'est une surcouche). Toutes ces extensions vont faire mumuse directement avec la mémoire de la carte graphique, et sont donc très rapide en local.
[^] # Re: Fenêtre
Posté par reno . Évalué à 2.
Euh le multi-GPU dont pas mal de gens se plaignent que X n'a pas ce n'est pas une histoire de robustesse, c'est pour pouvoir avoir le choix entre un GPU économe en énergie et un GPU puissant, je ne vois pas en quoi le plantage de pilote intervient ici..
J'avais mal lu ta réponse à nud, désolé. Mais je ne pense pas qu'il faille réécrire les applis: les devs GTK/Qt qui discutent parfois sur la mailing list Wayland ont l'air plutôt calme ;-)
Hum comme X11R6 ne fait pas de composing, tes équivalents ne me paraissent pas équivalent coté performance..
Wayland te permet de faire: l'application rend sa fenêtre dans un buffer du GPU, donne l'adresse du buffer à Weston, Weston compose toutes les fenetre dans un autre buffer pour obtenir l'écran puis l'affiche, donc il y a une seule copie des fenêtres de la mémoire du GPU vers la mémoire du GPU avant d'afficher l'écran, comment tu fais ça aussi efficacement avec X11R6 en partant de la même situation de départ: l'application a rendu sa fenêtre dans la mémoire du GPU?
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 2.
Euh le multi-GPU dont pas mal de gens se plaignent que X n'a pas ce n'est pas une histoire de robustesse, c'est pour pouvoir avoir le choix entre un GPU économe en énergie et un GPU puissant, je ne vois pas en quoi le plantage de pilote intervient ici..
Sur les systèmes à changement de GPU, il y a un buffer video dédié pour le passage d'une carte graphique à l'autre. On met tout ce dont on a besoin dans ce buffer (résolution, profondeur de couleurs, les diverses zones de travail et leur contenu) et on utilise tout ça pour initialiser la nouvelle carte graphique.
A ma connaissance on a pas les specs de ce buffer, ni les specs pour initialiser les cartes graphiques à partir de ce buffer. De fait Linux (le Kernel) n'a rien implémenté pour que l'on puisse changer de pilote en cours de route (désactiver DRI, désactiver EXA et consors, rediriger vers le nouveau pilote, réactiver DRI etc.)
Si on avait les specs et si la partie pilote kernel suivait on pourrait créer une extension X11R6 et la coder dans Xorg pour faire ce switch. Tant qu'on a pas....
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 1.
Pardon pour la réponse en deux temps, j'ai voulu aller trop vite.
Hum comme X11R6 ne fait pas de composing, tes équivalents ne me paraissent pas équivalent coté performance..
Non ils sont souvent meilleurs niveau performance.
Sous Wayland (ou autre compositor) ca donne ça :
Travail dans un buffer dédié -> copie dans le buffer de composition -> copie dans le buffer affichage (ou switch buffer en cas de back buffer/triple buffer)
Sous X11R6 en DRI ca donne ça Travail dans un buffer dédié -> copie dans le buffer affichage (ou dans un back buffer)
La seule différence c'est qu'il n'y a pas d'étape de composing, donc on peut pas faire de trucs rigolos (comme des icones qui se réduisent en continuant à mettre à jour la 3D) mais niveau perf on est plutôt mieux.
comment tu fais ça aussi efficacement avec X11R6 en partant de la même situation de départ: l'application a rendu sa fenêtre dans la mémoire du GPU?
Si la mémoire est en off screen (généralement c'est le cas) plusieurs solutions :
a) mode m'en fous, je m'affiche. Le pilote via X indique à la carte graphique que quoi qu'il arrive c'est le contenu de tel buffer qui doit être copié à tel endroit de l'affichage. (très utile en fullscreen)
b) mode subtil : X garde en mémoire la zone ou la partie accélérée devrait se trouver, en fonction de cela il regarde si il y a d'autres fenêtres par dessus et indique à la CG les partie non recouverte et donc à copier.
c) triple buffer le composing du pauvre et du bourrin. On rend les contenus accélérés dans leur buffers respectifs, X copie tout en masse dans un backbuffer et peint ses fenêtres par dessus, on échange le back buffer et le front buffer.
Comme tu vois il n'y a à chaque fois qu'une seule copie.
[^] # Re: Fenêtre
Posté par reno . Évalué à 3.
Bah non, je ne vois toujours pas comment l'application peut donner l'adresse d'un buffer du GPU au serveur X plutôt que l'adresse d'un buffer en mémoire centrale.
Ça fait partie de quelle API/extension ça?
[^] # Re: Fenêtre
Posté par Kaane . Évalué à 2.
Bah non, je ne vois toujours pas comment l'application peut donner l'adresse d'un buffer du GPU au serveur X plutôt que l'adresse d'un buffer en mémoire centrale.
Il n'a pas besoin de le faire. Il n'y a pas de composing. X a créé une surface de rendu via une des extensions pré-citées, l'application l'a bindé. Il n'y a rien besoin de faire d'autre.
Je ne suis pas sur de comprendre ou est le problème.
Via DRM/DRI, EXA, XAA l'appli travaille directement en mémoire GPU et le rendu ne passera jamais par la mémoire centrale. C'est bien ce que tu cherches non ?
[^] # Re: Fenêtre
Posté par reno . Évalué à 4.
Avec Wayland c'est le client qui alloue la surface en mémoire du GPU, puis passe son adresse au serveur d'affichage Weston, j'étais tellement focalisé sur ce mode là que j'oubliais que le client X pouvais demander au serveur X d'allouer la surface et de te retourner son adresse (enfin je crois que c'est ça: la doc est horrible), ce qui d'un point de vue copie mémoire pour les communications client/serveur revient strictement au même.
Bon bah, je comprends de moins en moins l'intérêt de Wayland..
[^] # Re: Fenêtre
Posté par claudex . Évalué à 2.
Le principal intérêt pour moi, c'est de repartir avec un système maintenable vu que ce n'est pas vraiment le cas avec X.org.
« 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: Fenêtre
Posté par nud . Évalué à 2.
Je me demande quand même où tu as vu que aujourd'hui gnome 3 utilise des décorations gérées par le client. Gtk+ stable ne gère pas les décorations à ce jour, donc non, les décorations ne sont pas gérées par les clients mais bien par le WM.
[^] # Re: Fenêtre
Posté par zebra3 . Évalué à 1.
En même temps, tu parles d'une appli non conçue pour Linux et X, donc d'emblée c'est un mauvais exemple.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Fenêtre
Posté par MTux . Évalué à 2.
Vraiment ? Pourtant c'est dans un processus wine... et on ne peut pas toujours rejeter la faute sur l'application.
[^] # Re: Fenêtre
Posté par CrEv (site web personnel) . Évalué à 6.
Tiens, lorsqu'on lit les explications on a plutôt l'impression du contraire : X est trop bordélique à maintenir, personne ne le connait suffisamment bien pour l'améliorer significativement, etc.
Mais non, c'est vrai, ça doit pas être ça, ils le font uniquement pour le plaisir.
Ha oui, c'est pas comme si X était déjà en retard depuis un moment quand même.
Mais si c'était envisageable de modifier X pour avancer, ne crois-tu pas que ce serait déjà le cas ?
[^] # Re: Fenêtre
Posté par CrEv (site web personnel) . Évalué à 3.
D'ailleurs, parfois la meilleur chose à faire est de recommencer à zéro. C'est, au bout d'un moment, le mieux, le plus efficace.
http://www.inc.com/magazine/201202/jason-fried/starting-over-get-real.html un lien comme un autre, sur le principe de recommencer. Je sais que c'est pas le même domaine, mais au final ça ne change rien.
Lorsqu'un architecture est dépassée, souvent il faut repartir d'une feuille blanche en ce concentrant sur le métier, le fonctionnel, et non tenter de modifier un mastodonte, ce qui ne fonctionner jamais, et il suffit de voir le retard de X dans le domaine pour s'en convaincre.
[^] # Re: Fenêtre
Posté par Jux (site web personnel) . Évalué à 10.
Tu as quand même conscience que Kristian Hogsberg (développeur principal de Wayland) et Keith Packard (un des développeurs principaux de X depuis pas mal d'années) semblent les deux penser que X a vécu et qu'il faut repartir sur de nouvelles bases car les hypothèses de base de X (transparence réseau, applications affichant essentiellement du texte et étant peu interactives) ne sont plus valables aujourd'hui ?
Je ne suis pas développeur X, mais quand deux des principaux développeurs disent qu'il a vécu, ils ont probablement raison. Et si c'était si simple de faire évoluer X11 en X12 pour résoudre les problèmes, ils le feraient probablement.
[^] # Re: Fenêtre
Posté par reno . Évalué à 4.
Plutôt on crée un système qui correspond à des préoccupations différente (uniquement le cas local), si ça reste juste une alternative il n'y a pas de problème, sinon effectivement ça lésera des utilisateurs.
Regarde 3 post plus haut: "Il y aura juste une API pour que le client indique ou se trouve le bouton pour fermer la fenêtre afin qu'un serveur puisse tuer un client non-réactif"
J'ignore de quoi tu parles, chaque application doit maintenir une image complete de son application, par contre je crois qu'il est possible a l'application de dire au serveur "redessine tel partie du buffer".
Pour ce qui est de l'affichage: tout est rendu sur un buffer hors d'écran, puis composer par le compositeur et enfin afficher, il ne devrait pas y avoir de glitch graphique donc (enfin sauf si l'application/le toolkit en fait).
Wayland tout entier reste à développer.. Il n'y a qu'à voir leur dernier TODO il est plutôt conséquent, et il y a déjà de la compatibilité X..
Sur les developpeurs de toolkit ou de desktop tu veux dire, par ce il y a très peu d'application qui appellent X directement.
Bah, vu le peu de gens qui se sont intéressé à Berlin/Fresco la perte de temps a été limitée et l'objectif était différent: obtenir un système "à la NeWS" qui fonctionne encore mieux en distant, mais tu as raison intégrer un "NX" à X aurait été bien plus utile..
Note que puisque tu parle d'iPad: Apple a aussi réinventer la roue: ils ont changer leur système d'affichage (Quartz) il y a déjà un certain temps..
[^] # Re: Fenêtre
Posté par fearan . Évalué à 3.
Ce qui est très différend de déplacer une fenêtre. Si la fenêtre contient un message d'erreur ou autre, c'est pas mal de la mettre à un endroit ou elle ne gène pas le temps de lancer un gdb, checker du code, ou tout simplement attendre que le collègue passe voir le truc.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Fenêtre
Posté par reno . Évalué à 5.
Un gars s'est amusé de faire un test avec Windows7 dans le cas ou une application arrête de répondre ou est (très) lente à répondre: une fois que le gestionnaire de fenêtre a détecté que l'application ne répond plus, tu peux déplacer la fenêtre "zombie".
Weston pourrait faire la même chose.. Bon ce n'est même pas dans leur TODO list (ou je l'ai loupé) actuellement, mais ils en sont au début!
Avec la décoration coté client chaque affichage de la fenêtre est "parfait", même lors d'un redimensionnement, par contre comme le test le montre il faut que le client soit réactif autrement c'est pas terrible: c'est un compromis.
Ce qui serait bien, c'est si ce besoin de réactivité incitait a aller vers un design à la BeOS/Haiku avec une thread par fenêtre dédié à l'IHM..
[^] # Re: Fenêtre
Posté par cedric . Évalué à 7.
Je trouve cet argumentaire d'assez mauvaise fois. On a aujourd'hui les exemples d'applications qui ont des besoins precis de la part du gestionnaire de bureau. Pourquoi n'ont-il juste pas integre ces besoins dans la spec de Wayland ? On aurait pu tres bien definir un moyen de decrire n state a une application, le windows manager se chargeant de gerer des tabs ou quelques representation graphique que ce soit. Je ne connais pas les besoins de GIMP, mais pourquoi n'y a-t'il pas eu une reflexion au niveau de l'integration d'un window manager dans Wayland.
De mon point de vue, Wayland s'est concentre sur le cote composite manager et a delegue le window manager a chaque application. Meme la gestion du curseur de souris est delegue aux applications, si j'ai bien suivi. Quand les Window Manager tel que KWin ou E commenceront a implementer serieusement le protocole Wayland, il est certain que celui-ci devra evoluer...
[^] # Re: Fenêtre
Posté par reno . Évalué à -1.
Toutafé.
[^] # Re: Fenêtre
Posté par reno . Évalué à 2.
Bah, ça vraiment c'est le problème le plus mineur et le plus simple a résoudre..
Il existe déjà sous X pour tout ce qui n'est pas la décoration de la fenêtre d'ailleurs: en pratique ça n'est pas un problème car les toolkits sont assez souple et configuré par les distributions pour que le "look n'feel" soit homogène (enfin à peu près).
# Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Ce n'est pas très clair : Wayland intègre son gestionnaire de fenêtres mais les fenêtres doivent elles-mêmes dessiner leurs décorations ? Ça semble un peu idiot, ça promet un beau bordel bien disparate, mais surtout, ça a l'air d'interdire toute possibilité de réaliser de nouveaux gestionnaires de fenêtres. Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus (Window Maker, le défunt Ion3, wmii, awesome et compagnie), la résistance à Wayland promet d'être féroce.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 10.
Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus (Window Maker, le défunt Ion3, wmii, awesome et compagnie), la résistance à Wayland promet d'être féroce.
Et si encore il y avait que les barbus.
Déjà il y a tous les scripts d'init et d'autoconfig à réécrire, donc les distribs vont super bien le vivre.
Ensuite tous les logiciels de prise de main à distance, que ce soit par export du display ou par pseudo serveur X sont à réécrire, à moins de se palucher des couches et des couches de compatibilité.
Après il y aura les cas à la con, genre la fenêtre à cheval sur deux écrans en Opengl avec chacun des deux écrans qui utilisent un compositor différent. Ou alors une appli web HTML5 en full screen sur deux écrans avec du webgl et du flash dedans.
Avec un peu de chances on aura même des API noyeau ou des programmes de config qui étaient utilisés principalement par X et qui vont être deprecated pendant 10, 15 ans (on en est à 9 ans pour OSS, 13 pour ifconfig)
Avec un peu de chance peut-être même que L.P finira par écrire une surcouche de gestion userland.
Moi j'ai déjà commandé du pop-corn.
[^] # Re: Gestionnaire de fenêtres
Posté par coïn . Évalué à 2.
Pour peu que la migration soit faite à la hussarde comme pour PulseAudio, il y a de quoi passer un bon moment avant de retrouver un peu de sérénité. Mais j'imagine que d'ici là, les nouveaux systèmes de fichiers révolutionnaires seront arrivés pour faire le cliffhanger.
Je ramène les bières.
[^] # Re: Gestionnaire de fenêtres
Posté par brendel . Évalué à 7.
Oui mais ça c'est pas grave, c'est le travail nécessaire pour l'adoption de Wayland. Moi ce qui me gène comme tanguy, c'est de retirer la possibilité d'utiliser le gestionnaire de fenêtre qu'on veut. C'est quand même pour moi une grosse force de Linux.
C'est là que j'ai pas tout compris. La dépêche dit que finalement un serveur Wayland c'est un compositeur. Est-ce que compositeur et gestionnaire de fenêtre sont synonymes?
Si oui, ça veut dire que écrire un gestionnaire de fenêtre reviens à écrire un serveur Wayland. Est-ce que Wayland est vraiment prévu pour pouvoir écrire des compositeurs facilement?
[^] # Re: Gestionnaire de fenêtres
Posté par claudex . Évalué à 2.
Vu qu'il en existe déjà 3 ou 4, je dirais oui.
« 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: Gestionnaire de fenêtres
Posté par Corentin Chary (site web personnel) . Évalué à 5.
Il y'a même des classes Qt pour écrire son compositeur tout en Qt ! le gros bonus c'est que du coups le compositeur peut ensuite tourner sous X si besoin.
[^] # Re: Gestionnaire de fenêtres
Posté par brendel . Évalué à 3.
OK, c'est juste que comme le compositeur par défaut ne gère pas les décoration, ça me faisait un peu peur. Si pour eux c'est le fonctionnement normal de Wayland, alors le projet risque d'évoluer plus dans ce sens.
Cela dit je n'ai toujours pas bien compris la différence entre gestionnaire de fenêtre et compositeur. Dans ce que je trouve c'est souvent utilisé comme synonyme.
[^] # Re: Gestionnaire de fenêtres
Posté par jyes . Évalué à 1.
Parce que beaucoup de gestionnaires de fenêtres embarquent leur propre compositeur (historiquement Compiz, puis Kwin, Mutter, etc), mais tu peux aussi trouver des compositeurs autonomes (xcompmgr, fbcompose, cairo-composer). Tu peux ainsi avoir un environnement « composité » avec fluxbox, openbox, window-maker, un tiling-wm ou n’importe quel gestionnaire qui ne dispose pas de son propre compositeur..
[^] # Re: Gestionnaire de fenêtres
Posté par jiyuu . Évalué à 1.
Question con: Pourquoi voudrais-tu avoir deux compositeurs différents dans un même gestionnaire de fenêtres ?
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 8.
_Question con: Pourquoi voudrais-tu avoir deux compositeurs différents dans un même gestionnaire de fenêtres ? _
Réponse : parce que je peux ? (enfin si je peux)
Il y a pleins de raisons de vouloir avoir des écrans séparés gérés par des compositors différents. Par exemple avoir un écran de dev et un écran de rendu, que ce soit pour la photo, le dessin, le montage video ou même simplement le développement de sites webs.
Et puis je ne sais pas comment Wayland va gérer les écrans multiples non identiques (comme un écran en mode portrait, un autre plus petit pour les infos critiques et le debug).
De toute façon ce qui m'intéresse se sont les cas particuliers, et comment ils vont être pris en compte. Parce que ce qui fait le succès d'une appli open source c'est tous les trucs bizarres qu'on ne pouvait pas faire avant qu'elle arrive. Les cas ultra généraux seront traités convenablement je pense.
Et puis aussi il ne faut pas oublier la loi des 90/90. En informatique 90% des utilisateurs veulent faire au moins un truc dont 90% des autres utilisateurs n'ont strictement rien à foutre.
[^] # Re: Gestionnaire de fenêtres
Posté par jiyuu . Évalué à 4.
Il y a truc que je dois pas comprendre. Tu dis:
Mais dans l'état actuel des choses, on utilise seulement un seul compositeur (Compiz, Mutter, KWin... dans les compositeur + gestionnaire de fenêtres et [xd]compmgr, cairo-compmgr pour les compositeurs seuls), et ça n'empêche pas de faire tous ce que tu dis. En quoi un deuxième compositeur serait utile ?
Ce n'est pas que j'en ai rien à foutre, c'est surtout qu'avec X11, je ne crois pas que ce que tu dis soit possible (2 compositeurs pour un seul gestionnaire de fenêtres) mais je peux me tromper.
Bref, merci d'éclairer ma lanterne.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 2.
Mais dans l'état actuel des choses, on utilise seulement un seul compositeur
On en utilise même souvent 0. A l'heure actuelle on peut parfaitement se passer des différents "display compositors" et avoir un système qui marche très bien. Sauf que là la règle va changer, on va en fait avoir des cascades de compositors.
Déjà le compositor final Wayland, ensuite probablement au moins un des clients (ou plugins du serveur wayland ?) sera un composite window manager.
Ensuite se pose les problèmes de tout ce qui utilise les backbuffers, l'accès direct ou l'overlay (video, 2D/3D accéléré etc.) Parceque ça fait pas forcément très bon ménage avec les compositors. Bien sur il existe des solutions qui marchent, mais il va falloir faire des choix et définir des priorités. Par exemple que se passe-t-il sur un contenu webGL dans firefox ? Est-ce que l'on fait un rendu complet de tout le WebGL et qu'on l'envoi à Wayland ? Est-ce qu'on créé un hook dans Wayland pour qu'il fasse le rendu webGL lui-même (avec ou sans aide de Firefox qui peut prémacher une partie du boulot) ou est-ce qu'on définit une zone buffer dans Wayland dans laquelle il n'y a pas de composing et ou le rendu se fait en direct ? Ou alors est-ce qu'on multiplie les API pour garder la compatibilité (et dans ce cas je sens qu'on va encore jouer à "ou qu'elle est la doc ? D T Code !")
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control). Et pourtant eux ils avaient plus ou moins table rase de l'historique. Chose que Linux va avoir du mal à faire.
Donc plusieurs compositors c'est à peu près obligatoire, reste à savoir si on pourra avoir plusieurs moteurs de composing en même temps. Si oui, comment vont-ils dialoguer ensemble pour pas se taper sur la gueule (pas DBus, pitié pas DBus), sinon est-ce que le moteur "officiel" de Gnome sera compatible avec celui de KDE ou avec celui d'enlightenment...
[^] # Re: Gestionnaire de fenêtres
Posté par Frank-N-Furter . Évalué à 4. Dernière modification le 21 février 2012 à 14:13.
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control).
Mission control? Tu es certain de ça?
Depending on the time of day, the French go either way.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 1.
Mission control? Tu es certain de ça?
En fait non, je ne retrouve plus l'article qui expliquait qu'avec mission control venait un gestionnaire de composition repensé sauce GCD. Maintenant que Google est noyé sous les "comment changer la couleur de fond quand on est sous mission control kikoo lol" ca va être plus dur à retrouver.
Donc à prendre avec des pincettes.
[^] # Re: Gestionnaire de fenêtres
Posté par letsyl . Évalué à 3.
De ce que je comprends, il n'y a pas "d'envoi" de buffer avec Wayland. Le serveur donne aux clients des buffers dans lesquels ils peuvent écrire, et les clients envoient un message lorsque cela a été fait. Le serveur Wayland peut alors afficher le buffer (KMS page flipping).
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 1.
De ce que je comprends, il n'y a pas "d'envoi" de buffer avec Wayland.
Pour un rendu OpenGL/WebGL "accéléré" il faut travailler dans un espace spécial. Donc soit cet espace est fourni par Wayland (solution 3 de mon post), soit le rendu est effectué par Wayland à partir de pseudo-code (solution 2) soit on travaille dans un espace non affiché et on copie le rendu dans le buffer Wayland à la fin (solution 1 que j'ai appelé "envoi de buffer" parceque s'en est un même si je me rend compte que ça peut porter à confusion)
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 2.
Pour les applications normale il me semble que c'est (1) qui est utilisé, pourquoi WebGL serait différent?
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . Évalué à 0.
Pour les applications normale il me semble que c'est (1) qui est utilisé, pourquoi WebGL serait différent?
C'est la solution la plus facile et la plus simple. Mais c'est aussi celle qui a le pire rendement niveau perf. On se retrouve à rendre la frame, à la mettre de coté, à la placer dans le buffer wayland, et à attendre le composing avant de finalement arriver jusqu'à l'affichage.
Dans les autres méthodes on fait un rendu que la carte graphique affiche directement quand il est fini.
[^] # Re: Gestionnaire de fenêtres
Posté par claudex . Évalué à 1.
Il y a déjà 3 ou 4 compositeurs pour Wayland, je ne vois pas ce qui l'interdit. De plus, ça me semble normal que le gestionnaire de fenêtre soit très intégré au compositeur puisque ce dernier va effectuer le rendu en fonction du placement des fenêtres. D'ailleurs, c'est déjà le cas actuellement, pour utiliser un compositeur, il faut un gestionnaire de fenêtre compatible (Kwin (celui de KDE4), celui de compiz... mais pas Metacity (en tout cas, lors de la sortie de compiz)).
« 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: Gestionnaire de fenêtres
Posté par jyes . Évalué à 1.
Non, tu peux utiliser un gestionnaire de fenêtre et un compositeur indépendants (même si Mutter, Compiz et Kwin embarquent leur propre compositeur). Rien ne t’empêche d’utiliser Metacity avec xcompmgr.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 5.
Oui, c'est le comportement par défaut.
Non: aucune solution n'est idéale, c'est un compromis.
L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.
Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
La synchro se fera par du EWMH j'imagine.
Il y a des raisons de ne pas aimer Wayland:
-non portabilité actuelle sur les *BSD
-un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.
[^] # Re: Gestionnaire de fenêtres
Posté par Gof (site web personnel) . Évalué à 3.
Techniquement, c'est Watson (le compositeur de référence) qui n'est pas portable sur *BSD.
Mais rien n'empêche d'autres compositeurs Wayland (KWin ou autre) de tourner sur *BSD (par dessus X s'il le faut)
(Et donc les applications Wayand reste compatible avec *BSD)
[^] # Re: Gestionnaire de fenêtres
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Weston, pas Watson.
[^] # Décorations gérées par l’application
Posté par Arthur Accroc . Évalué à 7.
Comme on le sait, aucune application ne part jamais en sucette. D’ailleurs, sous Windows, qui laisse les applications gérer ça, il n’y a jamais de fenêtre bloquée au milieu de l’écran...
C’est donc idiot, comme le disait Tanguy.
Bon, je ne dis pas non d’avance à Wayland, mais pour ce qui est du compositeur par défaut, ce n’est même pas la peine. Peut-être avec un qui gère vraiment les fenêtres...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Gestionnaire de fenêtres
Posté par CrEv (site web personnel) . Évalué à -1.
Belle démonstration d'immobilisme...
Mais c'est vrai ça, refusons toute évolution.
Ha oui, et surtout, soyons féroce histoire de bien montrer qu'on ne veut pas évoluer.
En général, on appel ça, par exemple, des dinosaures, pas des barbus...
Moi qui croyait que dans le libre, contrairement à beaucoup de "proprio" on était capable de casser des choses lorsqu'elles sont obsolètes / non adaptées / non pertinents / qu'il y a mieux à faire.
(et c'est pas comme si tout était fait sans réfléchir un minimum comment être compatible avec X)
[^] # Re: Gestionnaire de fenêtres
Posté par fearan . Évalué à 4.
Si un gestionnaire de fenêtre répondait à toutes les problématique, on serait tous dessus. En attendant on en a plusieurs, et tant qu'il n'y en aura pas d'équivalent, les gens ne bougerons pas.
Il me semble ici que bon nombre ont oublié le vieux dicton "If it works DONT't fix it"
Justement non, le libre c'est aussi être capable de continuer à utiliser l'existant même si la boite qui développait le truc disparaissait.
Oui on est capable de tout casser (y a qu'a voir le passage par KDE 4.0), mais on est aussi capable de conserver les truc en fonctionnement (kde 3.5). Wayland est le petit nouveau et s'il veut s'imposer il doit convaincre, pas seulement être le plus beau techniquement (sinon betamax aurait pulvérisé VHS)
J'aimerai aussi savoir comment se comportera une appli sous wayland en mode tilling, ça promet d'être assez laid
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Gestionnaire de fenêtres
Posté par CrEv (site web personnel) . Évalué à 5.
Ben heureusement que beaucoup l'ont oublié.
C'est bien pour un truc critique en prod ça, mais c'est aussi le premier pas vers "ne bougeons pas, jamais !"
Pourquoi "justement non" ? Les deux approches sont loin d'être incompatibles.
Oué mais faut aussi lire ce qui est écris, entre autre que ça peut embarquer un X par exemple.
Quel est le problème ? Car "laid" ça ne veut rien dire, ni explique le problème qu'il pourrait y avoir.
[^] # Re: Gestionnaire de fenêtres
Posté par fearan . Évalué à 0.
Oui qui marche en LAN (et encore faut pas être trop dessus), et qui fout ta connexion WAN en l'air. Wayland est très bien, c'est un progrès, mais faut arrêter de le présenter comme le messie supérieur à X sur tout les points de vue. Car en niant ces problèmes, on risque pas de les corriger.
Les décoration gérées par l'appli plutôt que le gestionnaire de fenêtre? (par exemple)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Gestionnaire de fenêtres
Posté par Moonz . Évalué à 8.
Si des trucs comme wmii ou dwn deviennent impossible sous Wayland, j’appelle pas ça une évolution mais une régression.
[^] # Re: Gestionnaire de fenêtres
Posté par CrEv (site web personnel) . Évalué à 2.
Et pourquoi ce serait-le cas ?
Où est-ce indiqué que ce ne sera pas possible ?
Il est même indiqué que ça embarquera un serveur X.
Il est indiqué que la compatibilité avec X est loin d'être oubliée et évidemment fait partie des préoccupation.
Le problème est là, un truc nouveau arrive, il n'est pas encore fini, et tout de suite on a droit à des "et si [bla bla bla j'en sais rien] alors c'est rien que de la merde"
Ca fait juste preuve d'immobilisme et de peur du changement. Et au final le libre n'est pas mieux qu'ailleurs sur ce sujet, alors qu'il devrait tirer partie de ses avantages, entre autre le fait d'avoir les sources pour pouvoir rendre compatible ce qui existe.
[^] # Re: Gestionnaire de fenêtres
Posté par Moonz . Évalué à 3.
si
(conjonction)
Au cas où, supposé que.
Et je m’en fiche totalement de la compatibilité avec X, à un point que tu ne peux pas imaginer.
Moi, ce que je comprend de cette description de Wayland, c’est que le serveur Wayland, c’est à la fois un compositeur + un WM. Dit autrement, si je veux écrire un wmii, je dois me taper la réécriture du serveur complet (avec tous les problèmes de communication avec le noyau, avec la carte graphique), un compositeur (même problématique). Autant dire que ce sera à l’extrême limite de l’impossible, et que le serveur résultant sera à bien des points (bugs, performances) en-deçà du serveur « officiel ».
Mais prouve moi que je me trompe, et j’adopte Wayland demain.
[^] # Re: Gestionnaire de fenêtres
Posté par Shuba . Évalué à 2.
En voyant les schémas de fonctionnement je vois pas vraiment la différence de fonctionnement avec X11 pour la gestion des fenêtres. Si je me trompe pas, un WM est un client X11 comme un autre, c'est juste la façon de l'utiliser (premier client lancé, les clients lancés ensuite le sont via l'api du WM) qui en fait une appli particulière. Ca ne changerait donc pas vraiment sous wayland.
[^] # Re: Gestionnaire de fenêtres
Posté par Mildred (site web personnel) . Évalué à 4.
Un WM, tu peux le tuer en cours de route, et tu peux le lancer après tous les autres clients. Et pour que les clients ait une décoration, il suffit qu'ils accèdent au même DISPLAY.
Essaie de faire la chose suivante:
Un WM n'a pas d'API pour lancer une application.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 2.
Hum si: la gestion des fenêtres se fait par le processus compositeur (Weston) sur Wayland.
Sur X la gestion des fenêtres se fait par un processus séparé.
Et par défaut les 2 ne font pas tout a la même chose car sur Wayland par défaut c'est le client qui dessine ses décorations de fenêtres.
[^] # Re: Gestionnaire de fenêtres
Posté par glisse . Évalué à 3.
Tu te trompes ;)
L'idée c'est d'utiliser EGL & GLES2. EGL c'est un API standard pour pouvoir créer des contexts OpenGL ou OpenVG ou autre (rien d'autre dans le standard pour le moment). Donc tu écris ton compositeur wayland avec EGL, tu crées un context opengl (wayland encourage d'utiliser GLES2 parceque c'est en gros opengl 2.0 - opengl 1.0 et que ca correspond as ce que supporte tous les GPU embedded).
Et voila c'est exactement comme les compositeur actuel. Tu fais de l'opengl, et les bugs GPU bah c'est des bugs du driver GL.
Bon je simplifie un peux parceque tu as aussi besoin de faire le modesetting mais ca y a deja des librairies pour utiliser KMS et faire le boulot a ta place. Ou tu peux copier le code de weston.
La vérité c'est que la partie modesetting & creation de context ca doit être 1000lignes de code en plus par rapport a un compositeur X. C'est pas grand chose et c'est standard si tu utilises EGL et KMS (KMS linux only pour le moment).
[^] # Re: Gestionnaire de fenêtres
Posté par brendel . Évalué à 1.
Ça veut dire qu'il faut impérativement utiliser openGL pour faire un compositeur? Comment je fait un compositeur qui ne nécessite pas d'accélération materielle de la part du GPU?
[^] # Re: Gestionnaire de fenêtres
Posté par glisse . Évalué à 2.
Tu utilise un truc comme llvmpipe (opengl avec CPU). Ou alors tu fais ton propre truc de rendu software mais la ton probleme ca sera les clients wayland, car c'est eux qui font le rendu de leur fenetre. Donc il faudra aussi que tu portes les toolkit pour qu'il marche en GL ou avec autre chose.
GL c'est le denominateur commun choisi implicitement parceque tout les platformes de ces 5 dernieres annees le supportent.
[^] # Re: Gestionnaire de fenêtres
Posté par cedric . Évalué à 2.
Non, il y a un vrai probleme de design dans Wayland de ce cote la. Tu ne peux pas faire un compositeur software (avec llvmpipe ou un truc plus efficace/adapte pour de la 2D) et avoir une fenetre d'un client en OpenGL.
C'est genant comme probleme. Principalement parce que les drivers dans le cadre d'un utilisation en compositeur sont en tres mauvais etat et que si tu ne peux pas avoir de fallback soft, tu termines sur une machine completement instable. L'autre raison, c'est que certaine carte OpenGL savent gerer un nombre fini de context OpenGL au dela duquel elles ont de tres mauvaise performance. Il est donc opportun de faire tourner le compositeur en soft dans ce cas la. Les performances d'un truc comme llvmpipe sont pas excellente pour faire de la 2D, mais avec un bon moteur de rendu 2D, tu peux facilement etre aussi performant qu'un rendu OpenGL dans les scenario classique d'un compositeur.
Donc c'est un probleme a regler et pour l'instant, c'est pas encore fait.
[^] # Re: Gestionnaire de fenêtres
Posté par brendel . Évalué à 2.
Je comprend pas bien la différence avec X de ce coté là. Dans X une appli fait son rendu en OpenGL ou non, envoi le résultat à X, qui va envoyer le tout au composteur qui peut choisir d'utiliser openGl ou non, c'est bien ça? Alors pourquoi Wayland ne peut pas faire ça? Les client Wayland feraient leur rendu en openGL et l'enverrait au compositeur qui pourrait faire la composition en soft.
Sinon vu l'état des drivers libres actuels (surtout nouveau) ça me semble aussi risqué de proposer un truc qui ne marche pas sans accélération graphique.
[^] # Re: Gestionnaire de fenêtres
Posté par navaati . Évalué à 10.
Ben tu te trompes :)
J'avais la même inquiétude (z'OMG que va devenir mon XMonad :'( ?), mais j'ai été sur IRC proposer une idée et on m'a dit que c'était possible et que c'était même la solution envisagée à long terme.
Reprenons le schéma d'architecture de Wayland :
Ce qui te fais peur ce sont ces petites flèches 1 et 4 que tu vas devoir implémenter dans ton wmii, right ? Ben en fait c'est toutafé possible d'ajouter un bloc à cet endroit là, qu'on appellera compositeur système. Lui va parler au noyal direct, et ton wmii va parler au compositeur système en utilisant le protocole… Wayland. Qui est bien plus simple que evdev+kms. De plus ça impliquera que ton WM/compositeur sera automatiquement (enfin, à condition qu'il existe un "compositeur système" idoine) portable sur d'autres plateformes que kms+evdev, par exemple la plateforme X11 ou la plateforme "nested wayland" ou "fb + gpm" ou encore "api graphique de *bsd + api events de *bsd".
Bien sûr, par rapport à un bon vieux WM X, t'as quand même un truc en plus à gérer : le compositing, qui dans sa forme la plus simple revient à pas grand chose : un blit par fenêtre à l'endroit où t'as décidé de la poser. T'as aussi à faire la distribution des events (mon focus est sur telle appli donc c'est vers elle que je route les évènements).
Mais ça, ça a un avantage certain : les possibilités offertes à ton WM explosent. Franchement imagine un wmii qui a accès à tout le pouvoir offert à un compositeur : ça fait rêver.
Bon tu vas me dire, "argh, rajouter un bloc en plus dans le schéma juste pour faire la traduction (kms,evdev) -> (wayland sous-partie graphique, wayland sous-partie events), c'est moche, et les perfs ? Y se trouve que le fameux compositeur système, il a aucune opération graphique à faire, juste forwarder ce que ton compositeur/WM a produit. Et comme on est dans un monde moderne de buffers graphiques partagés, y peut se contenter de dire à la carte graphique (via KMS) "le scanout buffer que tu dois sortir à l'écran, c'est ". Et hop, zéro copie, zéro overhead.
[^] # Re: Gestionnaire de fenêtres
Posté par Thomas Douillard . Évalué à 6.
WMonad ?
[^] # Re: Gestionnaire de fenêtres
Posté par navaati . Évalué à 2.
En fait dans le context de Wayland, un WArrow me semble bien plus pertinent (les haskelleux comprendront… peut-être).
[^] # Re: Gestionnaire de fenêtres
Posté par dinomasque . Évalué à 1.
Windows et Mac OS X y arrivent très bien.
Pourquoi voudrais-tu que Wayland en soit incapable ?
BeOS le faisait il y a 20 ans !
# Mauvaise foi
Posté par monde_de_merde . Évalué à 9.
Je suis sidéré par le nombre de commentaires de mauvaise foi, que ce soit volontaire ou juste par flemme de s'informer correctement, que j'ai pus lire à chaque nouvelle sur Wayland, ici ou ailleurs.
Il y a un nombre considérable de commentateurs qui brandissent l'abstraction du réseau et l'habillage des fenêtres comme arguments "imparables" en faveur de X alors que fondamentalement ce ne sont pas des obstacles techniques mais plutôt une question d'intérêt des développeurs (il faut croire que contrairement à ce que l'on veut nous faire croire, la transparence réseau n'est pas vitale puisque aucun des développeurs de Wayland ne s'en est préoccupé jusqu'à présent et qu'aucun de leur employeur respectif n'a cru bon de les incités à le faire) et d'organisation de l'UI (Windows comme Mac OS X permettent aux applications de dessiner elles même leurs décorations, et ce n'est pas l'apocalypse annoncé...).
Ça me déprime un peu quand à l'état et l'existence de "la communauté du libre".
[^] # Re: Mauvaise foi
Posté par fearan . Évalué à 9.
Là où je bosse en ce moment c'est bourré de gens bossant en ssh -X, putty + X forwarding, et rlogin + export DISPLAY; et le réseau arrive à saturer de temps en temps, si wayland augmente la charge réseau, il va y avoir un gros problème.
Alors ça peut ne pas être un obstacle pour les développeurs, mais c'est quand même utilisé. J'ajouterai que quand je dépanne ma mère qui a un problème de disparition de certains éléments de son IHM, je suis bien content de faire un ssh -X lancer l'appli corriger le problème, et fermer l'appli. Généralement la console me suffit, mais si la consommation réseau augmente, je passerai à un truc inutilisable.
Sans oublier qu'avec la virtualisation la politique est de centrer toutes les apllis sur une grille et y travailler en déporté, ce serait un peu con de perdre cet avantage.
C'est aussi un problème du libre, comme chacun à plus ou moins son mot à dire tu vas les entendre si tu supprime une fonctionnalité qu'ils utilisent.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvaise foi
Posté par monde_de_merde . Évalué à 6.
Le truc il est là, où les gens ont vu que qu'"on" allait supprimer une fonctionnalité ? Sérieusement où ? L'équipe de Wayland ne touche pas X, je sais pas ce qu'il leur faut aux ayatollah...
La transparence réseau est un peu utile certs. Mais que les gens qui l'utilisent prennent les armes dés qu'on parle d'un truc qui ne convient pas à leur Workflow (flux de travail c'est hyper moche en français) je trouve ça scandaleux. Personne n'a mis de couteau sous la gorge de personne, d'une part. Et d'autre part les développeurs ont beau se tuer à répéter que X peut tourné en client Wayland, que quitte à développer un compositeur proxy on peut y ajouter la compression des buffers etc... Rien n'y fait, en lisant les commentaire on a l'impression que Wayland va tuer le "libre" (oui, au grand complet, avec les femmes, les enfants, les vaches les veaux, tout).
Que les gens s'exprime, encore une fois c'est très bien, mais Linux et sons écosystème sont assez victime du FUD ambiant pour que ses utilisateurs ne s'y adonne pas en plus non ?
[^] # Re: Mauvaise foi
Posté par fearan . Évalué à 6.
Je suis complètement d'accord sur le fait que Wayland est une innovation, et qu'il devrait, à terme, remplacer Xorg, là où je suis plus dubitatif, c'est justement les ayatollah qui prétendent que tel truc et peu utilisé et que ce n'est pas la peine de s'en charger.
Oui on était pas forcé de passer à kde4 ou gnome 3, enfin suffit de ressortir les journaux de l'époque pour se rendre compte que c'est pas toujours aussi facile.
Vu que le réseau où je suis sature de temps en temps, me prononcer contre un encombrement réseau plus important ne fait pas partie de ce que j'appelle un FUD, mais une remarque constructive sur les points à améliorer.
Le passage à Wayland se fera de manière quasi certaine (a moins qu'on trouve mieux d'ici là), autant répondre au attente de chacun, plutôt que dire que telle fonctionnalité n'est utilisé que par 3 barbus.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvaise foi
Posté par monde_de_merde . Évalué à 2.
Oui on alors on s'est rendu que les progrès promis était finalement bien venu et pas aussi nul/rétrograde/contreproductif/whatever que prédit par leur détracteurs
En même la charge du réseau quand on envoie des buffers c'est peut-être une des seules critiques constructives sur une prise en charge du réseau par envoie de buffers que j'ai lu jusqu'à maintenant. En même temps on peut quand même laisser un tout petit peu de crédit aux développeurs et compter sur eux pour faire les choses intelligemment (compression, envoi uniquement de ce qui a changé etc...).
Et puis bon, le protocole X couplé à une interface moderne avec ses arrondis et ses gradients c'est loin d'être light en terme d'éléments primitifs à dessiner.
[^] # Re: Mauvaise foi
Posté par fearan . Évalué à 1.
Déjà il a les décorations en moins, et je te garantis que les applis métiers que j'utilise ne s'amusent absolument pas à avoir des dégradés à la con.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvaise foi
Posté par monde_de_merde . Évalué à 5.
En même temps les applis métiers tu vas pas t'amuser à les basculer sous Wayland parce que c'est le truc le plus mieux neuf donc bon... D'ici à ce que le support de X disparaisse on a le temps de voir de l'eau couler sous les ponts. Beaucoup d'eau même vu la durée du support d'une RHEL. Et changer le serveur d'affichage c'est pas comme mettre à jour l'environnement de bureau. Mais on en revient au premier point les développeurs de la pile graphique n'ont pas prévu de tuer quelque logiciel que ce soit. Si Wayland c'est "trop de la balle t'as vu ça déchire sa mère" (au minimum) alors oui X pourra disparaitre mais ça sera sans doute faute d'utilisateur vu l'importance du truc (même s'il y aura sans doute toujours des pour dire que c'était mieux à vent).
[^] # Re: Mauvaise foi
Posté par Jux (site web personnel) . Évalué à 2.
Surtout que Wayland peut faire tourner un serveur X en mode "seamless". Comme sous OSX quoi.
Donc ça ira très bien pour les applis métier.
[^] # Re: Mauvaise foi
Posté par letsyl . Évalué à 3.
Je ne comprends pas d'où sort cet encombrement réseau plus important ?
Les toolkits modernes (Qt, gtk, fltk, ...) se contentent d'écrire dans un buffer et de le transmettre à X. On a donc un pixmap non compressé qui est transféré au serveur X, donc à moins d'utiliser des applis écrites avec Motif n'importe quelle autre façon de faire sera plus efficace.
L'affichage déporté est d'ailleurs sur la TODO list de Kristian Høgsberg :
C'est en tout cas amusant de voir des gens qui ne maitrisent pas le sujet expliquer aux développeurs X (ou de pilotes graphiques) ce qu'il faudrait faire.
Quand on voit que mêmes les développeurs X "historiques" poussent vers Wayland (alors qu'ils pourraient être tentés de défendre leur "bébé"), j'ai du mal à comprendre qu'on ne leur fasse pas plus confiance.
[^] # Re: Mauvaise foi
Posté par reno . Évalué à 3.
Hum, ce qu'il dit me parait être un grand raccourci: regardes les GlyphSet d'XRender, X permet au toolkit d'envoyer du texte en distant de manière assez efficace (une fois que tu as transmis une glyphe tu peux la réutiliser..) et une recherche Qt GlyphSet m'a donné quelques résultats: donc apparemment ils utilisent ce mécanisme).
Pour le texte regarde plus haut, pour le fond effectivement envoyer les pixmap non compressé c'est pas terrible, mais c'est pour ça que NX compresse les pixmap il me semble(*), avec Wayland un buffer contiendrait à la fois le fond et le texte, donc si on essayait de compresser le buffer ce serait bien pire!
Pour le cas local, je ne vois pas pourquoi ce serait impossible d'ajouter a X des références vers de la mémoire du GPU de la même manière que la "shared memory" lui a été ajouté..
Et bien si les justifications de Kristian étaient plus convaincantes ça aiderait!
Quand LibreOffice a du code mort, ils le virent, ils ne changent pas totalement la conception..
*: personne n'a dit qu'X était idéal pour le réseau, NeWS ou Berlin/Fresco étaient meilleurs coté réseau (paix à leurs âmes), mais vu que Wayland sera pire de ce coté là, ce n'est pas un argument pour Wayland, c'est un argument pour intégrer NX à X.
[^] # Re: Mauvaise foi
Posté par claudex . Évalué à 4.
Tes propositions ont l'air tellement faciles que tout le monde se jettent dessus pour les implémenter.
« 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: Mauvaise foi
Posté par Jux (site web personnel) . Évalué à 4.
Ben peut-être qu'ils devraient un jour penser à repartir sur de nouvelles bases :-)
Plus sérieusement, tu compares deux projet qui n'ont rien à voir. X a vu un certain nombre de révisions depuis qu'il a été crée. On en arrive à un point ou le design original est complètement dépassé. Même si certain utilisent encore X sur le réseau aujourd'hui, on n'est plus dans le cas où il y a un serveur central avec des terminaux pour les applis de l'entreprise.
L'utilisation réseau de X est minimale. Wayland ne va pas rendre impossible cette utilisation, il va simplement l'enlever du coeur du design.
Bref, je pense que de temps à autre, toutes les quelques dizaines d'année, c'est pas complètement con d'avoir un redesign de certains logiciels...
[^] # Re: Mauvaise foi
Posté par Mali (site web personnel) . Évalué à 5.
Pourtant c'est l'avenir, j'ai beaucoup d'exemples autour de moi ou le PC de la comptable, DAF, responsable de production, etc .. se transforme petit à petit en terminal.
[^] # Re: Mauvaise foi
Posté par CrEv (site web personnel) . Évalué à 2.
Mouai, l'avenir, le passé, ça se mélange beaucoup à ce niveau...
Au mieux on pourrait parler en partie de cycle, mais il y a aussi beaucoup de cas où ce n'est clairement pas l'avenir, en tout cas pas version terminal comme on connaissait.
Entre autre, beaucoup d'ordi portables, notebook, tablettes, smartphones, et ceux là c'est pas des terminaux.
Par contre, c'est en partie des terminaux web + apps connectées, donc c'est un peu des terminaux.
[^] # Re: Mauvaise foi
Posté par Jux (site web personnel) . Évalué à 3.
Certe, l'aspect terminal reste, mais la grosse différence c'est que maintenant, ce sont des terminaux pour applis web. Donc il n'y a pas besoin des capacités réseau de X, suffit de faire tourner un navigateur.
Bref, je suis d'accord que les idées théoriques sont la même, mais dans la pratique, ce sont deux choses complètement différentes.
[^] # Re: Mauvaise foi
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
disons que maintenant le serveur d'affichage c'est gecko/webkit/etc. Je ne suis pas certain qu'on y gagne en performance (malgré les prouesses qui sont faites dans les navigateurs), jusqu'à ce qu'on fasse du WebGL pour toute appli un peu riche¹ et là on aura réinventé le bureau à distance over http).
¹ je pense à des outils comme blender qui ont un toolkit opengl, il doit être faisable de faire des trucs similaires en webgl non ? et quand on voit gtk3 porté sur html5, on se dit qu'ils pourraient faire encore plus performant avec webgl !
Il n'y aurai pas un créneau pour une appli "serveur d'affichage pour application distante" ? qu'on puisse installer partout comme un navigateur, et qui puisse se connecter au client avec une simple url ? On pourrait faire un truc comme
wayland-explorer wayland://google.com/mail, par exemple.Le succès des applications web est du au fait que l'accès demande une et une seule appli générique, et qu'il suffit d'avoir un navigateur compatible pour accéder à l'appli. Mais un navigateur web c'est d'abord fait pour du web (du contenu avec des hyperliens)…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mauvaise foi
Posté par Gof (site web personnel) . Évalué à 2.
En ce qui concerne Qt, il a plusieurs types de rendu:
- native, c'est celui qui utilise X11 et XRander pour le rendu de certains truc.
- raster, le défaut, tout est dessiné en software par le client.
- opengl, experimental, instable et non supporté
raster est maintenant le défault pour plusieur raisons:
Premièrement, il est beaucoup plus rapide en pratique. Pour de jolies interfaces QML il faut dessiner à 60fps. Dessiner tout en sofwtare est beaucoup plus rapide que de faire des roundtrips entre le client et le serveur.
Compare le scolling d'application KDE quand tu les lance avec --graphicssystem native ou --graphicssystem raster
Et puis comme ça, le rendu est le même sur toute les platforme. En effet, avec X11, certaines API de produisaient des résultats légèrement différent de platformes en platformes. Maintenant, c'est unifié.
[^] # Re: Mauvaise foi
Posté par reno . Évalué à 3.
Est-ce que c'est réglable application par application?
Le mode native parait adapté a une application affiché en distant et les 2 autres pour l'affichage local.
[^] # Re: Mauvaise foi
Posté par Gof (site web personnel) . Évalué à 4.
oui, il suffit de passer un paramettre comme argument.
--graphicssystem rasterpour les apply kde et-graphicssystem rasterpour les autres apply Qt.Il y a aussi une variable d'environement je crois, mais j'ai oublié le nom.
[^] # Re: Mauvaise foi
Posté par lolop (site web personnel) . Évalué à 2.
C'est bien pour les applications existantes (un des avantages de X: un serveur peut n'être qu'une simple application sur une machine, tournant par exemple sous Windows).
Le problème est pour l'utilisation distante d'es applications futures développées en se basant sur Wayland.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Mauvaise foi
Posté par houra . Évalué à 7.
parce que tu crois que chaque application inclut Xorg dans ses sources ?
Ou la XLib, qui aurait dû être remplacée par XCB ?
Allons allons, les applications graphiques, elles utilisent les bibliothèques GTK, Qt, la SDL, les EFL, ou wxWidgets quand c'est pas écrit en Java ou en Mono. Les applications, elles sont neutres vis-à-vis du protocole d'affichage utilisé. Et si certaines utilisent la XLib, elles auraient du de toutes façons passer à XCB à l'époque où les developpeurs de Xorg pensaient qu'il fallait reprendre le code de la XLib de zéro. Avant qu'ils pensent à changer le protocole de base.
Ce qui me fait peur , par rapport à Wayland, est d'un autre niveau.
C'est par rapport aux BSD: ne faut-il pas imaginer un système d'affichage indépendant totalement des cartes graphiques et des réseaux dans lequel la composition vient en module qu'un système tournant totalement autour de la composition ? Il faut noter que cette inquiétude peut aussi être appliquée à systemd.
Je pense que la " révolution " du graphique viendra d'un protocole totalement modulaire dont la base peut être la même sur les OS BSD et sur les distributions Linux.
Firefox, et maintenant The Gimp ont montré la force d'un ensemble composé d'une unité importante et de modules optionnels que l'on peut facilement greffer.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Mauvaise foi
Posté par claudex . Évalué à 5.
Wayland est une API qui ne dépend que d'OpenGL qui est disponible sur beaucoup d'OS. Le fait que ce soit Linux-only pour le moment est dû à l'utilisation de KMS (qui n'est pas nécessaire mais permet de faire les choses proprement sous Linux). On pourrait très bien imaginer un compositeur indépendant de KMS mais il faudrait que quelqu'un soit motiver pour le coder.
« 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: Mauvaise foi
Posté par navaati . Évalué à 2.
NON NON NON à la première phrase (désolé, pas contre toi, c'est l'usure)
Wayland ne dépends PAS de OpenGL, ou KMS, ou quoi que ce soit qui a à voir avec le hardware.
Exemple : imagine un compositeur qui utilise le framebuffer classique pour le dessin et + GPM pour les évènements.
Imagine que ce compositeur n'implémente pas l'extension DRM du protocole Wayland (c'est cette extension qui permet de partager des buffers en mémoire GPU, et oui le protocole lui-même est modulaire), donc qu'il n'utilise que la bonne vieille SHM Unix pour récupérer les buffers des applis.
Imagine qu'il utilise, soyons fou, la SDL pour afficher un wallpaper et blitter les fenêtres au bon endroit sur l'écran.
Imagine que le GTK de ton appli fasse du pur rendu software dans un buffer en RAM.
Ayé, t'as une infrastructure Wayland complète qui tourne même sur BSD ou sous un linux sans autre pilote que vesafb. Bien sûr ça va ramer, sauf si t'as un gros proc, mais c'est normal : pas d'API d'accès au matos (DRM, KMS, OpenGL, toussa), pas d'accélération.
Bien sûr ya beaucoup de "imagine" dans mon exemple, pasque personne a développé ces cas de figures (enfin, SDL over FB ça existe déjà je crois, et rendu GTK en software dans un buffer en RAM aussi, il me semble (c'est une possibilité de cairo en fait)). Mais ce que je veux dire c'est que ya rien dans Wayland lui-même qui est pas portable ou même qui a besoin de pilotes graphiques.
Bon, en fait j'ai plus répondu à ce que tu as quoté : ce protocole modulaire indépendant de l'OS… c'est Wayland. Cool, nan ?
[^] # Re: Mauvaise foi
Posté par djano . Évalué à 1.
Calme toi, il a écrit Wayland la ou il aurait du écrire Weston. Il a simplement confondu l'implémentation avec le protocole.
Il sera fouetté 42 fois pour expier ce péché.
[^] # Re: Mauvaise foi
Posté par reno . Évalué à 3.
Non plus: Weston n'est pas une API, donc remplacer Wayland par Weston dans son post ne le rend pas beaucoup plus correct.
[^] # Re: Mauvaise foi
Posté par reno . Évalué à 3.
Je pense qu'il faut prendre 'application' au sens large (application ou toolkit) dans son post pour comprendre son point.
On va dire 2 ans pour stabiliser Wayland, 2 ans pour que les toolkits l'exploitent bien: à l'horizon 2015 si tu dépends d'X pour les accès distant en WAN, il y aura de quoi être nerveux: l'histoire d'XCB l'a montré les toolkits essayent vraiment de supporter X "a minima".
[^] # Re: Mauvaise foi
Posté par Prae . Évalué à -4.
Ca me fait penser à Linus qui dit que "c'est super utile sous un shell, ca va plus vite". Ah ouais, mais dans les faits, c'est plus lent. (ou c'est pas utile hormis le mec qui fait une compile)
La part de marché du nombre de personne faisant du SSH+XFwd/Export Display = peanuts.
Et le nombre de personne qui voudrait bien qu'on avance un peu syr le desktop linux et qu'on arrête d'avoir des trucs tout pourri comparé à MacOSX ou même Windows ...?
[^] # Re: Mauvaise foi
Posté par fearan . Évalué à 9.
La part de marché de machin utilisant truc sous linux c'est peanuts. Tu peux remplacer machin par a peu près tout ce qui tourne sous linux hormis la glib, le LSB (et encore), firefox (et encore avec ice-weasel, chromium et autre...).
Enfin bref linux c'est la diversité et le choix, je code sous emacs, mon voisin de bureau sous vim, au bout du couloir, il y a des hérétique avec eclipse, on en a sous net beans, un transfuge sous xemacs, de temps en temps un qtCreator qui traine...
Et tout ça rien que pour du code; Et dans le lot TOUS utilisent un export DISPLAY quelconque ( dont au moins 1 avec xhost +, j'adore le 1er avril)
J'ajouterai que cette part de marché est tellement ridicule que nous ne trouvons aucun serveur X sous windows (xming, Sylpheed...) ni de client ssh ayant le X11 forwarding intégré (putty)
Oui c'est clair pour jouer, c'est mieux d'avoir un windows; en attendant pour bosser, je suis nettement plus efficace sous linux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvaise foi
Posté par niconoe . Évalué à 0.
Veux-tu m'épouser ?
[^] # Re: Mauvaise foi
Posté par monde_de_merde . Évalué à 4.
Je suis promis à L. Pottering déjà, désolé. J'aime les sujets à trolls ça m'aide à me sentir supérieur et lui il les génère par kilotonnes.
[^] # Re: Mauvaise foi
Posté par Sébastien B. . Évalué à 3.
Je suis entièrement d'accord avec toi, juste par contre, citer Windows comme exemple de "c'est pas l'apocalypse que les applications puissent dessiner eux même leur fenêtre", ça me parait un peu bizarre. Quand je dois utiliser du Windows, je suis effaré de voir le manque de cohérence de l'environnement quand tu utilise certaines applis tierces. Du genre tu lance Avast, itunes, chrome, Internet Explorer et Windows Media Player et t'as un environnement pas du tout intégré, avec chaque application qui pourrait être considérée comme jolie et bien faite (bon ça dépend par qui) mais qui, en formant un tout, sont absolument horrible.
Et perso, un environnement cohérent, j'adore ça. Bon, après, c'est pas de la faute de Windows et du fait que les applications peuvent faire ce qu'elle veulent, le problème, c'est les développeurs d'applications qui font n'importe quoi en terme d'UI.
[^] # Re: Mauvaise foi
Posté par Adrien . Évalué à 8.
Essaye de lancer au hasard mplayer, firefox et libreoffice dans un environnement KDE…
[^] # Re: Mauvaise foi
Posté par monde_de_merde . Évalué à 3.
C'était là ou je voulais en venir, c'est pareil que chez nous, donc bon, pas d’apocalypse (à moi que le monde soit déjà en train de brûler).
[^] # Re: Mauvaise foi
Posté par 태 (site web personnel) . Évalué à 0.
mplayer ? Si afficher une image, c'est ne pas être intégré, il ne doit pas y avoir grand chose d'intégré à kde.
[^] # Re: Mauvaise foi
Posté par Anonyme . Évalué à 1.
On parle d’intégration visuel hein.
Donc, vas-y, lance Firefox et LibreOffice(-KDE) dans KDE, tu verras, grâce à Qt, c’est plutôt bien intégré (visuellement).
[^] # Re: Mauvaise foi
Posté par Adrien . Évalué à 3.
Je sais très bien qu'on peut intégrer un minimum tout ces logiciels dans KDE, mais il existe très certainement d'autres exemple : les applications X ou Tcl/tk par exemple. On peut aussi faire l'inverse : du Qt dans du GTK, mais on peut contourner plus ou moins.
Le commentaire auquel je répondais sous-entendais que la non intégration des applications était l'apanage de windows, c'est simplement faux, tu peux très bien faire des trucs intégrés ou non sous windows et Linux, ça n'est pas une caractéristique du système.
[^] # Re: Mauvaise foi
Posté par spider-mario . Évalué à 1.
Je trouve que Qt s’intègre mieux dans GTK (grâce à QGtkStyle) que l’inverse (Oxygen-GTK est plutôt une réussite mais tout le monde n’utilise pas Oxygen ou QtCurve, je suppose).
[^] # Re: Mauvaise foi
Posté par Adrien . Évalué à 3.
Comme partout, il y a ceux qui blablatte et ceux qui contribuent…
[^] # Re: Mauvaise foi
Posté par steph1978 . Évalué à 1.
Je ne me prononce pas sur le contenu de ton commentaire puisque je n'y connais pas grand chose et que je n'ai pas vraiment compris ce que tu voulais exprimer.
Mais le "c'est surement pas important puisque personne ne s'en ai occupé" il est grandiose !
# [vendredi]
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Déja, le logo est grave moche. Alors que celui de X <3
[^] # Re: [vendredi]
Posté par Frederic Cambus (site web personnel) . Évalué à 1.
J'ai du mal avec le logo de Wayland également, d'ailleurs il fait carrément penser au logo Motorola à l'envers :)
[^] # Re: [vendredi]
Posté par khertan . Évalué à 2.
Me fait plus penser à 'La Marque Jaune' (Blake et Mortimer) :)
# Distributions Linux
Posté par nigaiden . Évalué à 2.
Je fais partie de utilisateurs qui attendront longuement avant de migrer car d'après ce que j'ai compris de la dépêche Wayland ne m'apporte rien (ça marche, pas toucher). N'étant ni développeur X, ni packager, j'imagine que je me contenterai de migrer au moment où ma distribution Linux l'imposera. Du coup je me demande : les distributions comptent-elles fournir simultanément serveur X et Wayland ? Les toolkits pourront-ils être compilés avec deux back-ends ? Que deviendra xpenguins ?
J'imagine bien une transition similaire à celle de Gnome 2 vers Gnome 3, une scission entre ceux qui veulent faire la migration et ceux qui n'en veulent pas. Moi aussi je préparer le pop-corn...
# Pourquoi?
Posté par alpaga . Évalué à 3.
Bonjour à tous les lecteurs et contributeurs de linuxfr, cela fait plusieurs mois (années même) que je suis les dépêches du site et j'interviens ici pour la première fois.
La question que je me pose principalement pour Wayland, c'est quel intérêt? Je comprends qu'il y a peut-être un effet mode actuellement où il faut à tout prix détruire les "cathédrales" (logicielles) mais en l'occurrence ce n'est pas très utile. À la rigueur s'il souhaitait créer un X "light", d'accord mais là ce n'est même pas l'objectif.
On nous propose un nouvel environnement graphique qui apporte plus de problème qu'il n'en résout. Ce n'est pas tout à fait claire l'histoire des compositeurs/serveurs vu que wayland est quand même présent en tant que serveur lorsque l'on souhaite en utiliser un autre que Weston (qui est un peu le fonctionnement de X non?), ce qui sera déjà le cas pour les utilisateurs de KDE, donc ça risque peut-être de coincer lorsque l'on voudra utiliser une appli Qt/KDE hors de celui-ci (ou alors avoir plusieurs compositeurs de lancés en simultané comme X actuellement).
Avec tout ça ce qui est proposé, c'est juste une nouvelle API ou chaque appli doit se dépatouiller dans son coin, en faisant pour beaucoup la même tâche donc une surcharge de travail pour pas grand chose? Et si j'ai bien compris, wayland aura quand même besoin de X pour pas mal de cas donc il faudrait que les deux tournent simultanément.
Qui plus est, certes gnu/linux est l'os libre le plus utilisé en desktop (je l'utilise d'ailleurs) mais "fermer" en quelque sorte l'environnement aux autres et un peu à l'encontre de la philosophie du libre.
Je plains d'avance les distribs qui choisiront wayland pour essuyer les plâtre. (ubuntu?)
Le seul avenir (lointain) que je peux voir pour Wayland serait un serveur d'abstraction pour plusieur environnement (X ou autre) mais à part ça je le trouve bien maigrelet pour détroner X.
Dites moi si je me trompe mais tout ceci n'a pas grand intérêt en soit?
[^] # Re: Pourquoi?
Posté par claudex . Évalué à 3.
Parce que X ne marche pas, comme dis dans la dépêche
Cela rend les choses compliqué à maintenir et certaines fonctionnalités, comme l'activation d'un GPU à la demande (le truc de nVidia) n'est pas imaginable dans l'état actuel des choses.
Je ne vois pas d'où tu sors ça.
Non, KDE peut tourner avec un autre WM que Kwin et pourra tourner avec un autre compositeur que Kwin. Wayland ne fait que définir une API pour interagir avec le compositeur.
Je ne vois pas pourquoi. La transparence réseau peut se faire avec Spice 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: Pourquoi?
Posté par reno . Évalué à 2.
Augmenter les performances en local.
Ce projet vient de l'embarqué: ça répond très bien à leurs besoins.
Pff, tu pourrais faire un peu plus attention en lisant les descriptions..
Wayland c'est une interface, une API (comme X), qui sera accessible a partir de librairie qu'utiliseront les clients et les serveurs (Weston et autres).
Dans le système Wayland, il y aura un seul processus serveur qui fait compositeur et gestionnaire de fenêtre.
En théorie oui, mais en pratique les devs Qt/KDE ont bossé pour que tu puisse utiliser une appli Qt/KDE sous GNOME sans que tu voie trop la différence (et vice versa), donc je pense qu'il y aura la même chose avec Wayland.
Pour la compatibilité et la transparence réseau "efficace" oui. Si tu n'utilise pas ça non.
Probablement Ubuntu oui: ils visent l'embarqué.
Hum, ta boule de crystal est plantée, une fois que l'application a rendu son image dans un buffer c'est trop tard pour X! Enfin techniquement tu peux, tu as juste des performances réseau pourrie..
[^] # Re: Pourquoi?
Posté par reno . Évalué à 4.
Hum, dommage qu'on ne puisse pas s'auto-moinsser: la partie augmentation des performances en local est fausse depuis qu'X peut fournir un buffer du GPU (DRI) a son client..
Donc effectivement la question de l'intérêt de Wayland se pose.
# Pourquoi un tel désintérêt pour X ?
Posté par Anonyme . Évalué à 3.
Une chose me frappe. Visiblement X répond déjà à tous nos besoins, mais il présente a posteriori un défaut d'architecture en séparant le compositeur et le serveur. Ce défaut ne peut-il être corrigé dans X ?
Deuxième point. Il semble qu'une grande partie de X est inutilisée ce qui laisse croire que X n'est pas capable, au hasard, de redessiner une fenêtre sans clignotement, alors qu'il l'est. Pourquoi les développeurs des toolkits graphiques ne tirent-ils pas partie de tout X ? Si ce n'est pas possible parce qu'en fait ces fonctionnalités sont cassées, pourquoi en tirer un prétexte pour tout redévelopper au lieu de les retirer ?
On m'a soufflé qu'un manque cruel de développeur X en est la cause. En quoi lancer Wayland résoudrait ce problème ?
Au final, dire que X est sous-utilisé ressemble fortement à la rage...
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par claudex . Évalué à 3.
C'est un système plus compréhensible (parce qu'il ne doit pas se trainer tout une pelleté de fonctionnalités plus forcément utiles), ça motive plus les gens.
C'est plus le changement d'archtictue qui a motivé Wayland à mon avis.
« 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: Pourquoi un tel désintérêt pour X ?
Posté par reno . Évalué à 1.
Ce n'est pas le seul: il faudrait aussi ajouter un mode ou les clients puissent envoyer une référence vers un buffer dans la mémoire du GPU (et non plus seulement en mémoire principale partagée).
Techniquement tout est possible, c'est au niveau de la main d'oeuvre/volonté que ça pèche.
Pour X en rien, qui te dis que les développeurs de Wayland veulent résoudre les problèmes d'X??
Ils veulent résoudre leur problème qui est de faire un système d'affichage efficace en local pour l'embarqué.
Hein? Personne n'a dis ça, tu as lu de travers. L'article dit juste qu'X a plein de fonctionnalité non-utilisée car obsolète, ce qui complique la maintenance du serveur X.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Anonyme . Évalué à 1.
Lancer autre chose la dilue.
A partir du moment où on parle de remplacer X en général, (l'embarqué n'est pas mentionné dans la dépêche), c'est aussi leur problème.
Je ne lis pas de travers. C'est tout de même un point important cité dans la partie "Pourquoi X n'est plus adapté". Par contre je n'ai pas encore pris le temps de parcourir les liens en référence. Ça me donnerait peut-être la hiérarchie des problèmes qui motive la création de Wayland.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par djano . Évalué à 2.
Sauf si la base (le protocole X et son implémentation X.org) est la raison originelle du manque de main d’œuvre.
Pour faire court: X embarque une tripotée d'API qui ne sont quasiment plus utilisées aujourd'hui. Elles étaient très utilisées et adaptées lorsqu'X a été créé, mais ne correspondent plus aux usages actuels (OpenGL). Beaucoup de ces fonctionnalités ont été sorties de X (gestion des fontes directement dans GTK ou Qt, KMS, etc.). Le problème c’est que pour qu'un logiciel puisse clamer être un serveur X, il doit implémenter toutes ces fonctionnalités obsolètes. Donc, a un problème d'architecture mentionné plus haut, s'ajoute un problème de conception qui n'est plus en phase avec son temps.
Comme avec tout logiciel devenu historique (legacy), on peut soit ne pas toucher beaucoup a son cœur et lui rajouter des extensions (c'est ce que l'on a fait jusque la avec X), jusqu’à ce qu'on le remplace, car trop lourd, trop cher, on peut faire mieux, etc.
Je crois que nous en sommes arrivés a ce point.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Olivier Serve (site web personnel) . Évalué à 10.
À l'époque où X a été conçu, les interfaces étaient simples à construire : des lignes, des rectangles, des ellipses, des à-plats de couleurs. Il était donc logique de concevoir le protocole autour de primitives simples de ce type. C'était une approche vectorielle du rendu qui correspondait aux besoins d'alors.
Maintenant, il faut dessiner des dégradés, des arrondis, gérer la transparence... C'est beaucoup plus complexe, et le protocole X n'est pas adapté. Les boîtes à outils que sont GTK, Qt ou les EFL, ont donc modifié leur façon d'utiliser X : elles font le rendu elle-mêmes et envoient l'image résultante au serveur X. On est maintenant passé à une approche 'bitmap'.
Au final, le protocole ne sert plus qu'à gérer les évènements et transférer des images. Si une grande partie de X est inutilisée, c'est qu'elle est devenue obsolète car ne répondant plus aux besoins.
Wayland est né de ce constat : X n'est plus adapté à l'utilisation qu'en ont les applications.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . Évalué à 6.
Bien supporté par XRender (qui dans X). Et note que l'approche 'bitmap' peut utiliser bien moins de bande passante quand tu envoie d'un coté le texte (GlyphSet), de l'autres les "images de de fond" plutôt qu'un buffer qui contient une image de la fenetre (va essayer de compresser ça sans induire de retard!).
Bof, c'est une justification foireuse: du même constat tu pourrait dire, faisons X12 qui vire tout le code mort/inutilisé (draw stippled line) mais qui garde XRender.
Pour les toolkits, ça changerait même moins de chose!
Je le répète la vrai justification de Wayland c'est d'avoir un rendu local plus performant pour l'embarqué.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Anonyme . Évalué à 0.
Exactement mon constat de départ, mais je n'ai pas voulu le dire si directement.
Ce qui pose un tout de même un problème si Wayland est présenté et reçu comme un successeur de X, puisque X n'est pas dédié à l'embarqué.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par nud . Évalué à 7.
Faire cela reviendrait au même:
Bref, il faudrait toucher toutes les applications. Sauf qu'en plus:
Donc, autant partir d'une feuille blanche:
Ceci dit, si on avait baptisé Wayland X12 sans rien changer d'autre, peut-être n'y aurait-il pas eu matière à troll.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Anonyme . Évalué à 1.
Ce n'est pas un troll mais une demande d'éclaircissement. Je ne suis pas un développeur X/Wayland donc je m'en remets à leurs choix éclairés. Je cherche juste à comprendre les réelles motivations de ces changements et ce qu'ils impliquent, car la dépêche est un peu courte.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . Évalué à 1.
Ton poste est un peu du n'importe quoi, si on ferme les yeux tout se ressemble OK, mais bon dire ça ne fait pas beaucoup avancer les choses..
Une petite évolution ou une révolution qui change totalement les caractéristiques réseaux du système je ne trouves pas que ça revient au même!
Quelque chose me dit que tu ne dois pas avoir besoin de l'affichage distant autrement tu ne penserais pas ça..
Tu ne peux pas appeler Wayland X12 pour la même raison que tu ne peux pas appeler (Quartz + VNC) X12: même si l'incrémentation du numéro de version signifie "incompatible" il faut quand même que:
1- cette incompatibilité soit limitée
2- le nouveau système reste dans l'esprit X: l'esprit initial était de faire un système avec la transparence réseau donc efficace en utilisation de bande passante, d'abord tout le rendu coté serveur, puis quand ça a posé des problèmes on est passé a un équilibre entre le client et le serveur avec XRender (les fontes sont rendues sur le client et cachées sur le serveur par exemple Glyphset), dommage cependant que la possibilité de compression des bitmap pour le fond ait été ajouter dans NX mais pas dans X..
Le système de Wayland d'avoir l'application qui rend toute la fenêtre et tant pis pour la bande passante utilisée me parait totalement différent de l'esprit X: si tu veux vraiment résoudre les problèmes d'X et avoir à la fois un système efficace en local et en distant tu n'obtiens pas Wayland, tu obtiens un mélange X(XRender), de NX (compression des pixmap, diminution du nombre de RTT) et de Wayland (passage de buffer dans la mémoire du GPU entre le client et le serveur).
Par contre si tu veux résoudre les problèmes de l'embarqué (rien à faire de la transparence réseau, mais il faut que ce soit efficace en local) alors là oui, tu obtiens Wayland.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Jux (site web personnel) . Évalué à 4.
De l'embarqué et de 90% des utilisateurs desktop.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par reno . Évalué à 2.
Bon depuis DRI(DRI2?) X peut passer des adresses de buffer GPU en local donc rayons ce point là, par contre Wayland a le serveur d'affichage, gestionnaire de fenêtre et le compositeur dans le même processus (Weston) ce qui semble être un changement intéressant.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Anonyme . Évalué à 2.
Merci de pointer enfin la raison de cette inutilité. De là je me pose une autre question. Les technologies comme SVG font le chemin inverse et prenant de plus en plus de place dans les navigateurs et les bureaux graphiques. Est-ce qu'on ne va pas se rendre compte dans 10 ans qu'on a fait une boulette en retirant les capacités vectorielles du serveur d'affichage alors qu'elles seraient devenues omniprésentes dans les applications ?
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par claudex . Évalué à 2.
J'en doute, où il faudrait sacrément étendre les possibilités vectorielles du serveur d'affichage (comme la possibilité de dégradés ou autres). Peut-être que dans 10 ans ce sera imaginable mais ce n'est pas le cas maintenant.
« 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: Pourquoi un tel désintérêt pour X ?
Posté par reno . Évalué à 2.
En local ça m'étonnerait, en distant: c'est possible.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Troy McClure (site web personnel) . Évalué à 10.
de toute façon le coté "vectoriel" de X11 c'est un peu comme dessiner des lignes et des rectangles avec microsoft Paint, on ne peut rien faire avec a part des traits moches et des elipses moches. Il n'y a donc rien a recuperer de ce côté là
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par Olivier Serve (site web personnel) . Évalué à 1.
On reviendra peut-être à une approche vectorielle.
Mais ce n'est pas pour autant qu'on aura fait une boulette en changeant avant. C'est juste que les besoins et possibilités auront à nouveau évolué, rendant le vectoriel plus adapté (si cela se produit).
# Un peu d'info
Posté par Nerdiland de Fesseps . Évalué à 7.
À lire les commentaires, il y a encore beaucoup d'incompréhension et de questions vis à vis de Wayland. Pour un complément d'informations par rapport à cette dépêche, je vous invite à lire l'article sur The H qui détaille l'historique du projet.
En résumé:
- X est lourd et lent
- Il est basé sur des principes d'architectures qui ne sont plus valides aujourd'hui
- Le code ayant presque 30 ans d'histoire et étant très complexe, peu de monde est capable de le comprendre et de travailler efficacement dessus
- Les applications actuelles n'utilisent qu'une infime partie des fonctionnalités de X
- X est déjà remplacé par d'autres gestionnaires sur certaines plateformes pour lesquelles il n'est pas adapté (Android a son propre système, Tizen lorgne sur Wayland, etc)
X étant devenu inadapté et trop difficile à faire évoluer, il était temps de développer un gestionnaire d'affichage moderne.
[^] # Re: Un peu d'info
Posté par reno . Évalué à 1.
Note que l'article sur The H et l'article ici reprennent tout les deux les mêmes "explications" fournies par le projet Wayland/par Kristian.
[^] # Re: Un peu d'info
Posté par patrick_g (site web personnel) . Évalué à 10.
En même temps Kristian ayant été un core dev de X, on peut penser qu'il est plus à même que nous d'évaluer les qualités et les défauts de X. Comme Keith Packard (gros barbu de X s'il en est) pense la même chose que Kristian je crois qu'on peut se ranger à leur avis.
[^] # Re: Un peu d'info
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
J'ai beaucoup d'admiration pour Keith mais au début des années 2000, après pas mal de boulot avec son équipe, il en a conclu que la transparence réseau dans X ne pouvait être amélioré car tout son boulot équivalait au final au travail du -C de ssh (un bête gzip) !
Puis, a peine son annonce faite, le tonnerre No-Machine avec NX !
NX est tout simplement FORMIDABLE en transparence réseau. Ce point est FONDAMENTAL tant pour plein d'utilisation que pour le développement distant. Le supprimer est une erreur fondamental et pousse encore aux applications web… et a une verbosité accrut du web ;-)
La question qu'on peux se poser, après toutes ces années, pourquoi NX, alors que toutes les bibliothèques sont libres, n'est toujours pas intégré au coeur d'X ?
[^] # Re: Un peu d'info
Posté par cedric . Évalué à 5.
Va falloir arreter avec X est lourd et lent. Ca depend uniquement des extentions que tu mets dedans. La difference de perf entre un rendu en framebuffer et un rendu via X est de 5%. Pour la consomation memoire, elle peut si il est bien configurer, descendre a moins d'un mega. Donc non, ce n'est qu'un mythe lie a des toolkit graphique pourri qui reporte la faute sur X au lieu de resoudre leur probleme architectural !
Le dernier point concernant Tizen, il y a certe une raison technique de lorgner sur Wayland (le merge du composite manager et de la gestion des input permet de gerer les rotations de maniere enfin correct), mais c'est a l'etat de projet de recherche pure. Wayland ne sera pas utilisable en production avant au moins un an voir deux.
# Appli X sans toolkit
Posté par Astaoth . Évalué à 1.
Je n'ai pas lu l'ensemble des commentaires pour voir si ma réponse y est, mais qu'en est-il des logiciels utilisant X, mais sans toolkit ? Je pense tout particulièrement à FVWM, mon gestionnaire de fenêtre préféré.
Emacs le fait depuis 30 ans.
# Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 10. Dernière modification le 21 février 2012 à 14:36.
Au cas où ça intéresserait des gens, voici un petit retour d'expérience sur le développement de Gecko (Firefox) / Linux et comment X est un gros boulet qu'on se traîne:
Les pixmaps X. Ce sont des images bitmap stockées du côté serveur X, c'est-à-dire des images en mémoire vidéo, comme les fameuses "textures" d'OpenGL. C'est très bien de stocker des images en mémoire vidéo, donc l'utilisation de pixmaps X a toujours été recommandée (en particuler en conjonction avec XRender mais pas seulement). Le problème vient justement de cette redondance entre pixmaps X et textures OpenGL. À partir du moment où l'on commence à utiliser OpenGL, on se trouve dans une situation où l'on a besoin de convertir efficacement des pixmaps en textures. C'est ce que fait l'extension texture_from_pixmap. Le problème est que les implementations de cette extension sont catastrophiquement buggées. En particulier dans les pilotes NVIDIA proprio et Intel libre. Conséquence: on ne peut pas activer l'accélération OpenGL du compositage dans Firefox tant qu'on ne se sera pas complètement débarrassés de l'utilisation de pixmaps.
XRender. C'était censé être une super API d'accélération 2D, une sorte de Direct2D avant l'heure. Le problème est que les performances des implementations de XRender varient si grandement qu'on ne peut pas savoir à quoi s'attendre. XRender peut être beaucoup plus rapide... ou beaucoup plus lent que du rendu logiciel.
Les erreurs X. C'est le cas d'école d'un système de gestion des erreurs raté. Les erreurs X sont asynchrones, donc pour obtenir le code d'erreur d'une fonction précise il faut synchroniser (XSync) juste après, et la synchronisation peut coûter extrêmement cher (surtout si le serveur X est ailleurs sur le réseau), donc on ne peut généralement pas se le permettre. Conséquence: on doit gérer les erreurs de façon vraiment asynchrone, ce qui veut dire que quand on reçoit une erreur, c'est généralement bien après qu'elle se soit produite... conséquence: il est alors généralement trop tard pour récupérer. Conséquence: les gestionnaires d'erreurs X consistent presque tous a simplement interrompre l'exécution du programme: boum, plantage! C'est le cas du gestionnaire d'erreurs X par défaut, de celui de GDK, et de celui de Mozilla. Il n'y a pas trop d'autre solution en général. Le pire est que les erreurs X peuvent se produire un peu n'importe quand, et ça dépend souvent de détails comme le pilote, le numéro de version du serveur... Une bonne partie des plantages "inexpliqués" de Firefox sous linux sont des erreurs X. (On peut le voir ici)
Gecko a besoin de savoir, avant de demander un contexte OpenGL, si c'est bien raisonnable: en effet, sur certains systèmes (problème avec un pilote, le serveur, etc), créer un contexte OpenGL résulte en un plantage ou une erreur X, ce qui revient au même (cf. point 3). Donc on veut implémenter une "liste noire" de systèmes/de pilotes où il faut éviter de toucher à OpenbGL. Le problème c'est que X est la seule plate-forme où on ne peut pas obtenir ces informations sans... créer un contexte OpenGL (et appeler glGetString)! On peut bien appeler glXQuery{Client|Server}String mais ça donne très peu d'informations. C'est la raison pour laquelle dans Firefox 4 et 5 il était difficile d'activer WebGL. On a résolu ça dans Firefox 6 en forquant un processus séparé qui crée un contexte OpenGL et obtient les informations, comme ça s'il planté c'est pas grave.
[^] # Re: Comment X penalise Firefox / Linux
Posté par fearan . Évalué à 2.
Pour le deux je recommande (vue la taille de firefox), de faire comme kwin. Utiliser l'implémentation propre, et pas l'éviter par une solution crade; cela force les éditeur ou développeur à faire un truc plus chiadé. Ça a très bien marché avec kwin les driver graphique ont été améliorés, je ne vois pas pourquoi ça ne marcherai pas avec firefox (faut juste communiquer la dessus, et expliquer le pourquoi du WONTFIX).
Pour ton point 3 j'aimerai bien voire comment tu implémenterai des remonté d'erreurs sur une appli réseau qui doit être réactive.
Pour le point 4, pareil que le 2 avec un binaire firefox-NoWGL, pudiquement nommé dans les menus firefox mode sans echec.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Comment X penalise Firefox / Linux
Posté par reno . Évalué à 2.
Pour (1) pourquoi y a t'il besoin de convertir les pixmap et les textures OpenGL? C'est une question de format?
Pour (2), l'intérêt d'XRender c'est que ça permet d'utiliser efficacement le réseau, mais effectivement en local c'est probablement moins efficace que le modèle a la Wayland.
Pour (3), si je me souviens bien X était une "amélioration" de W qui lui était synchrone: je ne vois pas trop comment avoir des erreurs synchrone sur un protocole asynchrone, ni comment un protocole synchrone pourrait être efficace en distant.
Pour (4), ça parait être principalement un problème OpenGL donc il me semble que tu peut avoir exactement le même problème avec Wayland.
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Pour (1) imagine par exemple qu'on a rendu un paragraphe de texte avec Cairo dans un pixmap. Pour le compositing OpenGL, on va avoir besoin de lire ce pixmap depuis OpenGL, ce qui necessite de l'interpreter comme une texture.
Pour (2), note que OpenGL, comme X11, est une architecture client-serveur, concue elle aussi pour bien marcher en reseau. Il est vrai que pour du rendu 2D en reseau, XRender permet d'aller plus loin qu'OpenGL, parce que dans le rendu 2D, tout ne peut pas toujours etre fait par OpenGL. Mais la bonne facon de resoudre ca est de continuer d'etendre OpenGL pour couvrir ces besoins (la 2D, c'est dur).
Pour (3), je n'ai pas dit que c'etait facile. Tu peux voir mon point 3 comme un argument soulignant le cout reel d'avoir une architecture asynchrone en reseau. Il ne faut pas se voiler la face, X a ete concu pour des reseaux et quand on fait tourner un serveur X dans son petit portable en local, on paye bel et bien un cout pour ca, aussi bien en termes de perfs pour l'utilisateur, qu'en termes de complexite/bugs pour le developpeur d'applications.
Pour (4), en effet c'est probablement un probleme des pilotes.
[^] # Re: Comment X penalise Firefox / Linux
Posté par reno . Évalué à 2.
J'avais bien compris, mais ce que je ne comprends pas c'est pourquoi il y a une différence, pour moi les deux ce sont des buffers dans un GPU.
Hum, dernièrement OpenGL a eu tendance à se simplifier en retirant les machins obsolètes qui ne correspondait plus au mode de fonctionnement des cartes, donc j'ai comme un doute sur l'extension OpenGL sur ce point là ait un grand avenir..
Pour (3), Wayland a été décrit comme "violently asynchronous" par Kristian Høgsberg, alors je ne suis pas sûr que ça soit beaucoup plus simple..
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
On est bien d'accord! C'est pourquoi la situation est totalement absurde. Le concept est le meme, on a juste 2 implementation differents (pixmaps contre textures) et des frottements entre les 2.
Le seul truc qui ait jamais ete retire d'OpenGL c'est le vieux pipeline a fonctionnalite fixe. Au contraire, les fonctions utiles a la 2D sont un domaine ou du travail est fait cf par exemple l'extension NV_path_rendering.
Tous les systemes graphiques sont asynchrones, mais seul X11 pretend abstraire completement la presence d'un reseau entre le client et le serveur.
[^] # Re: Comment X penalise Firefox / Linux
Posté par claudex . Évalué à 8.
Est-ce que vous avez déjà communiquer avec les développeurs Wayland pour éviter que les mêmes problème se reproduisent avec 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: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Je ne sais pas si d'autres personnes a Mozilla ont fait part de nos besoins aux devs de Wayland, mais c'est en effet quelque chose a garder en tete.
A priori, comme tous les autres systemes a part X11 (Windows, Mac, Android) font le boulot correctement, on n'est pas inquiets: les problemes de X11 semblent specifiques a X11. Sauf mon point 4 peut-etre, mais si c'est un probleme au niveau des pilotes, c'est orthogonal a X-contre-Wayland.
[^] # Re: Comment X penalise Firefox / Linux
Posté par cedric . Évalué à 3.
Pour le point 2, je n'ai jamais vu de systeme sur lequel le rendu XRender etait plus rapide que le rendu soft. C'est pour cette raison que le projet Enlightenment a completement supprime son backend xrender depuis des annees.
Et vu l'etat des drivers OpenGL, heureusement qu'ils ne se concentrent que sur ce morceau du driver, sinon on n'aurait juste rien d'utilisable... Et ca, je ne pense pas que ce soit Wayland qui resoudra le probleme :'(
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 3. Dernière modification le 21 février 2012 à 18:59.
Par exemple, cette page tourne beaucoup plus vite dans Firefox quand ton pilote XRender accelere bien les operations dont elle a besoin (marche bien sur NVIDIA proprio et ATI libre 'radeon' au moins):
http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html
Et puis l'etat des pilotes OpenGL n'est pas si mauvais du tout. Les pilotes Mesa progressent a tres grand pas.
[^] # Re: Comment X penalise Firefox / Linux
Posté par nud . Évalué à 1.
Ici (Iceweasel 10 sous Debian) cette page ne contient rien... Est-ce censé utiliser WebGL ? Est-ce que WebGL est supposé fonctionner sous linux des temps-ci ?
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . Évalué à 2. Dernière modification le 22 février 2012 à 04:19.
Cette page n'utilise bien entendu pas WebGL, c'est une demo technologique pour IE9! Url en microsoft.com.
C'est bizarre qu'elle n'affiche rien chez toi, ca laisse supposer un gros bug de XRender.
Pour repondre a ton autre question, WebGL fonctionne sous linux depuis le debut (il y avait certes peu de pilotes autorises dans Firefox 4 et 5, probleme resolu depuis).
[^] # Re: Comment X penalise Firefox / Linux
Posté par moi1392 . Évalué à 1.
webgl marche bien sous iceweasel 10 de debian, tu peux tester ces démos faites pour chrome : http://www.chromeexperiments.com/webgl
[^] # Re: Comment X penalise Firefox / Linux
Posté par Guillaume Knispel . Évalué à 2.
Pour 1, 2 et 4, Wayland va régler le problème comment ?
# EGL et GLES2...
Posté par Benoit Jacob (site web personnel) . Évalué à 8.
Dans l'article:
Ca n'a pas beaucoup de sens, ca. GLES2 est une abbreviation pour OpenGL ES 2, une version d'OpenGL. (Enfin d'OpenGL ES, la version portable pour appareils embarques, mais c'est une variante d'OpenGL).
EGL est l'interface entre OpenGL ES et le systeme de fenetrage. C'est ce qu'on utilise pour creer un contexte OpenGL ES. Disons que EGL est a OpenGL ES ce que GLX est a OpenGL sous X11. Sauf que EGL est universel, on l'utilise partout ou l'on utilise OpenGL ES.
[^] # Re: EGL et GLES2...
Posté par claudex . Évalué à 2.
Merci de la précision. Je ne savais pas ce que c'était et j'avais fait quelque recherche pour essayer de comprendre mais je suis visiblement tombé à côté de l'info.
« 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
# Notifications clavier
Posté par Anonyme . Évalué à 4.
Le mode secure keyboard de XTerm (ou d'autres émulateurs X de terminal) ne l'utilise pas ?
[^] # Re: Notifications clavier
Posté par Tof . Évalué à 3.
Ainsi que les ssh-askpass, je crois ?
[^] # Re: Notifications clavier
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Comment font les logiciels qui capturent le clavier comme qemu, remmina¹ (client vnc, entre autres) ? Ou les logiciels type sudo et les trucs de déverrouillage lors d'une saisie de mot de passe (cela dit parfois ils oublient de rendre le clavier :/) ?
Est-ce la feature qui permet à gnome, lorsqu'on a un menu ouvert, de rendre inefficace les raccourcis claviers comme les touches multimédia, ou qui bloque la mise en veille : et hop on quitte le menu et si le temps avait été dépassé, oups-verrouillage-instantané-parceque-ce-fait-longtemps-que-ca-aurait-du-etre-fait (les trucs à la remmina font ça aussi) ?
Est ce que ce n'est pas utilisé aussi lors d'un verrouillage de l'écran, pour éviter justement que l'on puisse lancer des commandes en arrière plan avec des raccourcis (il y avait eu un journal récemment sur un raccourci qui passait à travers et avait le bon goût de désactiver le verrouillage) ?
Si c'est ça je l'utilise tout les jours (et subit les bugs aussi, mais je ne jetterai pas la fonctionnalité avec les bugs).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Notifications clavier
Posté par claudex . Évalué à 2.
Si mais si je me souviens bien, les développeurs de Wayland veulent faire un écran de veille propre qui soit gérer en tant que tel et pas comme une fenêtre comme les autres. Ce sera sans doute dépendant du compositeur.
Le but des développeurs est d'analyser les situations où c'est utiliser pour voir si la fonctionnalité est vraiment nécessaire ou alors il y a moyen de trouver un meilleur système.
« 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
# Xembed
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
y a t'il un truc à la Xembed ? et y aura-t'il compatibilité (à travers le serveur X11 rootless pourquoi pas) ?
Parce que ça c'est pratique aussi, mettre une application dans une autre un peu comme une iframe, sans être dépendant du toolkit, simplemnt de X :)
Sur mon tablet pc, le clavier tactile est accessible dans gdm grâce à Xembed (j'ai utilisé longtemps cellwriter en mode clavier, maintenant j'utilise onboard). Ça aussi c'est encore bien courant !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Xembed
Posté par Olivier Serve (site web personnel) . Évalué à 2.
C'est aussi ce qu'utilise KHTML depuis longtemps pour inclure l'affichage des plugins qui tournent dans des processus séparés. Un flash devenu fou n'entraîne pas le navigateur avec lui.
[^] # Re: Xembed
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et il y a un truc similaire pour mozilla : https://developer.mozilla.org/en/XEmbed_Extension_for_Mozilla_Plugins
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Xembed
Posté par navaati . Évalué à 1.
Dans l'idée, si tu veux faire un truc style XEmbed la solution la plus simple est que ton appli devienne un "mini compositeur Wayland" qui acceptera qu'un seul client : le machin embeddé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.