Pourquoi Wayland veut remplacer X

Posté par (page perso) . Édité par Jarvis, reno, Nÿco, baud123, NeoX, Benoît, Yves Bourguignon et Laurent Pointecouteau. Modéré par baud123. Licence CC by-sa
Tags :
88
21
fév.
2012
Serveurs d'affichage

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.

Logo Wayland

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 :

Schéma de l'architecture de X

Avec Wayland :

Schéma de l'architecture de 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.

  • # remote display

    Posté par . Évalué à  2 .

    Et le remote display, il disparait avec wayland ?

    • [^] # Re: remote display

      Posté par (page perso) . Évalué à  10 .

      Cherche "affichage déporté" dans cette belle depêche en français ;-)

      ⚓ À g'Auch TOUTE! http://agauch.fr

      • [^] # Re: remote display

        Posté par (page perso) . É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 . Évalué à  9 .

      Et le remote display, il disparait avec wayland ?

      La réponse est compliquée:
      1) en LAN, il y a plusieurs solutions:
      a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.

      b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
      La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".

      c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).

      2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
      Mais pour les autres cas, la bande passante utilisée sera trop élevée.

      Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..

      • [^] # Re: remote display

        Posté par (page perso) . Évalué à  -7 .

        La réponse est compliquée

        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 . É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 . Évalué à  4 .

          Pour la situation b), il faudrait sur le client un serveur wayland qui écrit dans un un buffer à lui et qui envoie les buffers par le reseau.
          Coté serveur, un client proxy qui ne fait que transmettre les buffers au vrai serveur.

          Ca ressemble furieusement à du Vnc ou rfb :)

          Oui.. Note qu'à l'heure actuelle Wayland ne transmet que des fenêtres complètes entre le client et le serveur donc ça ne sera pas très efficace, mais en LAN ça doit passer..

          Pour la situation c), il me semble que le serveur wayland exisant sait déjà quasiment le faire puisque il peut s'utiliser en tant que client X.

          Oups, tu as raison j'avais oublié ça, un comble puisque c'est comme ça que Wayland a bootstrappé!

        • [^] # Re: remote display

          Posté par . Évalué à  3 .

          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.

          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 (page perso) . Évalué à  2 .

      Et le remote display, il disparait avec wayland ?

      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 (page perso) . É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 (page perso) . Évalué à  7 .

          Je ne vois pas comment Wayland pourra faire ça.

          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.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: remote display

        Posté par . É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 (page perso) . Évalué à  7 .

        Est-ce que tu utilise tellement que ça le "remote display" ? Avec quelle type d'application.

        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 . Évalué à  1 .

        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.

        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 (page perso) . É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 (page perso) . É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://agauch.fr

    • [^] # Re: Migrations libres

      Posté par (page perso) . Évalué à  9 .

      Et comme c'est propriétaire, elles sont mortes.

      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 (page perso) . É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 . É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 (page perso) . É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 . Évalué à  6 .

          En effet quitte à pousser un desktop libre autant pousser Haiku qui est conçu pour cela

          Un desktop Haiku restera certainement beaucoup plus réactif qu'un desktop Linux (même avec Wayand), mais Haiku a fait l'énorme erreur d'utiliser un noyau (NewOS) très peu utilisé plutôt que Linux ou FreeBSD alors non merci: à cause de ce choix, il est quasiment sûr qu'Haiku n'atteindra jamais la "masse critique".

          Les développeurs de Wayland n'ont pas fait cette erreur eux..

          • [^] # Re: Migrations libres

            Posté par (page perso) . É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 . Évalué à  2 .

              Mais si une partie du serveur graphique est intégrable dans NewOS j'y vois un gros avantage en perf car ça n'arrivera jamais avec Linux.

              C'est le cas? Coté doc je n'ai rien trouvé..

              Sinon pour répondre à ta question: avec le Linux 'standard' non, mais qui t’empêche de faire ton propre patch?
              C'est du travail bien sûr, mais créer/porter tout les autres drivers à mon avis ça réprésente bien plus de travail..

              • [^] # Re: Migrations libres

                Posté par (page perso) . Évalué à  4 . Dernière modification : le 21/02/12 à 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 . Évalué à  5 .

        Alors plusieurs petites choses:

        • Il y aura un serveur X embarqué dans Wayland (un rootless X server), un peu similaire au support X11 dans MacOS je suppose, pour faire tourner des applications X11 comme si elles étaient "natives".
        • Les toolkits les plus courants ont déjà le support pour wayland donc y'aura même pas besoin de patcher.

        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 . É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 . Évalué à  4 . Dernière modification : le 21/02/12 à 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.

            Boîte de dialogue d’installation de X11 sous OS X

    • [^] # Re: Migrations libres

      Posté par . Évalué à  2 .

      'Et comme c'est propriétaire, elles sont mortes. '
      Comme tout le monde s'en fout elles sont mortes.

  • # Coquille

    Posté par (page perso) . É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 :-)

  • # Vous pouvez m'éclairer ?

    Posté par (page perso) . Évalué à  4 .

    Wayland est une nouvelle architecture pour un serveur d'affichage
    [...]
    Wayland intègre un serveur, un gestionnaire de fenêtre et un compositeur
    [...]
    Le serveur d'affichage de Wayland est en fait le compositeur
    [...]
    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
    [...]
    un compositeur de référence pour Wayland qui répond au doux nom de Weston

    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 ?
    ARchi wayland

    • [^] # Re: Vous pouvez m'éclairer ?

      Posté par (page perso) . É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 . Évalué à  2 .

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

        Non! Pour que Wayland soit utile, il faut utiliser une API qui permette de partage la mémoire du GPU entre le client et le compositeur (GEM il me semble), autrement tu te retrouves avec le cas suivant: le client utilise le GPU pour rendre son application dans un buffer du GPU puis il faut lire le buffer du GPU pour le mettre en mémoire principale (lent) et ensuite le recopier de nouveau sur le GPU pour le "composer" et l'afficher: autant utiliser X car ça tue les performances..

        Sinon d'accord avec toi, il n'y a pas d'API entre le serveur d'affichage et le compositeur: le serveur d'affichage est le compositeur.
        Dommage d'ailleurs que ça n'ai pas été fait pour X: rien dans X n'impose d'avoir le serveur d'affichage et le compositeur séparé, certes c'est plus modulaire mais à mon avis dans ce cas là ce n'est pas une bonne chose.

        • [^] # Re: Vous pouvez m'éclairer ?

          Posté par (page perso) . É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 . É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 (page perso) . Évalué à  9 .

    L'utilisation éventuelle de Wayland par les *BSD serait plus difficile : Wayland utilise des APIs présentes uniquement dans Linux actuellement.

    C'est dommage pour le libre.

    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.

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

    • [^] # Re: Wayland / X

      Posté par (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Wayland / X

        Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à  5 .

          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 ?

          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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 ...

            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 . É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 (page perso) . Évalué à  9 .

            Voila la doc tu l'as, maintenant faut plus pleurer !

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

            le code est la meilleur documentation

            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.

            Et rien n'oblige *BSD a utiliser les memes.

            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 . É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 (page perso) . Évalué à  3 .

                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.

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

                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.

                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 . É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 . Évalué à  2 .

          le monde propriétaire quand il livre des immondices sans specs : l'éco système linux fait la même chose

          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 . É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 (page perso) . Évalué à  2 .

          Il suffira d'utiliser un compositeur qui ne nécessite pas de KMS.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Wayland / X

            Posté par . É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 (page perso) . É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.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Wayland / X

                Posté par . É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 . Évalué à  4 .

      Ça permettra aux applications X de continuer à tourner, c'est déjà ça.

      Euh non, ça permettra aux applications GTK, Qt (etc) de tourner, mais pour les applications pure X (il y en a peu OK) il faut installer un serveur X/client Wayland pour la compatibilité: pas de problème ça existe déjà.

      Pour ta seconde question, il n'y a pas actuellement l'équivalent de KMS sur les *BSD (pas sûr pour les autres API), mais je pense que ça viendra: ne serait-ce que pour pouvoir éviter d'avoir X en tant que root c'est intéressant.

  • # Fenêtre

    Posté par . É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 . Évalué à  10 .

      Tu te trompes.

      Depending on the time of day, the French go either way.

    • [^] # Re: Fenêtre

      Posté par (page perso) . É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 . É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 (page perso) . Évalué à  9 .

      Pour les décorations, ça dépendra du compositeur. Je cite la dépêche:

      Les décorations de fenêtre sont à la charge des clients plutôt qu'au serveur³;
      ³ : 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 l'intérieur de la fenêtre, chaque application fait déjà ce qu'elle veut avec X.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Fenêtre

        Posté par (page perso) . É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 (page perso) . Évalué à  3 .

          Non, ça veut dire que Kwin ne mettra pas les décorations que tu as dessiné mais les siennes.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Fenêtre

            Posté par . É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 (page perso) . É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"

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Fenêtre

                Posté par . É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 (page perso) . Évalué à  2 .

                  La version 1 n'est pas encore sortie non plus.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: Fenêtre

                    Posté par (page perso) . É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 (page perso) . É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 . Évalué à  5 .

                        Quid des applications qui plantent? On ne peut plus bouger la fenêtre......

                        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 ?

                        Quid de l'optimisation des SPANS pour tracer les pixels dans la carte graphique de manière optimisée est en droppant les doublons?

                        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.

                        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.

                        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.

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

                        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.

                        Quid du remote display qui meme s'il est possible N'EXISTE PAS et RESTE A DEVELOPPER.

                        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 .

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

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

                        Quelle perte de temps!

                        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 . É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 . Évalué à  3 .

                            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.

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

                            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.

                            Rappel ma question était :

                            Est ce que l'adressage mémoire actuel est capable

                            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.

                            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.

                            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 . É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 . Évalué à  3 .

                                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.

                                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 . É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 . Évalué à  3 .

                                    Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events

                                    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.

                                    on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent

                                    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.

                                    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.

                                    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 . É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 . Évalué à  3 .

                                        Et je ne suis pas le seul à le dire

                                        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 . Évalué à  1 .

                                          Un mot est resté dans mon clavier.

                                          Donc tu ne devrais même pas avoir de les applications,

                                          Il fallait lire: "Donc tu ne devrais même pas avoir besoin de recompiler les applications."

                                        • [^] # Re: Fenêtre

                                          Posté par . É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 (page perso) . Évalué à  6 .

                                Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct

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

                                  Sous X, tout aurait été embarqué avec le driver au final, et tu perds toutes tes applications.

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

                                  • La carte graphique a loupé une marche lors d'un context-switch (par exemple passage en plein écran avec d'autres paramètres d'accélération) et attend toujours une info qu'elle ne recevra jamais. En attendant elle est locké en exclusif par une appli et si on tue l'appli il faut aussi refaire le switch de contexte en sens inverse avant de pouvoir repasser en mode graphique. Généralement quand un switch de contexte est demandé sous Windows Vista ou 7, on se prend un message de type "Le mode de couleur des désormais windows 7 de base". ce qui se traduit par "Il y a une appli qui a demandé un type de format de pixels, ou d'accélération que je ne peut pas lui fournir dans le mode graphique actuel. Donc je range mes affaires et je lui passe la main." Si la carte part en vrille à ce moment là, c'est quasiment écran bleu assuré. Windows 7 va tenter de refaire le coup du passage par un mode non accéléré et reprise, mais si la carte est en attente d'infos de contexte ça a peut de chance de marcher. Sous linux c'est l'équivalent de tenter de passer sous la console, tuer l'appli qui casse les pieds et repasser en X en priant pour que l'affichage fonctionne. Des fois ça marche, souvent ça marche pas. La carte est mal initialisé, et les modes graphiques sont inaccessibles.
                              • [^] # Re: Fenêtre

                                Posté par . Évalué à  5 .

                                Je ne réponds qu'à certains de tes points car ton post est un peu long:

                                Oui la XLib est une bouse. On est d'accord.

                                Oui.

                                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.

                                Qt5 devrait aussi supporter XCB.

                                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.

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

                                Mais même les applis codées en GTK ou en QT parfait sont à réécrire.

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

                                Mais Wayland ne permet rien que X11R6 ne puisse faire.

                                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 . É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 . Évalué à  2 .

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

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

                                    [débat sur les modif à faire sur les applications] soit il y a un soucis.

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

                                    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.

                                    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 . É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 . É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 . Évalué à  3 .

                                        Comme tu vois il n'y a à chaque fois qu'une seule copie.

                                        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 . É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 . É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 (page perso) . Évalué à  2 .

                                              Bon bah, je comprends de moins en moins l'intérêt de Wayland..

                                              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.

                                              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                  • [^] # Re: Fenêtre

                                    Posté par . É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 . Évalué à  1 .

                          Je pense en particulier à World of Warcraft lorsqu'on essaie de switcher sur une appli non OpenGL et de revenir sur l'application OpenGL.

                          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 . É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 (page perso) . Évalué à  6 .

                        Alors qu'il eut été si simple de faire X12 compatible X11 avec abandon des trucs inutiles

                        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.

                        Perdez votre temps à réinventer la roue, pendant ce temps vos concurents avancent....

                        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 (page perso) . É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 (page perso) . Évalué à  10 .

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

                        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 . Évalué à  4 .

                        Pour moi, Wayland est une connerie tout court. On réinvente la roue carré au lieu d'améliorer le pneu....

                        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.

                        Quid des applications qui plantent? On ne peut plus bouger la fenêtre......

                        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"

                        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?

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

                        o Quid du remote display qui meme s'il est possible N'EXISTE PAS et RESTE A DEVELOPPER.

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

                        o Quid de l'impact de travail ENORME reporté sur les développeurs d'application

                        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.

                        Tout ça me fait penser au projet Berlin......(http://sourceforge.net/projects/berlin/)
                        Quelle perte de temps!

                        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 . Évalué à  3 .

                          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"

                          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 . É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 . É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 . Évalué à  -1 .

                    Toutafé.

    • [^] # Re: Fenêtre

      Posté par . É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 (page perso) . É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 . É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 . Évalué à  2 .

        Moi j'ai déjà commandé du pop-corn.

        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 . É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 (page perso) . Évalué à  2 .

          Est-ce que Wayland est vraiment prévu pour pouvoir écrire des compositeurs facilement?

          Vu qu'il en existe déjà 3 ou 4, je dirais oui.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Gestionnaire de fenêtres

            Posté par (page perso) . É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 . É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 (page perso) . É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 . Évalué à  1 .

        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.

        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 . É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 . Évalué à  4 .

            Il y a truc que je dois pas comprendre. Tu dis:

            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.

            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 ?

            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.

            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 . É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 . Évalué à  4 . Dernière modification : le 21/02/12 à 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 . É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 . Évalué à  3 .

                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 ?

                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 . É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 . É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 . É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 (page perso) . Évalué à  1 .

      mais surtout, ça a l'air d'interdire toute possibilité de réaliser de nouveaux gestionnaires de fenêtres

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

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Gestionnaire de fenêtres

        Posté par (page perso) . É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 . Évalué à  5 .

      Ce n'est pas très clair : Wayland intègre son gestionnaire de fenêtres mais les fenêtres doivent elles-mêmes dessiner leurs décorations ?

      Oui, c'est le comportement par défaut.

      Ça semble un peu idiot,

      Non: aucune solution n'est idéale, c'est un compromis.
      L'idée ici c'est que le client soit responsable de l'affichage de toute la fenêtre afin d'être sûr que la fenêtre soit "parfaite" en permanence,
      ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?, mais c'est défendable.

      ça promet un beau bordel bien disparate,

      Bah pas beaucoup plus que si tu mélanges du GTK, Qt, EFL, pur X à l'heure actuel.
      La synchro se fera par du EWMH j'imagine.

      la résistance à Wayland promet d'être féroce.

      Il y a des raisons de ne pas aimer Wayland:
      -non portabilité actuelle sur les *BSD
      -un client "pur" Wayland en WAN utiliserait beaucoup trop de bande passante
      mais les décorations clientes, non, je ne pense pas que ce soit un gros problème une fois que les bugs de jeunesses seront résolus.

      • [^] # Re: Gestionnaire de fenêtres

        Posté par (page perso) . Évalué à  3 .

        -non portabilité actuelle sur les *BSD

        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)

      • [^] # Décorations gérées par l’application

        Posté par . Évalué à  7 .

        ça a des conséquences:comment iconifier la fenetre si le client ne répond pas?

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

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Gestionnaire de fenêtres

      Posté par (page perso) . Évalué à  -1 .

      Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus, la résistance à Wayland promet d'être féroce.

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

        Moi qui croyait que dans le libre, contrairement à beaucoup de "proprio" on était capable de casser des choses

        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 (page perso) . Évalué à  5 .

          Il me semble ici que bon nombre ont oublié le vieux dicton "If it works DONT't fix it"

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

          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.

          Pourquoi "justement non" ? Les deux approches sont loin d'être incompatibles.

          s'il veut s'imposer il doit convaincre

          Oué mais faut aussi lire ce qui est écris, entre autre que ça peut embarquer un X par exemple.

          J'aimerai aussi savoir comment se comportera une appli sous wayland en mode tilling, ça promet d'être assez laid

          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 . Évalué à  0 .

            entre autre que ça peut embarquer un X par exemple.

            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.

            Quel est le problème ? Car "laid" ça ne veut rien dire, ni explique le problème qu'il pourrait y avoir.

            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 . Évalué à  8 .

        Mais c'est vrai ça, refusons toute évolution.

        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 (page perso) . Évalué à  2 .

          Si des trucs [...] deviennent impossible sous Wayland

          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 . Évalué à  3 .

            Où est-ce indiqué que ce ne sera pas possible ?

            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 . É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 (page perso) . É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:

                • Va sur un terminal texte (Ctrl-Alt-F2)
                • export DISPLAY=:0 (ou la valeur qui marche bien)
                • xterm (ou n'importe quel autre client X)

                Un WM n'a pas d'API pour lancer une application.

              • [^] # Re: Gestionnaire de fenêtres

                Posté par . Évalué à  2 .

                Ca ne changerait donc pas vraiment sous wayland.

                Hum si: la gestion des fenêtres se fait par le processus compositeur (Weston) sur Wayland.
                Sur X la gestion des fenêtres se fait par un processus séparé.

                Et par défaut les 2 ne font pas tout a la même chose car sur Wayland par défaut c'est le client qui dessine ses décorations de fenêtres.

            • [^] # Re: Gestionnaire de fenêtres

              Posté par . É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 . É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 . É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 . É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 . É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 . É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 :

              Archi 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 . É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 15 ans !

  • # Mauvaise foi

    Posté par (page perso) . É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 . É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 (page perso) . É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 . É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.

          Personne n'a mis de couteau sous la gorge de personne, d'une part.

          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.

          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 ?

          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 (page perso) . Évalué à  2 .

            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.

            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

            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.

            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 . Évalué à  1 .

              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.

              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 (page perso) . É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 (page perso) . É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 . Évalué à  3 .

            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.

            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 :

            "maybe try to make remote wayland actually happen, to see if there
            is something in the protocol/architecute that makes it harder than it
            should be"

            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 . Évalué à  3 .

              Les toolkits modernes (Qt, gtk, fltk, ...) se contentent d'écrire dans un buffer et de le transmettre à X.

              Hum, ce qu'il dit me parait être un grand raccourci: regardes les GlyphSet d'XRender, X permet au toolkit d'envoyer du texte en distant de manière assez efficace (une fois que tu as transmis une glyphe tu peux la réutiliser..) et une recherche Qt GlyphSet m'a donné quelques résultats: donc apparemment ils utilisent ce mécanisme).

              On a donc un pixmap non compressé qui est transféré au serveur X

              Pour le texte regarde plus haut, pour le fond effectivement envoyer les pixmap non compressé c'est pas terrible, mais c'est pour ça que NX compresse les pixmap il me semble(*), avec Wayland un buffer contiendrait à la fois le fond et le texte, donc si on essayait de compresser le buffer ce serait bien pire!

              Pour le cas local, je ne vois pas pourquoi ce serait impossible d'ajouter a X des références vers de la mémoire du GPU de la même manière que la "shared memory" lui a été ajouté..

              j'ai du mal à comprendre qu'on ne leur fasse pas plus confiance.

              Et bien si les justifications de Kristian étaient plus convaincantes ça aiderait!
              Quand LibreOffice a du code mort, ils le virent, ils ne changent pas totalement la conception..

              *: personne n'a dit qu'X était idéal pour le réseau, NeWS ou Berlin/Fresco étaient meilleurs coté réseau (paix à leurs âmes), mais vu que Wayland sera pire de ce coté là, ce n'est pas un argument pour Wayland, c'est un argument pour intégrer NX à X.

              • [^] # Re: Mauvaise foi

                Posté par (page perso) . Évalué à  4 .

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

                Tes propositions ont l'air tellement faciles que tout le monde se jettent dessus pour les implémenter.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Mauvaise foi

                Posté par (page perso) . Évalué à  4 .

                Quand LibreOffice a du code mort, ils le virent, ils ne changent pas totalement la conception..

                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 (page perso) . Évalué à  5 .

                  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.

                  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 (page perso) . Évalué à  2 .

                    Pourtant c'est l'avenir

                    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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . Évalué à  4 .

                    oui, il suffit de passer un paramettre comme argument.
                    --graphicssystem raster pour les apply kde et -graphicssystem raster pour 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 (page perso) . Évalué à  2 .

          les développeurs ont beau se tuer à répéter que X peut tourné en client Wayland

          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.

          • [^] # Re: Mauvaise foi

            Posté par . É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 (page perso) . Évalué à  5 .

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

              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.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Mauvaise foi

                Posté par . É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 . É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 . É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 . Évalué à  3 .

              parce que tu crois que chaque application inclut Xorg dans ses sources ?

              Je pense qu'il faut prendre 'application' au sens large (application ou toolkit) dans son post pour comprendre son point.

              On va dire 2 ans pour stabiliser Wayland, 2 ans pour que les toolkits l'exploitent bien: à l'horizon 2015 si tu dépends d'X pour les accès distant en WAN, il y aura de quoi être nerveux: l'histoire d'XCB l'a montré les toolkits essayent vraiment de supporter X "a minima".

      • [^] # Re: Mauvaise foi

        Posté par (page perso) . Évalué à  -4 .

        ssh -X, putty + X forwarding, et rlogin + export DISPLAY;

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

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

          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 . Évalué à  0 .

      Veux-tu m'épouser ?

      • [^] # Re: Mauvaise foi

        Posté par (page perso) . É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 . É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 . Évalué à  8 .

        Du genre tu lance Avast, itunes, chrome, Internet Explorer et Windows Media Player et t'as un environnement pas du tout intégré

        Essaye de lancer au hasard mplayer, firefox et libreoffice dans un environnement KDE…

        • [^] # Re: Mauvaise foi

          Posté par (page perso) . É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 (page perso) . É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 . É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 . É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 . Évalué à  1 .

              On peut aussi faire l'inverse : du Qt dans du GTK, mais on peut contourner plus ou moins.

              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 . Évalué à  3 .

      Ça me déprime un peu quand à l'état et l'existence de "la communauté du libre".

      Comme partout, il y a ceux qui blablatte et ceux qui contribuent…

    • [^] # Re: Mauvaise foi

      Posté par . É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 (page perso) . Évalué à  4 .

    Déja, le logo est grave moche. Alors que celui de X <3

    X11+MacOSX+Java

    * Ils vendront Usenet quand on aura fini de le remplir.

    • [^] # Re: [vendredi]

      Posté par (page perso) . É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 . Évalué à  2 .

        Me fait plus penser à 'La Marque Jaune' (Blake et Mortimer) :)

  • # Distributions Linux

    Posté par . É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 . É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 (page perso) . Évalué à  3 .

      La question que je me pose principalement pour Wayland, c'est quel intérêt?

      Parce que X ne marche pas, comme dis dans la dépêche

      X "marche" pour nous aujourd'hui, parce qu'on a construit un système d'affichage différent par dessus.

      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.

      vu que wayland est quand même présent en tant que serveur lorsque l'on souhaite en utiliser un autre que Weston

      Je ne vois pas d'où tu sors ça.

      ce qui sera déjà le cas pour les utilisateurs de KDE

      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.

      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.

      Je ne vois pas pourquoi. La transparence réseau peut se faire avec Spice par exemple.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Pourquoi?

      Posté par . Évalué à  2 .

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

      Augmenter les performances en local.
      Ce projet vient de l'embarqué: ça répond très bien à leurs besoins.

      vu que wayland est quand même présent en tant que serveur lorsque l'on souhaite en utiliser un autre que Weston

      Pff, tu pourrais faire un peu plus attention en lisant les descriptions..
      Wayland c'est une interface, une API (comme X), qui sera accessible a partir de librairie qu'utiliseront les clients et les serveurs (Weston et autres).
      Dans le système Wayland, il y aura un seul processus serveur qui fait compositeur et gestionnaire de fenêtre.

      ça risque peut-être de coincer lorsque l'on voudra utiliser une appli Qt/KDE hors de celui-ci

      En théorie oui, mais en pratique les devs Qt/KDE ont bossé pour que tu puisse utiliser une appli Qt/KDE sous GNOME sans que tu voie trop la différence (et vice versa), donc je pense qu'il y aura la même chose avec Wayland.

      Et si j'ai bien compris, wayland aura quand même besoin de X pour pas mal de cas donc il faudrait que les deux tournent simultanément.

      Pour la compatibilité et la transparence réseau "efficace" oui. Si tu n'utilise pas ça non.

      Je plains d'avance les distribs qui choisiront wayland pour essuyer les plâtre. (ubuntu?)

      Probablement Ubuntu oui: ils visent l'embarqué.

      Le seul avenir (lointain) que je peux voir pour Wayland serait un serveur d'abstraction pour plusieur environnement (X ou autre)

      Hum, ta boule de crystal est plantée, une fois que l'application a rendu son image dans un buffer c'est trop tard pour X! Enfin techniquement tu peux, tu as juste des performances réseau pourrie..

      • [^] # Re: Pourquoi?

        Posté par . É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 . É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 (page perso) . Évalué à  3 .

      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 ?

      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.

      Au final, dire que X est sous-utilisé ressemble fortement à la rage...

      C'est plus le changement d'archtictue qui a motivé Wayland à mon avis.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Pourquoi un tel désintérêt pour X ?

      Posté par . Évalué à  1 .

      mais il présente a posteriori un défaut d'architecture en séparant le compositeur et le serveur.

      Ce n'est pas le seul: il faudrait aussi ajouter un mode ou les clients puissent envoyer une référence vers un buffer dans la mémoire du GPU (et non plus seulement en mémoire principale partagée).

      Ce défaut ne peut-il être corrigé dans X ?

      Techniquement tout est possible, c'est au niveau de la main d'oeuvre/volonté que ça pèche.

      En quoi lancer Wayland résoudrait ce problème ?

      Pour X en rien, qui te dis que les développeurs de Wayland veulent résoudre les problèmes d'X??
      Ils veulent résoudre leur problème qui est de faire un système d'affichage efficace en local pour l'embarqué.

      Au final, dire que X est sous-utilisé ressemble fortement à la rage...

      Hein? Personne n'a dis ça, tu as lu de travers. L'article dit juste qu'X a plein de fonctionnalité non-utilisée car obsolète, ce qui complique la maintenance du serveur X.

      • [^] # Re: Pourquoi un tel désintérêt pour X ?

        Posté par . Évalué à  1 .

        Techniquement tout est possible, c'est au niveau de la main d'oeuvre/volonté que ça pèche.

        Lancer autre chose la dilue.

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

        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.

        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.

        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 . Évalué à  2 .

          Techniquement tout est possible, c'est au niveau de la main d’œuvre/volonté que ça pèche.

          Lancer autre chose la dilue.

          Sauf si la base (le protocole X et son implémentation X.org) est la raison originelle du manque de main d’œuvre.

          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.

          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 (page perso) . Évalué à  10 .

      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 ?

      À 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 . Évalué à  6 .

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

        Bien supporté par XRender (qui dans X). Et note que l'approche 'bitmap' peut utiliser bien moins de bande passante quand tu envoie d'un coté le texte (GlyphSet), de l'autres les "images de de fond" plutôt qu'un buffer qui contient une image de la fenetre (va essayer de compresser ça sans induire de retard!).

        Wayland est né de ce constat : X n'est plus adapté à l'utilisation qu'en ont les applications.

        Bof, c'est une justification foireuse: du même constat tu pourrait dire, faisons X12 qui vire tout le code mort/inutilisé (draw stippled line) mais qui garde XRender.
        Pour les toolkits, ça changerait même moins de chose!

        Je le répète la vrai justification de Wayland c'est d'avoir un rendu local plus performant pour l'embarqué.

        • [^] # Re: Pourquoi un tel désintérêt pour X ?

          Posté par . Évalué à  0 .

          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!

          Exactement mon constat de départ, mais je n'ai pas voulu le dire si directement.

          Je le répète la vrai justification de Wayland c'est d'avoir un rendu local plus performant pour l'embarqué.

          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 . Évalué à  7 .

          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.

          Faire cela reviendrait au même:

          • tu aurais besoin d'un serveur X11 complet quelque part (probablement un X11 rootless comme celui utilisé avec Wayland) pour les applications Motif et autres qui utilisent les fonctionnalités enlevées que "personne" n'utilise;
          • tu aurais besoin de mettre à jour tous les toolkits pour t'assurer qu'ils n'utilisent pas de fonctionnalité dépréciée.

          Bref, il faudrait toucher toutes les applications. Sauf qu'en plus:

          • Tu aurais toujours dans les pieds le vieux code et le vieux design prévus pour des choses qui n'existent plus (les fonctions que tu proposes de supprimer);
          • Tu aurais toujours les grosses misfeatures de X11;
          • Tu aurais de toute façon un serveur incompatible avec les autres;
          • Tu conserverais une partie du protocole X11 (mais pas tout) donc tu serais compatible avec l'existant (mais pas vraiment).

          Donc, autant partir d'une feuille blanche:

          • On peut faire supprimer les problèmes que l'on connaît avec le design de X11;
          • On peut faire quelque chose de plus adapté à l'utilisation actuelle qu'un design datant des années 70/80
          • On peut faire plus simple et plus accessibles pour attirer du sang neuf;
          • On ne casse au final pas plus la compatibilité qu'avec un protocole X "simplifié" comme énoncé plus haut.

          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 . Évalué à  1 .

            Ceci dit, si on avait baptisé Wayland X12 sans rien changer d'autre, peut-être n'y aurait-il pas eu matière à troll.

            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 . É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 (page perso) . Évalué à  4 .

              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.

              De l'embarqué et de 90% des utilisateurs desktop.

            • [^] # Re: Pourquoi un tel désintérêt pour X ?

              Posté par . É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 . Évalué à  2 .

        À l'époque où X a été conçu, [...] C'était une approche vectorielle du rendu qui correspondait aux besoins d'alors. [...] On est maintenant passé à une approche 'bitmap'.

        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 (page perso) . É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.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Pourquoi un tel désintérêt pour X ?

          Posté par . Évalué à  2 .

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

        • [^] # Re: Pourquoi un tel désintérêt pour X ?

          Posté par (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . É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é.

    Opera le fait depuis 10 ans.

  • # Comment X penalise Firefox / Linux

    Posté par (page perso) . Évalué à  10 . Dernière modification : le 21/02/12 à 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:

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

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

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

    4. 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 . É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 . É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 (page perso) . É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 . Évalué à  2 .

          Pour (1) imagine par exemple qu'on a rendu un paragraphe de texte avec Cairo dans un pixmap. Pour le compositing OpenGL, on va avoir besoin de lire ce pixmap depuis OpenGL, ce qui necessite de l'interpreter comme une texture.

          J'avais bien compris, mais ce que je ne comprends pas c'est pourquoi il y a une différence, pour moi les deux ce sont des buffers dans un GPU.

          Mais la bonne facon de resoudre ca est de continuer d'etendre OpenGL pour couvrir ces besoins (la 2D, c'est dur).

          Hum, dernièrement OpenGL a eu tendance à se simplifier en retirant les machins obsolètes qui ne correspondait plus au mode de fonctionnement des cartes, donc j'ai comme un doute sur l'extension OpenGL sur ce point là ait un grand avenir..

          Pour (3), Wayland a été décrit comme "violently asynchronous" par Kristian Høgsberg, alors je ne suis pas sûr que ça soit beaucoup plus simple..

          • [^] # Re: Comment X penalise Firefox / Linux

            Posté par (page perso) . Évalué à  5 .

            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.

            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 (page perso) . É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?

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Comment X penalise Firefox / Linux

        Posté par (page perso) . É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 . É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 . Évalué à  2 .

      Pour 1, 2 et 4, Wayland va régler le problème comment ?

  • # EGL et GLES2...

    Posté par (page perso) . Évalué à  8 .

    Dans l'article:

    ² : EGL et GLES2 sont une surcouche à OpenGL qui permettent d'accélérer le rendu.

    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 (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Notifications clavier

    Posté par . Évalué à  4 .

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

    Le mode secure keyboard de XTerm (ou d'autres émulateurs X de terminal) ne l'utilise pas ?

    • [^] # Re: Notifications clavier

      Posté par (page perso) . Évalué à  3 .

      Ainsi que les ssh-askpass, je crois ?

    • [^] # Re: Notifications clavier

      Posté par (page perso) . É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 (page perso) . Évalué à  2 .

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

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

        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.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Xembed

    Posté par (page perso) . É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

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.