X.Org est mort, vive Wayland !

Posté par  (site web personnel) . Édité par antistress, reno, Davy Defaud, patrick_g, Benoît, Yves Bourguignon, claudex, Sylvain Berfini, Marc Quinton, saltimbanque, Maxime, Benoît Sibaud et Damien Szczyt. Modéré par j. Licence CC By‑SA.
Étiquettes :
110
23
oct.
2012
Serveurs d’affichage

Eh oui les amis, ça y est, le jour tant attendu est arrivé : Wayland 1.0 est enfin là !

À ce jour, sur tous les ordinateurs de bureau et portables sous GNU/Linux, *BSD ou Solaris de la planète, l’interface graphique — que ce soit KDE, GNOME ou autre — est gérée par X Window System ou X11, dont X.Org est une implémentation (dérivée de XFree86).
Fait tout aussi notable : dans le monde mobile (Android) ou de l’embarqué où GNU/Linux est largement diffusé, X.Org est la plupart du temps absent.

X a été conçu au MIT en 1984 — il y a presque 30 ans ! —, sa version 11 datant, elle, de 1987, ce qui est très vieux pour du code gérant du matériel ayant subi de nombreuses (r)évolutions, avec pour corollaire que X.Org est devenu très difficile à maintenir.
De plus, avec l’avènement des compositeurs (permettant des effets de transparence, d’ombre portée, etc.), le fonctionnement de X.Org pour la gestion graphique ne semble plus optimal, car il constitue une étape supplémentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matériel.

Plusieurs tentatives pour remplacer X ont eu lieu : Y Window System, Fresco/Berlin… Aucune n’a rencontré le succès escompté.

En 2008, le Danois Kristian Høgsberg a décidé de créer un nouveau serveur d’affichage, à la fois plus moderne et plus simple à maintenir : le projet Wayland était né.

C’est donc finalement le W de Wayland qui succèdera à X !
Wayland

Pour se donner une petite idée de leurs différences, l’interface de programmation (API) de Wayland est environ 15 fois plus petite que celle de X…

Du côté utilisateur, on nous promet quelques bénéfices immédiats : une plus grande fluidité, un affichage sans cisaillements (tear‐free) quand la décoration est gérée par le client…
Notons enfin que Wayland n’est pas développé contre X.Org, mais avec le plein appui des développeurs de ce dernier qui voient bien l’intérêt de simplifier la maintenance. D’ailleurs, la Fondation X.Org vient de réviser ses statuts en incluant Wayland dans les logiciels qu’elle soutient.

Participants à la rédaction de cette dépêche : reno, antistress, Xavier Claude, Davy Defaud, Patrick_g, Benoît.

Sommaire

Bref rappel de l’architecture de Wayland

Wayland est construit au sommet des briques récemment ajoutées à la pile graphique de Linux : DRI 2 (accès direct, sans passer par le serveur X, au processeur graphique pour les applications), GEM (gestionnaire de mémoire graphique commun aux pilotes, utilisé par KMS) et KMS (gestion de la résolution et du nombre de couleurs par le noyau, au lieu du serveur graphique), tous deux utilisés par l’intermédiaire d’EGL.

Le fait que Wayland s’appuie sur KMS entraîne une première conséquence forte : seuls les pilotes libres sont actuellement à même de faire tourner Wayland !

Wayland est le nom du projet et du protocole d’affichage ; le projet contient plusieurs parties :

  • une bibliothèque implémentant ce protocole, elle est utilisé par les clients et par le serveur pour communiquer ;
  • un serveur d’affichage de référence : Weston ;
  • des exemples de clients.

Au début, il était prévu que Weston soit uniquement un prototype utilisé pour tester le protocole, mais il est vraisemblable que Weston sera utilisé en tant que tel dans l’embarqué.

Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.

Le fonctionnement de Wayland est le suivant : le serveur envoie les événements d’entrée (souris, clavier…) au client concerné. Le client traite l’événement et dessine localement dans un tampon puis envoie la référence du tampon modifié au serveur. Le serveur rassemble les différents tampons pour dessiner l’image finale qui sera affichée. Il est important que le serveur soit le compositeur et aussi le gestionnaire de fenêtres, pour déterminer quelle partie de chaque tampon il doit afficher et à qui envoyer les événements d’entrée.

Débats liés à Wayland

Si Wayland a été globalement bien accepté et souvent salué (par rapport à la fronde que soulève systemd, par exemple… +300 points au trollomètre), il a aussi rencontré des oppositions liées à plusieurs problèmes potentiels :

  • la perte de la compatibilité avec X ;
  • la perte de la transparence réseau pour des applications natives Wayland ;
  • l’homogénéité de l’affichage des fenêtres : avec Weston, il est prévu que ce soit les clients qui dessinent eux‐mêmes leurs décorations.

Ces sujets sont détaillés ci‐dessous.

Compatibilité avec X : XWayland

La compatibilité avec X a été un problème sur lequel les développeurs de Wayland ont travaillé très tôt, en fournissant la possibilité d’avoir un serveur X tournant au dessus de Wayland : c’est tout le but de XWayland (lire les explications détaillées en anglais ici).

Le bonus étant qu’une application écrite pour X tournant sur Wayland avec la couche de compatibilité devrait bénéficier de certaines caractéristiques de la nouvelle infrastructure et finalement mieux tourner que nativement sous X.

Transparence réseau

La transparence réseau pour les applications natives Wayland avait été laissée de côté dans un premier temps, mais ça a évolué.

Notons que l’utilisation du réseau par Wayland pourra être différente de celle de X11 :

  1. le nombre de RTT nécessaire : Kristian Høgsberg a dit qu’il avait fait très attention à avoir un protocole asynchrone minimisant les allers‐retours entre les clients et le serveur*. Ce point pourrait être donc meilleur qu’avec X. Pour rappel, NX avait été créé en grande partie pour améliorer cet aspect de X ;

  2. la bande passante utilisée : là, Wayland ne sera pas forcément bon par rapport à X, car ce sont uniquement des tampons qui sont envoyés, contrairement à X qui peut envoyer des tampons, mais aussi des commandes de dessin. À suivre, donc.

(*) : Cependant, il a précisé qu’il n’avait pas fait de tests en simulant une forte latence.

La décoration des fenêtres par les clients

En fait, la décoration des fenêtres par les clients est une des caractéristiques du serveur d’affichage Weston, pas du protocole Wayland : les développeurs de KDE ont d’ailleurs prévu que ce soit le serveur d’affichage qui affiche les décorations des fenêtres.

En dehors du fait de savoir qui affiche les décorations, notons qu’à l’heure actuelle la question de la cohérence graphique se pose déjà quand on fait tourner une application GNOME sous KDE et vice‐versa, donc ce n’est pas vraiment nouveau.

Différences avec X.Org

  • Comme nous l’avons écrit plus haut, Wayland permet juste de passer des images (des tampons) entre les clients et le serveur, il n’a donc pas de commandes de dessin comme X. En simplifiant, on peut considérer que Wayland c’est l’extension DRI 2 de X (que l’on doit d’ailleurs à un certain Kristian Høgsberg…).

  • Wayland peut fournir une notification pour prévenir quand l’image fournie a été affichée, c’est ce qui doit permettre de faire des animations fluides.

  • Avec Wayland, les applications ne savent pas où le serveur d’affichage met ses fenêtres : pas de coordonnées absolues dans le protocole.

  • X.Org est implémenté par tous les UNIX, mais Wayland utilise des briques logicielles uniquement disponibles sur Linux actuellement (principalement KMS, nous revenons sur ce point un peu plus loin).

Adaptation des bibliothèques graphiques existantes

  • Les bibliothèques graphiques Clutter, EFL (Enlightenment Foundation Libraries), GTK+, Qt et SDL (Simple DirectMedia Layer) sont en cours de portage sur Wayland, avec Clutter et EFL qui sont prêts ou quasiment, et GTK+ (le portage est presque complet avec la version 3.4.1), Qt (il faudra la future version 5) et SDL qui sont un peu derrière. Ces portages devraient s’accélérer à présent que l’API de Wayland est stabilisée.
    Quant aux applications elles‐mêmes, celles utilisant GTK+ devraient logiquement être prêtes avant celles utilisant Qt, pour la simple raison que GTK+ 3 est là depuis le 10 février 2011 quand Qt 5 n’est pas encore sorti. Théoriquement une application utilisant GTK+ 3 et n’appelant pas directement Xlib devrait être parée pour Wayland.

  • Mesa va rapidement connaître une légère mise à jour pour intégrer les dernières modifications du projet, passant en version 9.0.1.

  • VA-API dans sa dernière version (1.1.0) est censée également être au point pour Wayland.

Propos finaux

Il n’y a pas que Linux dans la vie !

Une question importante se pose dès lors que Wayland se veut le remplaçant de X.Org : pourra‐t‐il — comme X.Org — bénéficier aux autres Unices (BSD…) ?
La logique de Wayland ne s’y oppose pas, mais son implémentation actuelle le permet‐elle ?

Répondre à cette question implique de regarder si les briques sur lesquelles repose Wayland sont portables ou portées sur les autres systèmes accueillant actuellement X.Org.

KMS obligatoire

FreeBSD est relativement avancé en la matière, avec les portages de GEM et KMS en cours pour les puces Intel, qui devraient se concrétiser avec la version 10 du projet (lire ici, ici et là). KMS pour puces NVIDIA et AMD prendra un peu plus de temps (les pilotes libres correspondants utilisent TTM au lieu de GEM).

Ce travail bénéficie directement à DragonFly BSD où les développements semblent en revanche se concentrer sur les puces AMD pour le moment (lire ici).

Solaris aurait déjà porté KMS pour puces Intel (lire ici).

À noter qu’une réécriture partielle de KMS est prévue par Intel pour la prochaine version 3.7 de Linux, qui devra être transposée dans les portages sus-évoqués…

udev, une dépendance facultative

udev était requis par Weston pour gérer les périphériques envoyant des évènements par evdev (udev et evdev étant spécifiques à GNU/Linux).
Le portage de Wayland sur Android (en cours de réalisation par Pekka Paalanen) a eu pour effet de supprimer la dépendance obligatoire à udev. Ainsi, udev reste une dépendance de Weston sous GNU/Linux, mais pas sous Android.
Si Weston utilise toujours evdev, le remplacer par un système équivalent sur un noyau autre que Linux ne devrait pas être trop difficile semble‐t‐il.

L’architecture de Wayland elle‐même est indépendante de ces questions.

systemd ? Pas indispensable

L’architecture de Wayland utilise la variable d’environnement XDG_RUNTIME_DIR que systemd implémente actuellement sous GNU/Linux. systemd lui‐même ne sera pas requis si cette variable est implémentée d’une autre manière sur le système cible.

Tout ça c’est bien beau, mais ça arrive quand chez nous ?

Comme le souligne Kristian Høgsberg lui‐même, et contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.

Wayland va certainement continuer de mûrir un peu et être testé un peu plus sérieusement (c.‐à‐d. à plus grande échelle) avant d’être proposé par défaut dans nos distributions.

En attendant, des CD autonomes (live CDs) sont à votre disposition pour vous faire une idée sans altérer votre système (Rebecca Black Linux ou Fedora, par exemple).

Aller plus loin

  • # Version 3.7 de Linux ?

    Posté par  . Évalué à -10.

    "À noter qu’une réécriture partielle de KMS est prévue par Intel pour la prochaine version 3.7 de Linux, qui devra être transposée dans les portages sus-évoqués…"

    Je suppose qu'il s'agit du noyau en version 3.7 ?

  • # Gestionnaire de fenêtres

    Posté par  (site web personnel) . Évalué à 0.

    Si j'ai bien compris, pour mettre en œuvre un gestionnaire de fenêtres, il faut coder un serveur Wayland alternatif ? Ça n'a jamais été clair, cette histoire, mais si c'est le cas, c'est bon, Wayland c'est mort pour être adopté, le premiers à résister seront les développeurs, grands utilisateurs de gestionnaires de fenêtres alternatifs.

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

      Posté par  (site web personnel) . Évalué à 10.

      Non, c'est un un serveur d’affichage alternatif, à savoir un équivalent de weston… C'est déjà ce que veut faire le projet KDE. Gnome je sais pas.

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

        Posté par  . Évalué à 8.

        Enlightment aussi http://trac.enlightenment.org/e/wiki/Wayland

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

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

        Posté par  . Évalué à 5.

        Pourquoi tu réponds non?
        Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.

        Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!

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

          Posté par  (site web personnel) . Évalué à 2.

          S'ils appellent « serveur d'affichage » un gestionnaire de fenêtres, très bien. En revanche, s'il s'agit d'un serveur complet, dans le même sens que pour X.Org, ça va demander une quantité invraisemblable de travail dupliqué. KDE et Gnome pourront le faire, mais les autres (WindowMaker, awesome, XMonad, wmii, ratpoison…) non. Ça va faire un gros clivage entre les développeurs un peu pointus qui resteront sous X.Org et les autres.

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

            Posté par  (site web personnel) . Évalué à 10.

            Un serveur d'affichage c'est un "compositeur" sous Xorg:
            - Compiz
            - Kwin
            - Mutter

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

              Posté par  (site web personnel) . Évalué à 1.

              D'accord, donc c'est moins hénaurme comme travail que de recoder Wayland. Donc ça devrait le faire pour les gestionnaires de fenêtres alternatifs du coup.

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

                Posté par  . Évalué à 3.

                Et quelle est donc la partie compliquée du serveur Wayland compliquée à réimplémenter te dérange (il ne reste plus grand chose après le compositeur et le gestionnaire de fenêtre) ?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

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

                Posté par  (site web personnel) . Évalué à 10. Dernière modification le 23 octobre 2012 à 13:55.

                recoder Wayland

                Wayland est un protocole. Tu confonds peut être avec Weston qui est une implementation du compositeur.

                X.Org fait aussi beaucoup de chose au niveau graphique qui sont laissées au kernel dans le cas de Weston.

                De plus, rien n'empêche aux gestionnaires de fenêtres alternatifs d'utiliser des bibliothèques.
                (C'est déjà le cas: Une bibliothèque: http://qt.gitorious.org/qt/qtwayland et un exemple impressionnant de compositeur réalisé avec, http://www.youtube.com/watch?v=_FjuPn7MXMs )

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 6.

              Ce commentaire a été supprimé par l’équipe de modération.

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

            Posté par  . Évalué à 3.

            Relis l'article "Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.", et toi tu marque "s'il s'agit d'un serveur complet", pffff.
            La source: http://wayland.freedesktop.org/architecture.html

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

              Posté par  (site web personnel) . Évalué à -3.

              Ah donc en fait si, c'est bien un serveur complet. Duplication d'effort maximale, GNOME et KDE y arriveront peut-être, les autres resteront sous X.Org.

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

                Posté par  . Évalué à 2.

                C'est honteux, KDE et GNOME n'utilisent pas le même compositeur et WM, quelle duplication d'effort ! Il faudrait merger mutter et KWin ! Et vite.

                Sérieusement, ça serait bien ici que les gens arrêtent de crier au loup sans cesse. Tu vois le diable là ou tu veux bien le voir.

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

                Posté par  . Évalué à 1.

                Duplication d'effort maximale,

                Tu ne modifie que la partie du serveur qui gère les fenêtres: http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html

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

                Posté par  (site web personnel) . Évalué à 5.

                Par curiosité, j'ai tapé "awesome wm wayland" et je suis tombé sur ceci : http://comments.gmane.org/gmane.comp.window-managers.awesome/8581

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

                Posté par  (site web personnel) . Évalué à 6. Dernière modification le 23 octobre 2012 à 12:18.

                Quand tu regardes Mutter, GNOME a déjà un compositeur-gestionnaire de fenêtres, ils doivent l'adapter à Wayland à mon avis ça devrait pas être trop dur car basé sur Clutter qui est en phase avec Wayland (Intel des deux côtés).
                Pour KDE ça risque d'être plus compliqué :

                Our current planning is to make KWin our Wayland Compositor. […] it seems to me that extending KWin with Wayland support is the only possible solution right now. Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

                Cependant :

                the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

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

                Posté par  . Évalué à 5.

                http://lists.freedesktop.org/archives/wayland-devel/2012-October/005973.html

                Hop déjà un compositeur non KDE ni gnome de "presque" fonctionnel.

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

            Posté par  . Évalué à 2.

            sinon, tu pourrais prendre la peine de te renseigner avant d'affirmer n'importe quoi.

            Il s'agit pas d'un WM appelé serveur d'affichage, ni l'inverse, il s'agit d'un WM qui est un serveur d'affichage ainsi qu'un compositeur. Alors, oui, il faut recoder un serveur d'affichage pour recoder une WM. Mais, il y a plusieurs choses à prendre en compte :

            • il y a une lib
            • si la licence te convient, tu peux repartir de weston
            • Weston fait 21279 lignes alors même qu'il implémente beaucoup de backends (android, par exemple), ce qui est pour info grosso modo la taille d'awesome WM.

            Donc, il y a de fortes chances qu'on voit fleurir des compositeurs waylands adaptés, voire même des ports de wm existants pour X, pour ceux qui on une logique propre comme awesome.

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

              Posté par  (site web personnel) . Évalué à 4.

              C'est bon, je crois que je commence à comprendre. Ce ne sera pas aussi simple qu'avec X11 où le gestionnaire de fenêtres et un logiciel indépendant, mais ça n'impliquera pas de tout recoder, simplement de forker et de se faire chier à réintégrer les nouveautés.

              Mais franchement, ça ne se devine pas tout seul. Le schéma d'architecture est particulièrement déroutant, il indique clairement que Wayland fait tout, et on en déduit que pour changer la gestion des fenêtres, il faut coder un autre Wayland.

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

                Posté par  . Évalué à 3.

                il indique clairement que Wayland fait tout, et on en déduit que pour changer la gestion des fenêtres, il faut coder un autre Wayland.

                Mais bien sûr, et pour rajouter un format d'image à Gimp, il faut coder un autre Gimp.

                Quand bien même le ce serait le cas, on peut raisonnablement espérer que Wayland est suffisamment modulaire pour qu'on puisse modifier le comportement de sa gestion de fenêtres sans casser son lien avec la carte graphique, non?

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

            Posté par  . Évalué à 3.

            Le travail va effectivement etre plutot important pour tous les Window Manager qui n'ont pas de Composite Manager et qui n'utilise pas un toolkit supportant l'ecriture de composite manager. Peut-etre apparaitra-t'il des hacks dans Weston pour brancher leur logique, mais la tache n'est pas negligable pour eux.

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

      Posté par  . Évalué à 3.

      D'apres la FAQ de Wayland:

      How can I replace Wayland's Window Manager?

      The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.

      This may sound like a lot of work, but one of the key points about Wayland is that the boilerplate code to a Wayland compositor is comparable or less than the X boilerplate involved in becoming an X window manager and compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and reading input from evdev can be done in less than a thousand lines of code. The Wayland server side library provides the protocol implementation and makes it easy to put the pieces together.

      En gros oui, il faut coder un serveur Wayland alternatif, mais ca devrait etre assez simple. Deja c'est plutot simple en soit, et surtout il y a la bibliotheque Wayland cote serveur qui aide grandement.
      Donc j'imagine que KDE va implementer un KWin qui fait serveur Wayland, a utiliser a la place de Weston… Mais je serais interesse par des references a ce propos.

      Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

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

      Posté par  (site web personnel) . Évalué à 2.

      Si j'ai bien compris, pour mettre en œuvre un gestionnaire de fenêtres, il faut coder un serveur Wayland alternatif ? Ça n'a jamais été clair, cette histoire, mais si c'est le cas, c'est bon, Wayland c'est mort pour être adopté, le premiers à résister seront les développeurs, grands utilisateurs de gestionnaires de fenêtres alternatifs.

      Je dois dire que je suis bluffé. En lisant la dépêche je me suis douté que tu avais déjà du lancer un troll stérile, mais de compétitions, avec des threads interminables, avec des arguments invérifiés, douteux ou contradictoires, des rebondissements. J'avais déjà quelque idée de troll imaginable dans la tête.

      Et là, mais c'est grandiose ! Bon, en poussant un peu tu aurais pu faire croire que le fork du noyau linux serait nécessaire pour la prochaine version de GTK3, mais c'est déjà pas mal, je me délecte !

      Bravo l'artiste (ou pas).

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

      Posté par  (site web personnel) . Évalué à 2.

      Avec un peu de chance il vont nous pondre un truc scriptable assez facilement, et les gens pourront mettre en oeuvre ce genre de choses rapidement.

      Je ne suis pas très inquiet :)

  • # Nous n'avons pas les mêmes valeurs

    Posté par  (site web personnel) . Évalué à 7.

    En attendant, des CD autonomes (live CDs) sont à votre disposition pour vous faire une idée sans altérer votre système (Rebecca Black Linux par exemple).

    Rebecca Romijn ou Claudia Black, OK, mais Rebecca Black, non merci !

  • # Non, Xorg n'est pas (encore) mort...

    Posté par  . Évalué à -10.

    …Pour la simple raison que Wayland ne tourne que sur Linux.

    • [^] # Re: Non, Xorg n'est pas (encore) mort...

      Posté par  (site web personnel) . Évalué à 2.

      Tu as lu la dépêche?

      Ca y est, après systemd puis journald, voila les "explications" pourries arriver pour Wayland… Le prochain sera?

      • [^] # Re: Non, Xorg n'est pas (encore) mort...

        Posté par  . Évalué à 5. Dernière modification le 23 octobre 2012 à 11:39.

        Oui mon chou, par contre on dirait que tu m'as mal lu.

        Bon, je m'explique: Wayland n'est pas encore disponible sur d'autres plateformes, donc on a encore besoin de Xorg, donc Xorg n'est pas encore mort. Réaction au titre simplement, d'où le "(encore)" dans le mien.

        Pour ton allusion aux "commentaires pourris" de systemd, je n'ai jamais dit saymalwayland, du tout.

        Enfin, je dis ça, je dis rien…

        • [^] # Re: Non, Xorg n'est pas (encore) mort...

          Posté par  . Évalué à 2.

          Réaction au titre simplement

          ça a été très vite "débattu" dans la tribune de ré(d)action, où il était "juste" question de trouver/proposer un titre trollesque accrocheur.

        • [^] # Re: Non, Xorg n'est pas (encore) mort...

          Posté par  (site web personnel) . Évalué à 8. Dernière modification le 23 octobre 2012 à 12:25.

          Sinon on peut lire la dépêche jusqu’au bout :

          contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.

          Comme dirait Ken : X.Org est mort mais il ne le sait pas encore

      • [^] # Re: Non, Xorg n'est pas (encore) mort...

        Posté par  . Évalué à 9.

        Ca y est, après systemd puis journald, voila les "explications" pourries arriver pour Wayland… Le prochain sera?

        Ça à rien avoir, c'est même l'inverse : Wayland est un remplaçant simple à X.org qui est devenu un bloatware, en faisant la même chose (affichage-clavier-souris).
        Systemd est un bloatware qui remplace pas mal de chose simple.

        Après on peu discuter sur le plan technique, mais je vois peu de reproches à faire à Wayland sur le principe.

        En plus franchement, dire que les gens ont des explications "pourries" quand elles ne vont pas dans ton sens…

    • [^] # Re: Non, Xorg n'est pas (encore) mort...

      Posté par  . Évalué à 8.

      Faudra juste trouver des mainteneurs, comme pour init…

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Instant de fierté

    Posté par  . Évalué à 10.

    Snif… C'est moi qui ait créé l'article Wikipedia la pile graphique de Linux. Il a été largement amélioré par Antistress, merci à lui!
    Ca fait plaisir de voir qu'une de ses contributions sert à quelque chose :)
    Voilà, c'était mon petit instant de fierté, ça fait du bien :)

    Excellent article au demeurant!
    Merci aux auteurs!

    • [^] # Re: Instant de fierté

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 23 octobre 2012 à 11:07.

      Arf c'était toi ? Le monde est petit ! L'idée était bonne, j'ai saisi la balle au bond quand j'ai écrit un article similaire sur mon blogue :-)
      Et dimanche dernier j'ai fait un joli schéma explicatif

      • [^] # Re: Instant de fierté

        Posté par  . Évalué à 3.

        C'était à force de traîner sur Phoronix et de rien comprendre aux articles parce que chaque paragraphe utilisait au moins 10 éléments de la stack graphique :)

        Cool le schéma!! Ca marche bien mieux qu'un long chapitre! :)

        • [^] # Re: Instant de fierté

          Posté par  (site web personnel) . Évalué à 3.

          C'était à force de traîner sur Phoronix et de rien comprendre aux articles parce que chaque paragraphe utilisait au moins 10 éléments de la stack graphique :)

          pareil !

      • [^] # Re: Instant de fierté

        Posté par  . Évalué à 2.

        Et wikipedia ne t'es pas tombé dessus pour l' "auto-plagiat" ?,
        j'ai abandonné les contributions suite à ça …

        • [^] # Re: Instant de fierté

          Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 15:26.

          Quand c'est sous CC-BY-SA à la source, ça ne doit pas déranger Wikipédia…

          C'est logique en même temps, quand tu reprends un de tes propres textes sur Wikipédia :

          • si ton texte d'origine est sous une licence propriétaire, tu dois prouver que tu es bien son auteur pour avoir le droit de le relicencier sous CC-BY-SA pour Wikipédia ;
          • si ton texte d'origine est sous CC-BY-SA, il n'y a rien à prouver, qu'il soit de toi ou de quelqu'un d'autre il a le droit d'être copié sur Wikipédia et redistribué sous CC-BY-SA.

          • [^] # Re: Instant de fierté

            Posté par  . Évalué à -2.

            oui les contraintes de modification de licence du texte d'origine, ou de preuve d'auteur sont rédhibitoires aux contributions.

            Je n'ai pas à changer la licence du texte d'origine pour en offrir une copie et puis quoi encore !, ni à prouver quoi que ce soit… Lorsque l'on m'explique que wikipedia vends le contenu qu'on lui donne et que l'on doit lui céder tous nos droits, ce n'est plus vraiment dans l'esprit que je m'en faisait…

            • [^] # Re: Instant de fierté

              Posté par  (site web personnel) . Évalué à 7. Dernière modification le 23 octobre 2012 à 16:03.

              Je n'ai pas à changer la licence du texte d'origine pour en offrir une copie

              Si cette copie en question est sur Wikipédia, elle est sous CC-BY-SA, donc en pratique ça revient à changer le texte de licence, puisqu'il est alors disponible sous deux licence, une propriétaire sur ton site, et une libre sur Wikipédia, et que les gens peuvent donc choisir la licence qu'ils préfèrent respecter parmi ces deux-là.

              ni à prouver quoi que ce soit

              Si : que tu es bien l'auteur d'origine, puisque lui seul a le droit de relicencier son texte.

              Lorsque l'on m'explique que wikipedia vends le contenu qu'on lui donne

              Tu sors ça d'où ? Ils ont le droit de le faire, tout le monde a le droit de le faire en fait, et ça ne me choquerait pas, mais je n'ai jamais entendu parler de ça.

              et que l'on doit lui céder tous nos droits

              Nawak. Tu dois mettre tes textes sous licence CC-BY-SA, aucune cession intégrale ou exclusive là-dedans. Perso mes textes sont sous CC-BY-SA à la base, donc je n'ai pas ces problèmes.

              • [^] # Re: Instant de fierté

                Posté par  . Évalué à 1.

                Pour le changement de licence, ce n'est vrai que si la licence en question est strictement plus restrictive que la CC-BY-SA. Si le texte existe ailleurs en CC-BY, par exemple, alors les gens pourront en faire un dérivé sans conserver la licence. Et cet exemple parait un peu stupide parce que n'importe qui peut prendre un texte en CC-BY et le relicencier en CC-BY-SA, à priori, mais si jamais l'auteur donne le choix entre une CC-BY-SA et une licence payante qui permet de relicencier des textes dérivés avec une licence très restrictive, ça peut être plus problématique si Wikipédia demande effectivement de changer la licence du texte d'origine. Mais je doute que ça soit le cas, tant que l'auteur du texte prouve qu'il est d'accord avec la publication en CC-BY-SA.

                LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

            • [^] # Re: Instant de fierté

              Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 19:03.

              Lorsque l'on m'explique que wikipedia vends le contenu qu'on lui donne et que l'on doit lui céder tous nos droits, ce n'est plus vraiment dans l'esprit que je m'en faisait…

              Ou alors, tu n'as absolument rien compris au libre…
              Libre != anti-commercial.
              l’interdiction de vendre serait d'ailleurs non libre.

              Quelle idée du libre tu te faisais? Si c'est du non commercial, tu t'es trompé effectivement, et lourdement.

              ou de preuve d'auteur sont rédhibitoires aux contributions.

              Super pratique tes exigences.
              En pratique, du coup, c'est juste infaisable, car cette non exigence amènerait tellement de procès dans le cul que tu passerait du temps qu'à gérer les procès et pas faire du libre.

              Pourquoi rédhibitoire? C'est simple, ça coûte rien (ça sera libre à la fin dans tous les cas), donc rien de rédhibitoire, au contraire!

              Plus une mauvaise excuse pour ne pas contribuer plus qu'autre chose, pourquoi ne pas simplement pas dire "pas envie de faire du libre"? Ce n'est pas mal.

        • [^] # Re: Instant de fierté

          Posté par  (site web personnel) . Évalué à 6. Dernière modification le 23 octobre 2012 à 18:38.

          j'ai abandonné les contributions suite à ça …

          Ça ressemble quand même à une mauvaise excuse.

  • # wayland

    Posté par  . Évalué à -10.

    il fait quoi de mieux qu X.org ?

    • [^] # Re: wayland

      Posté par  (site web personnel) . Évalué à 10.

      A priori, il permet de lire les news sur Linuxfr en entier.

      • [^] # Re: wayland

        Posté par  . Évalué à -1.

        pas avec firefox ni chrome tu aurais du lire mieux les liens

    • [^] # Re: wayland

      Posté par  . Évalué à 9.

      En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :

      1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.

      2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.

      3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.

      • [^] # Re: wayland

        Posté par  (site web personnel) . Évalué à 3.

        Est-ce que le changement de carte vidéo à chaud (sur les portables qui ont deux cartes) est également facilité avec Wayland ? De mémoire, il me semble que c'était très compliqué à implémenter sous X.org.

        • [^] # Re: wayland

          Posté par  . Évalué à 3.

          Il m'a toujours semblé que c'était plus un problème de Linux et de toolkit que d'X.Org mais les gens aiment bien taper sur X, je ne sais pas pourquoi..
          Supposons qu'une application ait obtenu un tampon dans une carte et qu'on souhaite changer de carte --> problème!

        • [^] # Re: wayland

          Posté par  . Évalué à 0.

          Autrement dit : est-ce que cela pourra éventuellement résoudre le problème du système Optimus… qui n'est censé pas être implémentable avec X.org.

          • [^] # Re: wayland

            Posté par  (site web personnel) . Évalué à 8. Dernière modification le 23 octobre 2012 à 12:30.

            La bascule entre deux processeurs graphiques distincts au sein d'un même ordinateur portable, en fonction des priorités du moment (performance ou autonomie) sera rendu possible avec X.Org grâce aux derniers développements libres réalisés par Red Hat et Texas Instruments au sein de Linux 3.5 et RandR 1.4 (inclus dans X Server 1.13) + adaptation des pilotes correspondants.
            Mais il faut des pilotes libres (couple nouveau/intel par exemple)

      • [^] # Re: wayland

        Posté par  . Évalué à -7.

        le truc qui fait les effets ,dont je ne me sers jamais et que je trouve inutile marchait mal, donc on refait x c'est ça ?

    • [^] # Re: wayland

      Posté par  . Évalué à 2.

      ça a été débattu sur linuxfr cette année
      dans le journal "Pourquoi Wayland veut remplacer X"

  • # Pilotes graphiques libres

    Posté par  . Évalué à 5.

    Le fait que Wayland s’appuie sur KMS entraîne une première conséquence forte : seuls les pilotes libres sont actuellement à même de faire tourner Wayland !

    Je suis étonné de ne pas avoir vu de commentaire à ce sujet.

    Combien sommes nous à avoir la chance de pouvoir utiliser les pilotes libres ? (A moins que ça n'ait déjà été fait récemment, ça peut mériter un sondage.)

    Est-ce que ça va condamner les propriétaires de matériel non pris en charge à jeter leur matos ? A rester sur de vieilles versions logicielles lorsque le support de Xorg sera abandonné ?

    J'imagine qu'on a du temps devant nous avant l'abandon de Xorg, mais je ne parierai pas que ça va s'arranger rapidement du côté des pilotes de carte graphique.

    • [^] # Re: Pilotes graphiques libres

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 12:35.

      Les pilotes privateurs çaÿlemal
      J'achète des IGP Intel depuis que j'utilise Linux parceque je ne suis pas maso (GMA 950, HD Graphics 4000).
      Sinon faut te plaindre à NVidia, pas aux développeurs Linux et co
      Heureusement il y a de gros progrès dans les cartons pour Nouveau (attends la dépêche à venir sur linux 3.7)

      Bonne idée, le sondage !

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 2.

        Sinon faut te plaindre à NVidia, pas aux développeurs Linux et co

        Je ne me plains pas, et je ne pointe le doigt sur personne, hein. D'autant que je suis parfaitement content (ou presque) de mon pilote libre. J'essaye juste de prendre en compte les conséquences de la nécessité d'utiliser des pilotes libres.

        Je doute d'ailleurs que les développeurs eux-même, qui sont des gens responsables, ne se posent pas ce genre de questions.

        Et il ne s'agit évidemment pas, comme j'ai pu le lire plus bas, de bloquer tout développement qui ne serait pas compatible avec les pilotes propriétaires, dont il faudrait évidemment se débarrasser.

        Bonne idée, le sondage !

        C'est fait.

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 6.

        J'achète des IGP Intel depuis que j'utilise Linux parceque je ne suis pas maso

        Et que tu n'as que peu de besoins en perf…

        • [^] # Re: Pilotes graphiques libres

          Posté par  (site web personnel) . Évalué à 0.

          Traduction en langage commun : parce que tu ne joues pas à des FPS récents. Parce que pour tout le reste, des cartes graphiques intégrées Intel, c'est parfait.

          • [^] # Re: Pilotes graphiques libres

            Posté par  (site web personnel) . Évalué à 10.

            Les cartes graphiques puissantes ne sont pas utilisées que pour le jeu.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

            • [^] # Re: Pilotes graphiques libres

              Posté par  (site web personnel) . Évalué à -8.

              Et pour quoi d'autre, au juste ? De façon détournée comme coprocesseur pour du calcul de montage 3D, à part ça je ne vois pas.

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 7.

                Il commence a y avoir pas mal de monde dans le domaine scientifique qui se servent du GPU pour faire des calculs.

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 6.

                Il existe d'autre logiciel, plus courant, utilisant CUDA™ ou Opencl™ comme darktable : http://www.darktable.org/2012/03/darktable-and-opencl/

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 8.

                Il y a pleins d'endroits ou une carte graphique puissante est utile en fait:

                • logiciels de modeling 3D comme blender
                • lecture de vidéos accélérée par le GPU
                • retouche d'image accélérée (GIMP bosse la dessus il me semble)
                • cryptanalyse

                Et de manière générale, les cartes devenant de plus en plus programmables, de plus en plus de domaines s'intéressent à l'accélération que peut leur procurer l'utilisation du GPU.

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 4.

                Pour lire des vidéos en HD via le GPU (c'est sympa pour la batterie, et ça chauffe beaucoup moins) ?
                Pour appliquer des filtres graphiques rapidement ?
                Pour faire de la 3D ?
                Pour faire tourner des moteurs physiques ?
                Pour faire des calculs qui passent mal sur un CPU ?
                Pour pouvoir utiliser Compiz (qui a des plugins utiles tels que Scale) ou Unity/Gnome Shell ?
                etc…

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Pilotes graphiques libres

                  Posté par  (site web personnel) . Évalué à 4.

                  Les points les plus courants marchent très bien sur CG Intel, à savoir :

                  Pour lire des vidéos en HD via le GPU (c'est sympa pour la batterie, et ça chauffe beaucoup moins) ?
                  Pour pouvoir utiliser Compiz (qui a des plugins utiles tels que Scale) ou Unity/Gnome Shell ?

              • [^] # Re: Pilotes graphiques libres

                Posté par  (site web personnel) . Évalué à 5.

                Un exemple, avec utilisation puissance 3D pour de la 3D: j'ai un collègue qui travaille sur une plateforme d'avatars avec des rendus réalistes temps réel, et il apprécie grandement la puissance des GPU. D'autres collègues travaillent dans une CAVE avec 7 surfaces de projections, bi-stéréo relative… pareil, ça bouffe du calcul pour du rendu 3D.

                Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

          • [^] # Re: Pilotes graphiques libres

            Posté par  . Évalué à 7.

            Je pousse à bout une quadro 6000 au boulot (un monstre avec 6 Go de ram !!) et je ne bosse pas dans le jeu vidéo, et je suis bien content de pouvoir bosser sous linux (et mes clients aussi !)

            Donc non, intel n'est pas parfait du tout pour tout ce qui n'est pas des FPS récents.

            • [^] # Re: Pilotes graphiques libres

              Posté par  . Évalué à 2.

              Je pousse à bout une quadro 6000 au boulot (un monstre avec 6 Go de ram !!) et je ne bosse pas dans le jeu vidéo

              mais tu ne nous dis pas dans quel domaine tu bosses…

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 7.

                Je pousse à bout une quadro 6000 au boulot (un monstre avec 6 Go de ram !!) et je ne bosse pas dans le jeu vidéo

                mais tu ne nous dis pas dans quel domaine tu bosses…

                Et ça changerait quoi? Tu doutes que Linux puisse servir à autre chose que Compiz et Xonotic?

                • Sinon pour info y a une grosse brute de logiciel CAO qui s'appelle Catiaw qui est utilisée sous Linux
                • L'animation 3D Pro: MayaW, Houdiniw) etc…
                • En libre, l'incontournable Blender 3D
                • Et puis tout un pan de la recherche qui peut avoir besoin de puissance graphique pour ses simulations.

                Donc, ton Xmonad qui gère ses 50 rxvt transparents illisbles dans lesquels tu suis les logs de ton server Apache qui propulse du Rails n'est pas représentatif de l'utilisation principal d'un ordi sous Linux.

                Heureusement que nVIDIA a très tôt supporté Linux et le marché pro est-ce qui a amené ce support.

                ps: bien que je te tutoie, je ne m'adresse pas directement à toi, c'est juste qu'il est fréquent de voir des linuxiens réduire l'intérêt du support accélèré de nos chères GPU.

                • [^] # Re: Pilotes graphiques libres

                  Posté par  (site web personnel) . Évalué à 3.

                  Sinon pour info y a une grosse brute de logiciel CAO qui s'appelle Catia qui est utilisée sous Linux

                  C'est nouveau, que ce soit disponible pour GNU/Linux, non ?

                • [^] # Re: Pilotes graphiques libres

                  Posté par  . Évalué à 4.

                  Et ça changerait quoi? Tu doutes que Linux puisse servir à autre chose que Compiz et Xonotic?

                  Ah non, moi pas du tout, je suis plutôt d'accord. Simplement la question était de savoir quels étaient les usages autre que ceux-là qui nécessitaient du GPU, etc, je vais pas reformuler. Et tu réponds un peu à côté en disant qu'il y en a… mais sans expliciter.

                  Après, où tu travailles, toi, personnellement, c'est pas mon problème, c'est sûr.

                  bien que je te tutoie, je ne m'adresse pas directement à toi, c'est juste qu'il est fréquent de voir des linuxiens réduire l'intérêt du support accélèré de nos chères GPU.

                  D'accord, d'accord.

                  • [^] # Re: Pilotes graphiques libres

                    Posté par  . Évalué à 6.

                    Rendu d'objets 3D très gros et très complexes (j'ai des vbo de 1 Go par coupe environ…) et simulation (du cuda sur de très gros volumes de données)
                    En fait, s'ils faisaient des cartes avec plus de 6 Go de ram, je suis sur que nos clients les achèteraient et augmenterait la taille de leurs modèles en conséquence. Parce que pour l'instant, pour les algos qui s'y prêtent, c'est juste incomparable en terme de performance avec les versions cpu.

                    Et pour te dire, on pousse tellement les cartes à bout, qu'on en arrive même à certifier des gammes de cartes avec des versions de pilotes et récement j'ai même du blacklister une version de bios buggué d'une carte !

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 2.

                le trading peut etre ?

          • [^] # Re: Pilotes graphiques libres

            Posté par  (site web personnel) . Évalué à 2.

            Bon, sous la pression populaire, j'amende mon affirmation. Pour les usages courants, hors des FPS récents, une CG intégrée Intel est parfait.

            • [^] # Re: Pilotes graphiques libres

              Posté par  . Évalué à 3.

              Là je suis d'accord :)
              D'ailleurs, je suis de l'avis de pas plusieurs personnes qui ont posté ici, si je pouvais avoir les mêmes performances avec un pilote libre, je n'hésiterais pas un instant, même à fonctionnalités moindres.
              Du coup, quand dans la pratique, c'est plutôt moins de performances mais plus d'intégration avec X, je comprends que les personnes qui n'ont pas besoin de grosses performances (qui représentent, à la louche, 99,99% des non joueurs de jeux récents), soient très contentes de leurs pilotes libres.

              • [^] # Re: Pilotes graphiques libres

                Posté par  . Évalué à 1.

                Et les non joueurs, ça représente combien de % de la population ?

                Non, parce que même moi qui me considère pas comme un gros joueur, j’apprécie une LAN de temps en temps entre collègue un vendredi soir…

                • [^] # Re: Pilotes graphiques libres

                  Posté par  (site web personnel) . Évalué à 6.

                  C'est pas un soucis : Quake 3 (et sa flopée de dérivés libres) tourne très bien sur à peu près n'importe quoi… et de toute façon tout le monde sait que aucun bon jeu n'est sorti depuis 2004 ! ;-)

                • [^] # Re: Pilotes graphiques libres

                  Posté par  (site web personnel) . Évalué à 6.

                  Et les non joueurs, ça représente combien de % de la population ?

                  Beaucoup, dès qu'on sort de l'effet de communauté, qui fait que les gens que tu connais te ressemblent assez. Parmi mes parents, mes sœurs, mes amis non geeks : zéro joueur. Après ce n'est pas forcément représentatif non plus, mais les joueurs ne sont qu'une communauté particulière.

                  • [^] # Re: Pilotes graphiques libres

                    Posté par  . Évalué à 2.

                    Beaucoup je suis d’accord, j’étais longtemps un non-joueur entouré de non-joueurs d’ailleurs, mais 99.99% ça me surprendrait énormément, c’est ce que je voulais dire.

    • [^] # Re: Pilotes graphiques libres

      Posté par  . Évalué à 10.

      J'utilise les pilotes libre avec Intel et AMD et ça marche bien, je n'ai pas trop à me plaindre.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Pilotes graphiques libres

      Posté par  (site web personnel) . Évalué à 6.

      Oui, ça m'a titillé aussi.

      Je suis le premier à vouloir des pilotes libres, mais je veux aussi que ça marche. Et, même si cela date maintenant un peu, mes derniers démêles avec les pilotes libres pour l'accélération 3D m'ont laissé de très mauvais souvenirs. En clair, mes jeux marchaient très mal ou pas du tout, tandis que je n'ai jamais eu de problème avec les pilotes propriétaires nvidia.

      Je suis prêt à accepter qu'un pilote libre marche (un peu) moins bien et (un peu) moins vite qu'un pilote propriétaire, mais pas qu'il ne marche pas du tout. Donc, si KMS ne permet pas de faire tourner ma carte correctement en 3D, je risque de m'accrocher à X longtemps.

      Et, pendant que j'y suis, la compatibilité de wayland avec X permet-elle de faire tourner des applications existantes sans les recompiler ? En somme, est-ce que les jeux 3D que j'ai achetés peuvent espérer fonctionner directement ou dois-je espérer un éventuel patch de leur auteur pour les faire tourner sous Wayland ?

      Les devs voient certainement plein d'avantage à passer sous Wayland, mais il faudrait au minimum qu'il n'y ait pas de désavantage pour l'utilisateur final. Si l'unique motivation qui me poussait à utiliser un OS était la pureté du design, je serais sous Hurd aujourd'hui…

      • [^] # Re: Pilotes graphiques libres

        Posté par  (site web personnel) . Évalué à 3.

        Il faut bien comprendre que les avantages pour les développeurs, à savoir une implémentation simple, claire et facilement maintenable, aura des répercussions sur l'utilisateur qui profitera potentiellement d'un produit moins bogué et plus performant. Ce sont les deux facettes d'une même médaille.
        Le but de la couche compatibilité X et de pouvoir continuer à utiliser les applis existantes telles que. Après faudra voir si ça marche…

        • [^] # Re: Pilotes graphiques libres

          Posté par  (site web personnel) . Évalué à 5.

          Moins bogué, certes, plus performant, c'est à voir. J'ai pas dis que ça va aller plus vite. La transparence réseau pourrait ne pas être plus performante…

          Si on regarde ces dernières années, on nous dis à chaque fois que ça va aller plus vite, que la dernière version est mieux et tout et tout mais on doit au final changer de PC car celui-ci se met à traîner ;-)

          • [^] # Re: Pilotes graphiques libres

            Posté par  . Évalué à 4.

            Moins bogué, certes, plus performant, c'est à voir. J'ai pas dis que ça va aller plus vite. La transparence réseau pourrait ne pas être plus performante…

            C'est à voir en effet, mais j'aurais tendance à être optimiste sur cet aspect. Le protocole X n'est plus utilisé de la même manière qu'à ses origines.
            Les toolkits modernes manipulent principalement des buffers.
            Wayland fonctionne sur ce principe et évite certaines contorsions liées à X.
            Donc en pratique, on peut espérer un gain en performances, y compris du côté réseau.

          • [^] # Re: Pilotes graphiques libres

            Posté par  . Évalué à 1.

            Moins bogué, certes, plus performant, c'est à voir.

            J'ai plutôt tendance à penser le contraire moi.
            Plus performant (architecture proche de DRI pour le rendu 2D, alors que c'était réservé à la 3D avant) mais plus bogué aussi, du moins dans les premiers temps.

            Et je vois déjà les râleurs se plaindre des premières versions qui crashent avec de superbes trolls de compétition élevés au grain non ogm et au mille feuille au kirsh !

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 4.

        pour info, avec le pilote libre radeon, je peux jouer à Xonotic, et presque jouer à 0ad ou flightgear (ça rame beaucoup, 10/15 FPS). Avec le pilote non-libre ça marcherais nickel.

        C'est moins bon, mais ça s'améliore d'année en année.

      • [^] # Re: Pilotes graphiques libres

        Posté par  (site web personnel) . Évalué à -3.

        Très convainquant comme commentaire. Comme certains ne sont pas regardant à l'achat de leur matos, il faudrait arrêter toutes évolutions non validées par Nvidia (ou pas en fait).

        • [^] # Re: Pilotes graphiques libres

          Posté par  (site web personnel) . Évalué à 10.

          Ha mais c'est tout le contraire. Je suis très très regardant sur le matos, j'achète justement celui qui me donnera ce que je recherche. Et pour l'instant, l'unique fabriquant qui me permette vraiment de jouer sous Linux, c'est nvidia. J'ai essayé 2 fois de migrer sous ATI (pilotes libres, toussa), et 2 fois je suis revenu sous nvidia.

          Si une alternative libre à une solution propriétaire existe, je suis le premier à l'utiliser. Mais il se trouve que les jeux sont l'unique raison pour laquelle je conserve une partition windows. Ce qui veut dire (pour le moment) que la seule solution qui me permette de ne pas booter Windows trop souvent passe par nvidia. Et par ses pilotes propriétaires.

          Pour la première fois peut-être, une floppée de très bon jeux est prévue prochainement pour Linux:

          • Project Eternity
          • Planetary annihilation
          • Wasteland 2
          • Double Fine

          Il y a aussi Chris Roberts qui prévoit de revenir au Space Opéra, et qui hésiterait à porter son jeu sous Linux.

          Alors, quel intérêt pour moi d'installer Wayland et des pilotes libres si je ne peut pas y jouer ? Si je dois installer un OS uniquement pour surfer sur internet et relever mes mails, pour la pureté et la gloire du logiciel libre, autant passer à BSD.

          Donc, le jour où j'aurais la garantie que Wayland et les pilotes libres ne se mettront pas en travers de ma route, entre moi et mes jeux, j'envisagerait de l'installer. Je serais même prêt à acheter une nouvelle carte graphique juste pour ça s'il le faut. Mais pas avant.

        • [^] # Re: Pilotes graphiques libres

          Posté par  . Évalué à 10. Dernière modification le 23 octobre 2012 à 18:41.

          Tu connais beaucoup toi de cartes avec un pilote libre qui aient les mêmes performances sous Linux qu’une Geforce avec les pilotes proprio ?

          Si c’est le cas, ça m’intéresse beaucoup.

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 3.

        J'ai quelques pistes de réflexion à ce sujet :

        D'une part, nVidia aurait des plans pour Wayland… j'ai bien dit "aurait"
        Lien vers l'article de Phoronix à ce sujet…

        Ensuite depuis que Linus les a un peu secoués (:p) ils ont l'air de mettre un peu plus de bonne volonté dans leur support des plate-formes libres. Si une bonne partie des distributions majeures affiche une volonté ferme de passer à Wayland, alors il y a des chances qu'ils s'y mettent. Ils détiennent quand même un quasi-monopole du jeu sur Linux, et qui risque de s'accroitre encore avec l'arrivée de Steam et l'élargissement du marché du jeu sur Linux, ce qui commence donc à représenter un marché suffisamment important pour qu'ils ne s'en séparent pas bêtement. D'autant qu'AMD est bien plus impliqué qu'eux dans le développement des drivers ATI libres.

        Alors deux solutions, ou nVidia sort un blob compatible Wayland et tout se passe comme à l'heure actuelle, soit ils quittent le bateau (ou du moins, ils n'embarquent pas) et il y a des chances pour que les Linuxiens se rabattent en masse sur les cartes de la marque rouge pétant (Intel ne constitue pas encore un véritable concurrent pour les joueurs dans la mesure où la puissance développée par leurs chipset est encore bien trop faible comparée à la GeForce la moins chère du marché). La question qui me vient immédiatement est : si ATI rencontre un franc succès, investiront-ils plus dans leurs drivers libre ?

        • [^] # Re: Pilotes graphiques libres

          Posté par  . Évalué à 9.

          D'autant qu'AMD est bien plus impliqué qu'eux dans le développement des drivers ATI libres.

          Remarque, si nVidia était plus impliqué qu'AMD dans le développement des drivers ATI libres, ce serait inquiétant.

          (pardon)

        • [^] # Re: Pilotes graphiques libres

          Posté par  . Évalué à 8.

          … ou nVidia sort un blob compatible Wayland et tout se passe comme à l'heure actuelle

          Je les vois bien faire ça, nVidia a montré depuis des années sa motivation pour sortir un driver de qualité pour ses chipsets sous linux. Je n'ai pas dit parfait, je n'ai pas dit idéal, je n'ai pas dit en adéquation totale avec le développement du noyau et de ses fonctionnalités (suspend…..), mais j'ai dit de qualité. Ça n'est pas un hasard si pour le jeu sous Linux encore aujourd'hui c'est chipset nVidia + driver proprio qu'il faut pour tenir la route. Bref, ils ont également montré leur volonté à ne pas ouvrir leur blob. Je ne vois pas en quoi Wayland changerait quoi que ce soit à leur "stratégie"…

          • [^] # Re: Pilotes graphiques libres

            Posté par  (site web personnel) . Évalué à 2.

            nVidia a montré depuis des années sa motivation pour sortir un driver de qualité pour ses chipsets sous linux.

            Pour préciser, nvidia sort un driver pour X. Celui-ci est porté sous diverses plate-formes (a ma connaissance, Linux, Solaris, FreeBSD). Je pense qu’économiquement pour Nvidia, Solaris reste encore le marché le plus juteux (On pense aux fermes de serveurs pour le rendu 3D des films …).

        • [^] # Re: Pilotes graphiques libres

          Posté par  . Évalué à 3.

          Que KMS soit en EXPORT_GPL ne me semble pas un gros problème, de toute façon nvidia n'a, à ma connaissance, jamais eu l'intention d’abandonner son architecture unifiée au profit de DRI/KMS.

          Personnellement j'utilise nouveau au quotidien et je ne démarre avec les pilotes nVidia que pour X-Plane (pas été cité celui-là comme "gros truc qui demande des performances 3D bien au delà de ce qu'offre les pilotes libres aujourd'hui" ?).

          Si Wayland devient majoritaire nVidia portera ses pilotes dessus, j'ai pas trop de soucis à ce sujet, ce sera une bonne occasion de faire évoluer le module noyau en y intégrant la gestion des résolutions et pourquoi pas un framebuffer accéléré, un "KMS équivalent", car aujourd'hui il faut bien avouer qu'à part en 3D les pilotes nVidia sont très en retard sur nouveau et le standard du monde libre en général, pas de transition sans clignotement entre X et les consoles, pas de framebuffer accéléré (et même pas de framebuffer du tout, obligé d'utiliser un framebuffer vesa), moins stables que les pilotes nouveau…

          • [^] # Re: Pilotes graphiques libres

            Posté par  . Évalué à 2.

            Je suis d'accord pôur ce qui est du retard sur les standards et les protocoles de X (XRandR seulement supporté par les dernières versions… ça m'a bien fait chier perso)
            Par contre, pour le stabilité (dans X en général), je n'ai jamais eu de gros soucis avec, pourtant je suis souvent très à jour au niveau des pilotes (y compris les version beta).
            Il y a eu quelques versions problématiques, mais en règle générale, on pouvait toujours revenir à une ancienne version.

            • [^] # Re: Pilotes graphiques libres

              Posté par  . Évalué à 2.

              Ben moi mes soucis ont commencés avec la fameuse "version problématique", mais ont continués après.

              Bon c'est assez rare mais quand-même il arrive que l'écran devienne gris~clignotant et que la seule solution soit un reboot "à l'aveugle".

          • [^] # Re: Pilotes graphiques libres

            Posté par  (site web personnel) . Évalué à 4.

            jamais eu l'intention d’abandonner son architecture unifiée au profit de DRI/KMS.

            Pourtant c'est cette partie qui est vraiment importante. La fin du matériel géré directement par X c'est quand même un sacré progrès dans la propritude du truc.

            • [^] # Re: Pilotes graphiques libres

              Posté par  . Évalué à 3.

              Oui mais ça ne passe pas forcement par GEM/DRI2/KMS

              Rien n'a empêché jusqu'à présent nVidia de mettre la gestion de la mémoire, de la résolution, de l'accélération dans son module noyau, c'est peut-être même déjà le cas (manquerait qu'un framebuffer pour égaler nouveau ?) et si ils ne l'ont pas fait c’est, je pense, parce-qu'ils n'ont as trouvé opportun de "tout casser" du pilote pour X11 alors qu'il va falloir de toute façon refaire le travail pour Wayland.

    • [^] # Re: Pilotes graphiques libres

      Posté par  . Évalué à 3. Dernière modification le 23 octobre 2012 à 13:45.

      Combien sommes nous à avoir la chance de pouvoir utiliser les pilotes libres ? (A moins que ça n'ait déjà été fait récemment, ça peut mériter un sondage.)

      Je ne sais pas combien de personne les utilisent, mais c'est mon cas. Et même pour moi qui suis un libriste intégriste qui n'a pas flash, je le fais par confort.

      J'ai une carte Nvidia, et avec le pilote propriétaire, j'ai des ligne blanches horizontales qui défilent sur mon écran. Donc déjà, le pilote libre Nouveau est de meilleure qualité que le pilote propriétaire Nvidia Linux et Windows.

      En plus, j'ai pas à galérer à installer/mettre à jour les pilotes propriétaire sur ma Fedora (sois avec le binaire nvidia, soit avec les paquets nvidia dans le dépôt rpmfusion propriétaire qui sont en retard à chaque mise à jour).

      Les pilotes libre pour moi, c'est que des avantages. (En plus, Red Eclipse et Urban Terror tournent parfaitement avec les pilotes libres)

      Knowing the syntax of Java does not make someone a software engineer.

      • [^] # Re: Pilotes graphiques libres

        Posté par  (site web personnel) . Évalué à 3.

        Oui, enfin il faut quand même dire que les sur certaines cartes les pilotes libres gèrent très mal la gestion de l'énergie => carte qui chauffe.

        Et puis certains jeux sont simplement injouables, comme cela a déjà été dit. Je crois que c'est un problème que l'on ne peut pas mettre sous le boisseau comme ça.

    • [^] # Re: Pilotes graphiques libres

      Posté par  . Évalué à 1.

      Après la claque à 300M$ que nVidia s'est mangé sur les pilotes non-libres pour les Chinois, je doute que le "on s'en fout, on va filer un blog binaire!" sur les pilotes Libres passe aussi bien qu'avant auprès des grands managers.

      Une petite poussette supplémentaire dans le dos d'nVidia pour qu'ils sautent dans le bain, ça ne peut pas faire de mal!

      Et quant à ATI, et bien quand ils en auront marre de lire que leurs cartes dédiées font à peine mieux que les Intel intégrées, ils n'auront qu'à bosser sur leurs pilotes Libres également!

      Je suis toujours partisan de la méthode forte avec les constructeurs récalcitrants. Attendez de voir un éditeur de grosse solution CAD qui demande une masse de machines très puissantes déclarer qu'il passe sous Wayland et ne fera donc de support que sur [insérer ici constructeur de carte coopératif], ça a toujours son petit effet…

    • [^] # Re: Pilotes graphiques libres

      Posté par  . Évalué à 10.

      En fait ce n'est pas tout à fait correct. KMS n'est pas strictement obligatoire pour Wayland, en fait d'après Kristian lui-même :

      According to Kristian closed drivers need 2 things:

      A way to set the graphics mode (like KMS, but it could also be a standalone library)
      A way to share video memory buffers (for example an EGLImage) between processes

      Donc théoriquement les drivers propriétaires peuvent utiliser Wayland sans forcément utiliser KMS/GEM si ils implémentent des mécanismes similaires pour partager les buffers entre les clients et un modesetting noyau.

    • [^] # Re: Pilotes graphiques libres

      Posté par  . Évalué à 9.

      Eh bien moi ça m'inquiète cette tendance Linux only que l'on retrouve partout.
      Exemple concret :

      L'autre jour j'installe FreeBSD, les mains dans les poches parce que "mon ordinateur a une carte graphique Intel, et le Intel saylibre saybien". Et bim, elle n'est pas supportée. La raison ? Le pilote est KMS only, et ça n'est pas encore présent sur FreeBSD. Le pilote AMD est en passe de devenir pareil et ses performances sont complètement à la ramasse (même sur Linux). Donc le seul moyen d'avoir de bons graphismes sur FreeBSD c'est d'acheter une carte Nvidia et de coller le pilote propriétaire.

      Sur le coup j'ai pas mal pesté car on marginalise encore plus les systèmes alternatifs à Linux qui vont devoir devenir des Linux-like pour faire du desktop.

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 10.

        C'est la faute de la licence BSD qui nourri le propriétaire.

        (Et hop, lancé de troll à 10 points).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Pilotes graphiques libres

        Posté par  (site web personnel) . Évalué à 4.

        Eh bien moi ça m'inquiète cette tendance Linux only que l'on retrouve partout.

        En même temps KMS a été commité en novembre 2008 et a été intégré dans le noyau Linux version 2.6.29 (début 2009).
        Est-ce que la fondation FreeBSD n'aurait pas du se pencher sur le sujet un peu plus tôt ?

        • [^] # Re: Pilotes graphiques libres

          Posté par  (site web personnel) . Évalué à 8.

          Est-ce que la fondation FreeBSD n'aurait pas du se pencher sur le sujet un peu plus tôt ?

          Est-ce que la fondation FreeBSD a les mêmes moyens ?
          Est-ce que la fondation FreeBSD place une technologie liée aux performances graphiques assez haut dans la pile des priorités, sachant qu'elle a plutôt tendance à être utilisée en tant que serveur, typiquement headless ?

          J'avoue ne pas connaître cet univers par coeur. J'ai l'impression que KMS était optionnel avant mais devient maintenant obligatoire, ce qui pose un réel problème pour ceux qui ne l'ont pas encore. J'ai bon ?

          • [^] # Re: Pilotes graphiques libres

            Posté par  . Évalué à 1.

            Oui, tu as bon.

          • [^] # Re: Pilotes graphiques libres

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 23 octobre 2012 à 23:13.

            Un lien de la dépêche qui t’intéressera énonce que les pilotes sont dorénavant KMS et que dragonflybsd a intérêt à coller à KMS pour continuer à avoir des pilotes graphiques.
            C'est clairement prioritaire pour eux.
            Après, X.Org ou Wayland… X.Org a été modernisé et marche quand même à peu près donc il y a pas urgence à embrasser Wayland, en tout cas moins d'urgence.

            It is especially vital for Linux drm GEM, TTM, KMS code to be ported immediately to the BSDs because developers are in the process of removing userland modesetting code from current graphics drivers. To paraphrase what we have been told by freedesktop.org developers, if we do not port this code, very shortly the BSDs will be left only using the simplest VESA driver at 1024 x 768 resolution with no hardware acceleration.

            We believe that limiting divergence from Linux's drm code is the clearest path for the BSDs to be able to follow the latest drm developments.

      • [^] # Re: Pilotes graphiques libres

        Posté par  . Évalué à 1.

        D'un autre côté, on est dans les drivers, donc dans le noyau. Ça a toujours été Linux-only.

        Je comprend les détracteurs de software userland linux-only, mais si le noyau devait lui-même attendre que les autres aient implémenté les mêmes fonctionnalités avant de les utiliser, on en sortirait pas. Surtout que vu que la licence BSD et la GPL sont incompatibles, et que de toute façon l'architecture des noyaux est différente, il faut que BSD réimplémente les fonctionnalités de zéro.

        • [^] # Re: Pilotes graphiques libres

          Posté par  (site web personnel) . Évalué à 10.

          Même lien que donné ci-dessus :

          We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible. The developers of X.org / freedesktop.org related graphics drivers have their current efforts focused on Linux because they have to get something working anywhere as fast as possible. It is the BSDs responsibility to keep up with these efforts and to contribute back to these developers to justify the developers continuing to generously license their drm code under terms compatible with those of the BSD licenses.

          (je grasse)

        • [^] # Re: Pilotes graphiques libres

          Posté par  . Évalué à 5.

          D'un autre côté, on est dans les drivers, donc dans le noyau. Ça a toujours été Linux-only.

          Non les première version de dri était partagé entre linux et bsd.
          Mais vu que la plupart du dev était fait sous linux, on pouvait cassé assez facilement le support bsd.

          Surtout que vu que la licence BSD et la GPL sont incompatibles

          Faux il existe des pilotes sous dual licence GPL et BSD

  • # Petite correction

    Posté par  . Évalué à 5.

    En dehors du fait de savoir qui affiche les décorations, notons qu’à l’heure actuelle la question de la cohérence graphique se pose déjà quand on fait tourner une application GNOME sous KDE et vice‐versa, donc ce n’est pas vraiment nouveau.

    Je ne vois absolument pas de quoi tu parles, sous KDE les applications Gnome ont la même tête que les applis KDE. Merci le travail fait le projet KDE pour cela. Si tu as des problemes a ce niveau la, cela se change dans un truc totalement nouveau qui s'appelle "systemconfig". C'est un logiciel qui permet de configurer pas mal de chose sour KDE. Pour la definition de configuration, ne pas aller sur le site de Gnome ou de Apple mais dans un dictionnaire.

    :)

    Au fait les devs KDE étant super sympa, ils ont aussi fait l'inverse, c'est à dire que les applis KDE ressemble a des applis Gnome sous Gnome…

    • [^] # Re: Petite correction

      Posté par  . Évalué à 2.

      Chez moi, il faut que je change le thème gtk (pour QtCurve ou oxygen gtk) pour arriver à ce résultat. Tu est certain que c'est automatisé par kde chez toi ?…

      • [^] # Re: Petite correction

        Posté par  . Évalué à 4. Dernière modification le 23 octobre 2012 à 22:27.

        Par KDE surement pas mais pas ma distribution oui. Si c'est pas le cas change de distribution.

        Par contre c'est bien le projet KDE qui permet d'avoir un environnement visuellement coherent avec Gnome. Les gnomiste n'ont jamais pondu la moindre ligne de code pour aider sur le sujet!

    • [^] # Re: Petite correction

      Posté par  . Évalué à 2.

      OK, le texte aurait put être plus clair, mais l'idée était de dire que faire que des appli X ayant un look cohérent dans Y, ça a demandé des efforts et qu'ajouter les décorations dans la liste des choses a adapter, c'est juste un item de plus a rajouter dans la liste des choses a synchroniser pas une nouvelle problématique.
      Mais c'est clair que ça fait du boulot de synchro en plus.

      • [^] # Re: Petite correction

        Posté par  . Évalué à 3.

        J'avais bien compris mais l'exemple pris est le mauvais exemple car si il y a deux toolkits qui s'interfacent, graphiquement parlant à peu prés correctement, c'est bien KDE et Gnome et cela grace aux efforts des developpeurs de KDE.

        Mais si tu veux utiliser une applis EFL dans KDE ou Gnome, la ca doit etre une sacré cata en effet mais au moins avec les bords de fenêtre similaire ce qui ne sera même plus le cas avec wayland si j'ai bien compris. Ca peut devenir sacrément "funky" le bureau :)

        • [^] # Re: Petite correction

          Posté par  (site web personnel) . Évalué à 0. Dernière modification le 24 octobre 2012 à 10:38.

          Surtout qu'il y a :

          • des gestionnaire de fenêtres qui ne sont pas censés avoir de décorations de fenêtres ;
          • par conséquent des logiciels qui n'afficheront pas de décorations de fenêtres.

          Du coup, on se retrouvera avec :

          • des décorations affichées sur des fenêtres dans des environnements où elles n'ont rien à faire, ce qui ennuiera les utilisateurs avancés ;
          • pas de décorations sur des fenêtres dans des environnements où elles sont censées être, ce qui déroutera les utilisateurs novices.

          • [^] # Re: Petite correction

            Posté par  . Évalué à 2.

            Vous avez lu la dépêche avant de râler ?

            En fait, la décoration des fenêtres par les clients est une des caractéristiques du serveur d’affichage Weston, pas du protocole Wayland : les développeurs de KDE ont d’ailleurs prévu que ce soit le serveur d’affichage qui affiche les décorations des fenêtres.

            Donc si tu ne veux pas avoir de décoration avec ton gestionnaire de fenêtre Tiling-machin-chose, tu peux le faire ! Et si tu veux toujours avoir une décoration uniformisée, tu peux le faire (ce qui est actuellement le choix fait par KDE) !

            • [^] # Re: Petite correction

              Posté par  (site web personnel) . Évalué à 1.

              Ah, exact. Dans ce cas, la situation sera différente, en effet :

              • KWin décorant lui-même les décorations, les logiciels KDE ne décoreront pas leurs fenêtres ;
              • GNOME, Xfce puis les autres suivront probablement la même voie, ne serait-ce que pour que les logiciels KDE lancés sous GNOME aient des décorations.

              Du coup, en pratique, ce sera du coup la même situation que sous X11 : presque aucun logiciel ne décorera lui-même ses fenêtres. C'est Weston qui sera marginalisé, avec :

              • aucun logiciels standards décorés sous Weston ;
              • tous les logiciels conçus pour Weston doublement décorés sous les autres gestionnaires de fenêtres.

              • [^] # Re: Petite correction

                Posté par  . Évalué à 3.

                Il ne seront pas doublement décorés : le protocole permet de spécifier si le client doit envoyer la décoration ou pas (si je ne me trompe pas).

                • [^] # Re: Petite correction

                  Posté par  . Évalué à 2.

                  Je ne sais pas si le logiciel a déjà cette fonctionnalité mais c'est clairement quelque-chose de nécessaire.

              • [^] # Re: Petite correction

                Posté par  (site web personnel) . Évalué à 3.

                . KWin décorant lui-même les décorations, les logiciels KDE ne décoreront pas leurs fenêtres ;
                . GNOME, Xfce puis les autres suivront probablement la même voie, ne serait-ce que pour que les logiciels KDE lancés sous GNOME aient des décorations.

                Intéressant, j'ai jeté un œil :
                Client Side Decorations est prévu dans GTK+ : pour GNOME, Xfce ou les deux ?
                Mais c'était déjà prévu du temps de X.Org, indépendamment de tout plan concernant Wayland
                En tout cas c'est toujours noté "to do" sur la roadmap

                Bref, difficile de connaître les plans de GNOME et Xfce avec ces éléments

                Accessoirement GTK+ relève ces avantages :

                This involves better RGBA window support in the toolkit and improved mouse cursor handling.

                Concernant KWin

                I plan to support server side decorations in KWin. My main concern is inconsistency, I fear that GTK windows will look different than Qt windows and that’s something we should try to prevent IMHO.

                Ça explique pourquoi d'après chaosreigns, Qt5 prend en charge Wayland sauf client side decorations (mais vu que Qt vise l'embarqué, faudra voir quel compositeur est utilisé là bas).

                Bref, on sait que KDE n'utilisera pas Client Side Decorations, à part ça…

        • [^] # Re: Petite correction

          Posté par  (site web personnel) . Évalué à 1.

          j'utilise Chromium qui n'affiche pas la décoration de Kwin, bon Ok, au début on est pas habitué, mais je m'y suis fait au point de trouver toutes ces décorations identiques entre fenêtres, ennuyeuses.. il y a un gain potentiel de place si les appli dessinent elle-même la décoration, c'est la possibilité de dessiner le menu directement dans la déco, sans passer par des hacks ou Pied ne veut plus rendre ses appli compatible avec petit dragon.

          • [^] # Re: Petite correction

            Posté par  (site web personnel) . Évalué à 3.

            il y a un gain potentiel de place si les appli dessinent elle-même la décoration, c'est la possibilité de dessiner le menu directement dans la déco

            Il y a une spec DBus pour ça.
            Appmenu permet aux applications d'indiquer leur structure de menus et (entre autres) au WindowManager de l'afficher dans la décoration. C'est ce qu'utilise aussi Unity pour la recherche dans les menus via le Dash.

            Bref, pas besoin de décoration cliente pour ça.

            • [^] # Re: Petite correction

              Posté par  (site web personnel) . Évalué à 2.

              c'est ce que j'appelle, à tord, un hack (c'est tout sauf un hack, puisque justement ça permet d'éviter les customisations), il faut faire une interface dbus, mettre tous les WM d'accord, je me rappelle que KDE et Gnome n'était pas d'accord pour faire une interface dbus commune à un moment. Mais tant qu'on peut se débarrasser de la décoration, il n'y a pas de problèmes.

              DBus remplace les XAtoms et les fameux window manager hints très limité, auxquelles je me rappelle avoir été confronté, le tout entre plusieurs Unix. Horrible comme souvenir. Je suis bien content de plus m'occuper de ça!

  • # Gestionnaire de sessions

    Posté par  (site web personnel) . Évalué à 8.

    Le conception de la pile Wayland est différente d'X11. En particulier, le gestionnaire de fenêtres doit être intégré au serveur, autrement dit un gestionnaire de fenêtres alternatif est en fait un serveur Wayland alternatif, même s'il peut réutiliser du code existant de bibliothèques faites pour.

    En revanche, sauriez-vous ce que ça donne pour l'ouverture de session ? Actuellement, en environnement multi-utilisateur graphique sous X11, le serveur est lancé, puis un premier client, le gestionnaire de sessions. Celui-ci laisse les utilisateurs s'identifier, puis lance leur session préférée, qui est constituée d'un gestionnaire de fenêtres, et souvent d'un gestionnaire de bureau.

    Et sous Wayland donc ? Si le gestionnaire de fenêtres est intégré au serveur, pour lancer le gestionnaire de fenêtres, autrement dit le serveur préféré de l'utilisateur qui vient de s'identifier, il faudrait remplacer le serveur utilisé par le gestionnaire de sessions ?

    • [^] # Re: Gestionnaire de sessions

      Posté par  (site web personnel) . Évalué à 7.

      Il y a plusieurs possibilités: La première possibilité est comme tu dis de remplacer un compositeur par un autre.

      La seconde possibilité, qui est vraisemblablement celle qui sera choisi est d'emboîter (nest) les compositeurs.
      En gros, on a un premier compositeur qui est lancé et affiche l'écran de login. Ensuite, le compositeur de l'utilisateur est lancé par dessus. Cela a comme avantage de permettre le changement rapide d'utilisateur et un verrouillage d'écran sûr.

      Tu peux regarder du coté de lightdm qui explore déjà ces pistes

      • [^] # Re: Gestionnaire de sessions

        Posté par  (site web personnel) . Évalué à -2.

        Cela a comme avantage de permettre le changement rapide d'utilisateur

        Le truc que Linux implémente depuis ses début avec des consoles virtuelles multiples, quoi. Vachement utile de réinventer la roue…

        et un verrouillage d'écran sûr.

        Mmmh, peut-être bien, ce n'est pas bête ça.

        • [^] # Re: Gestionnaire de sessions

          Posté par  (site web personnel) . Évalué à 8.

          Le truc que Linux implémente depuis ses début avec des consoles virtuelles multiples, quoi. Vachement utile de réinventer la roue…

          Et qui prends des plombes à faire clignoter l'écran 3 fois.
          (Avec KVM c'est un peu mieux, mais quand même)
          Alors que là on pourrait même mettre les différentes sessions sur les différentes faces d'un cube.

        • [^] # Re: Gestionnaire de sessions

          Posté par  . Évalué à 8.

          Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher. C'est un "lege" probleme. Plus cosmetic, quand tu switch d'un utilisateur a un autre, c'est lent et c'est pas beau !

          En ayant un top compositeur qui se charge de ca, tu peux regler les deux problemes. D'un point de vue performance ce top compositeur sera surement la plus part du temps dans le mode je switch les buffers du seul fils que j'ai. Donc ca coutera un switch de context, mais ca sera tout. Si ce compositeur est garde simple, il sera donc une source de plus grande stabilite et d'interface plus sympatique. Ca ressemble au progres pour moi.

          • [^] # Re: Gestionnaire de sessions

            Posté par  . Évalué à 2.

            Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher. C'est un "lege" probleme.

            Je le déplore aussi malheureusement trop souvent, tu as raison sur ce point. Si ton X est bloqué jamais il réagira à Ctrl + Alt + Fx…

            Plus cosmetic, quand tu switch d'un utilisateur a un autre, c'est lent et c'est pas beau !

            Ça ça fait quand même pas mal de temps que c'est fini, enfin si tu utilises des drivers bien intégrés, et avec KMS (pas les blobs quoi)

          • [^] # Re: Gestionnaire de sessions

            Posté par  (site web personnel) . Évalué à 6.

            Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher.

            Alt + SysRq + R pour rendre le clavier au noyau
            Alt + Fn pour passer à la console n.
            De rien.

  • # Gestionnaire de fenêtre et toolkit

    Posté par  . Évalué à 0.

    Y'a un truc que je comprends pas très bien: Wayland incorporerait le gestionnaire de fenêtres, mais avec Weston, ce sont les clients qui dessinent leurs décorations. Il est où le gestionnaire de fenêtre dans tout ça?

    De plus, plutôt que de porter les toolkits (gtk, qt, etc, la liste est longue) pour wayland, il aurait été beaucoup plus intéressant et performant qu'un OS moderne se décide enfin à incorporer le toolkit dans le serveur graphique. Cela supprimerait une couche de plus. L'Amiga le faisait déjà, et c'était une des raisons pour lesquelles cette machine était si performante pour son époque et si facile à programmer. Avec les machines actuelles, se serait de la bombe en 3D…

    Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.

    • [^] # Re: Gestionnaire de fenêtre et toolkit

      Posté par  . Évalué à 5.

      Je ne comprends ce que tu veux dire avec des toolkits dans le serveur graphique, mais pour le gestionnaire de fenêtre, son but premier n'est pas de décorer les fenêtres mais de les placer sur l'écran et de savoir qui recouvre quoi.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Gestionnaire de fenêtre et toolkit

        Posté par  . Évalué à 2.

        D'un point de vue technique, faire gérer la fenêtre par l'application (via le toolkit) ne me choque pas.

        Je crains toutefois de voir une belle anarchie s'installer dans ce domaine.

        Il ne semble pas y avoir de mécanisme clair permettant d'unifier la gestion des fenêtres entre les applications GTK, GNOME-GTK, XCFE-GTK, QT, QT-KDE, X11 (via le serveur rootless intégré à Wayland), Java, SDL, GLUT, … ?

        Non seulement le look risque d'être différent d'un toolkit à l'autre mais les comportements aussi ('click' ou 'follow focus', raccourcis claviers, …).

        L'idéal serait d'avoir une lib (ou un service) unique s'occupant de tout les détails du coté client mais je suis près à parier qu'il ne faudra pas attendre 15 jours pour voir apparaitre une lib concurrente ou un toolkit qui refait le truc en 'mieux'.

        J'espère que je me trompe mais franchement je m'attends à un beau bordel!

        et je n'ose même pas imaginer les applications qui décideront de gérer même leur décorations.

      • [^] # Re: Gestionnaire de fenêtre et toolkit

        Posté par  . Évalué à 0.

        Mon premier pc décent était un Amiga. Dans l'AmigaOS, il n'y a qu'un seul toolkit qui est intégré dans le serveur graphique. Le toolkit de l'Amiga est l'équivalent de Xlib + toolkit xyz. De plus, une partie était intégré dans le kernel. Ce qui avait l'avantage de la simplicité et d'être rapide même sur un processeur qui ne tournait qu'à 8MHz et disposait que de quelques MB de ram. Le tout en couleur et sonorisé, basé sur un kernel préemptible multitâche. Le meilleur de mes ordis.

        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.

    • [^] # Re: Gestionnaire de fenêtre et toolkit

      Posté par  (site web personnel) . Évalué à 3.

      1- Le gestionnaire de fenêtre est un concept X11, Ce concept n'existe plus avec Wayland, tout comme il n'existe pas sous Windows. Mais les fonctionnalités ne sont pas pour autant perdue, puisqu'on peux toujours choisir un compositeur alternatif.

      2- les toolkits comme Qt ou glib/GTK ne sont pas juste des éléments graphique, Il correspondent surtout a une façon de programmer différente : Langages différents, API différentes, paradigmes différents.

      3- Pourquoi serait-il plus performant de mettre les éléments graphiques coté serveur ? Peut être que pour des applications simple, on gagnerais en latence lors de l'utilisation de la transparence réseau, Mais dans le cas pour lequel Wayland est prévu, je ne vois pas ce qu'il y a à gagner. Les clients Wayland ont justement plus de possibilité quand il peuvent simplement dessiner leur fenêtre de la manière qu'il souhaite.

      • [^] # Re: Gestionnaire de fenêtre et toolkit

        Posté par  . Évalué à 2. Dernière modification le 24 octobre 2012 à 11:45.

        Par rapport au 1 : DWM.exe n'est pas justement le gestionnaire de fenêtres de Vista/Seven (et suivants) ?
        http://en.wikipedia.org/wiki/Desktop_Window_Manager

        (je n'ai pas souvenir de ce genre de processus dans les Windows précédents…)

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Gestionnaire de fenêtre et toolkit

        Posté par  . Évalué à 0.

        Si tu lis la FAQ, le gestionnaire de fenêtre existe toujours, simplement, comme dans l'AmigaOS, il est incorporé dans le serveur d'affichage et le compositeur.

        Si wayland est bien fait, il doit être possible de gagner beaucoup pour tout ce qui touche à l'affichage. Si je compare aeros (une version libre de l'AmigaOS qui peut être installée comme hôte linux ou en natif), le Gimp se lance 4 ou 5 fois plus rapidement sous aeros installé comme hôte sous linux que Gimp en natif linux dans la même machine. Ce qui ne change pas par contre sont les temps de traitement des filtres sur les images. Mais au niveau du lancement des applications et de la fluidité de X, la différence est impressionnante.

        Donc, affaire à suivre. Je pense cependant que pour les applications wayland, cela devrait être rapide. Pour les applications X lancées sous wayland, c'est à voir. Quand à lancer X sous wayland, ce sera (d’après la FAQ) un petit peu plus lent.

        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.

    • [^] # Re: Gestionnaire de fenêtre et toolkit

      Posté par  . Évalué à 2.

      Y'a un truc que je comprends pas très bien: Wayland incorporerait le gestionnaire de fenêtres, mais avec Weston, ce sont les clients qui dessinent leurs décorations. Il est où le gestionnaire de fenêtre dans tout ça?

      Oui, une partie des fonctionnalités du gestionnaire de fenêtre "a la X" est faite par le client (le dessin et la gestion des décorations des fenêtres) quand on utilise Weston, mais il reste le déplacement des fenetres (le client détecte que l'utilisateur veut déplacer la fenetre et dit à Weston "je suis en mode de déplacement" qui déplace ensuite la fenetre de manière autonome jusqu'à ce que l'utilisateur relache le boutton puis il rend la main), prendre la main sur les clients qui ne "ping" plus, etc.

      incorporer le toolkit dans le serveur graphique.

      M'étonnerait, tu perds en souplesse et (sauf en cas distant) je ne pense pas que tu gagne beaucoup en performance.

  • # X.Org mériterait un peu plus d'égards.

    Posté par  . Évalué à 10.

    Outre l'aspect je traine des casseroles depuis 30 piges c'est quand même un serveur graphique qui a fait les beaux jours de Linux (et *BSD) et qui fonctionne très bien sur mon matériel tantôt nVIDIA proprio tantôt GMA4500.
    Certes une reconception du serveur graphique était necessaire mais c'est pas comme si on utilisait de la merde depuis 10 ans.

    X.Org n'est pas mort, il se retire après avoir servi fièrement* le monde du libre.

    ciao l'artiste!

    *et d'achever les dernier cheveux de pas mal de codeurs. :)

  • # comparaison taille API

    Posté par  . Évalué à 10.

    Pour se donner une petite idée de leurs différences, l’interface de programmation (API) de Wayland est environ 15 fois plus petite que celle de X…

    On en reparlera dans 30 ans si W est toujours là! ^_^

    • [^] # Re: comparaison taille API

      Posté par  . Évalué à 2.

      Je doute fortement que l'API grossisse tant que ça pour en arriver à celle de Xorg.
      Xorg fait 50 fois plus de choses, et je pense que c'est surtout les méthodes de rendu qui explosent le compteur. Chose qui n'est pas prévue pour Wayland.

    • [^] # Re: comparaison taille API

      Posté par  . Évalué à 4.

      On en reparlera dans 25 ans si L est toujours là _^

  • # Pas d'OpenGL?

    Posté par  (site web personnel) . Évalué à 3.

    D'après la FAQ de Wayland:

    A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so we're using GLES2 for now. Longer term, we'll need a way to use full GL under Wayland.

    Ca veut dire que sous Wayland, on va devoir se contenter du OpenGL handicapé (GLES)?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Pas d'OpenGL?

      Posté par  . Évalué à 3.

      Il me semble que ça signifie seuleument que le compositeur devra utiliser GLES, si tu veux qu'une de tes applis utilise un GL complet tu pourras, mais il faudra aller chercher les dépendances nécessaires.

    • [^] # Re: Pas d'OpenGL?

      Posté par  . Évalué à 3.

      Et il me semble que OpenGL ES n'enlève pas tant de possibilités que ça. La grosse différence viendrait de l'épuration des fonctions gardées dans OpenGL par souce de compatibilité ascendante. Ce serait donc d'abord une mise au propre moderne de OpenGL puis un compromis légèreté/fonctionalités.
      (Attention, je n'ai pas dit que ça n'enlevait rien d'utile du tout!)

      • [^] # Re: Pas d'OpenGL?

        Posté par  (site web personnel) . Évalué à 2.

        Un gros avantage d'OpenGL, c'est que les vieux programmes écrit il y a 15 ans sur mon Pentium 75 sans carte 3d fonctionnent toujours avec, les nouveaux pouvant profiter des extensions.

        Mais un jour certains ont prétexté qu'il fallait une API designed for embedded system (dont le plus minable représentant est certainement plus puissant que mon P75), mais surtout designed pour pas se faire chier à implémenter.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # X -> W : retour vers le futur ?

    Posté par  . Évalué à 9.

    Salut,

    article très intéressant.

    Je me suis amusé en lisant :

    C’est donc finalement le W de Wayland qui succèdera à X !

    Car au départ X était l'évolution de W, voir la partie History de http://en.wikipedia.org/wiki/X_Window_System :

    X derives its name as a successor to a pre-1983 window system called W (the letter preceding X in the English alphabet). W ran under the V operating system. W used a network protocol supporting terminal and graphics windows, the server maintaining display lists.

    D'où le titre de mon commentaire ;-)

  • # directFB

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 24 octobre 2012 à 10:28.

    comment peut-on comparer Wayland à DirectFB? Je crois que directFB impose un gestionnaire de fenêtre (un peu comme Weston, ou une implémentation alternative du protocole)?

    J'ai l'impression surtout que directFB n'utilise pas EGL, ou que la différence doit être de cet ordre…

  • # x.org est mort

    Posté par  . Évalué à -1.

    mais Xfree NON

  • # XDG_RUNTIME_DIR

    Posté par  . Évalué à 3.

    L’architecture de Wayland utilise la variable d’environnement XDG_RUNTIME_DIR que systemd implémente actuellement sous GNU/Linux.

    Sans vouloir la ramener, il me semble que le terme approprié est "définit". Défini la variable et éventuellement implémente un mécanisme.

    $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, …) should be stored.

    Selon la spec, ca me fait penser à un $HOME/tmp/ qu'il suffirait d'exporter dans le .profile.

Suivre le flux des commentaires

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