Sortie de Wayland et Weston 1.6

Posté par  . Édité par ZeroHeure, Davy Defaud, Xavier Teyssier, palm123 et Nils Ratusznik. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
44
7
oct.
2014
Serveurs d’affichage

Wayland et son implémentation de référence Weston sont sortis en version 1.6 le 19 septembre 2014.

Sous GNU/Linux et BSD (entre autres), lorsqu’une application veut afficher quelque chose à l’écran, elle doit utiliser le protocole X11 pour communiquer avec X.Org. Mais X.Org est vieux, pas vraiment adapté au matériel moderne ni très sécurisé.

Wayland

Wayland est le nom du projet, du protocole conçu pour remplacer X11 et d’une bibliothèque qui l’implémente. Une partie du travail qui était réalisé par X.Org devra désormais l’être par le compositeur, dans la plupart des cas le gestionnaire de fenêtres. Weston est une implémentation de référence d’un compositeur pour démontrer les capacités des protocoles (Wayland, xdg-shell…) et des bibliothèques utilisées (libxkbcommon, libinput…).

Wayland

  • ajout de l’énumération des erreurs dans wl_surface ;
  • ajout des informations sur la répétition du clavier dans le protocole wl_keyboard ;
  • ajout pour la récupération d’erreur dans libwayland-client : quand il y a une erreur dans le protocole, le programme peut demander des informations plus détaillées à propos de l’erreur. C’est surtout utile lors des tests pour s’assurer que ce sont les bonnes erreurs ;
  • wl_display_add_socket_auto() dans libwayland-server trouve automatiquement un nom de chaussette libre [oui, c’est de socket, mais ça fait rire le modérateur] ;
  • plein de tests ajoutés à la suite make check, dont un cadriciel pour tester les interactions client‐serveur plus facilement (en rapport avec des corrections de bogues de parallélisation et de blocage) ;
  • ajout de wl_display_roundtrip_queue() pour bloquer les round‐trips dans une file d’attente personnalisée ;
  • suppression de l’exposition globale du binding wl_display, ça aurait déclenché des bogues, et on n’en a pas d’utilisation correcte.

Weston

  • changement du protocole xdg-shell (compatibilité cassée par rapport à la 1.5.0) ;
  • ajout d’un mécanisme de masquage pour weston-layer ;
  • dorsal (backend) DRM : récupération de la taille du curseur depuis le noyau ;
  • gestion configurable du taux de répétition du clavier, envoyé du compositeur au client ;
  • ajout de wl_display_add_socket_auto() pour ne plus avoir besoin d’indiquer la chaussette (la socket) pour lancer Weston dans Weston ;
  • utilisation de libinput par défaut. Le dorsal qui n’utilise pas libinput est toujours là, mais sera supprimé pour la 1.7 ;
  • un peu de configuration supplémentaire pour le desktop-shell ;
  • make distcheck fonctionne maintenant sans bidouillage (en désactivant le test de xwayland pour distcheck pour le moment) ;
  • quitter Weston si weston-desktop-shell meurt trop tôt. Cela devrait régler certains problèmes d’écrans noirs ;
  • option pour forcer l’activation du verrouillage numérique au démarrage pour les dorsaux DRM et fbdev ;
  • plein de corrections (évidemment).

Versions suivantes

Le cycle de développement de la 1.7 commence la semaine prochaine. Le programme jusqu’à la version 1.7.0 est :

  • 1.7-alpha à la mi‐janvier 2015 (autour du 16) pour que les gens aient un ou deux week‐ends après les vacances pour pousser les travaux de dernière minute. C’est le dernier délai pour les grosses fonctionnalités ;
  • 1.7-rc1 autour du 30 janvier. Au‐delà de cette date, seules les corrections seront acceptées ;
  • 1.7-rc2 autour du 6 février ;
  • 1.7.0 publiée autour du vendredi 13 février. Oups !

Aller plus loin

  • # A noter: la release a été faite par Pekka Paalanen.

    Posté par  . Évalué à 6.

    Avant c'était Kristian Høgsberg (l'initiateur du projet) qui faisait les release mais apparemment il ne travaille plus sur Wayland pour le moment.

  • # triste

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

    compatibilité cassée par rapport à la 1.5.0

    C'est triste de casser la compatibilité avec un changement de version mineure.

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

    • [^] # Re: triste

      Posté par  . Évalué à 10.

      Encore?
      Ça a été un sujet de discussion sur LWN, bien longue la discussion et finalement la raison pour laquelle ils ont fait ça est que xdg-shell est encore considéré comme étant expérimental donc casser la compatibilité sur un protocole expérimental n'implique pas de mettre à jour le numéro de version majeur du projet ce qui me parait normal: http://lwn.net/Articles/612653/

      • [^] # Re: triste

        Posté par  . Évalué à 10.

        Encore?

        Tout le monde ne lis pas LWN :)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: triste

          Posté par  . Évalué à 10.

          Tout le monde devrait lire LWN :)

      • [^] # Re: triste

        Posté par  . Évalué à 7.

        Si le protocole est expérimental, pourquoi sa version est en 1.x et pas en 0.x ?

        Je sais que c'est purement indicatif, mais le numéro de version est souvent relativement important pour se faire une idée de l'utilisabilité.

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

        • [^] # Re: triste

          Posté par  . Évalué à 4.

          C'est xdg-shell qui est expérimental pas Wayland.
          Xdg-shell c'est spécifique aux environnements de bureaux genre KDE/Gnome.

          • [^] # Re: triste

            Posté par  . Évalué à 5.

            D'accord.

            Je trouve tout de même que c'est pas clair. Pourquoi y'a-t-il autant de protocoles ?

            Que fait Wayland concrètement ? Pourquoi faut-il lui adjoindre des protocoles supplémentaires (non finalisés qui plus est) pour que les bureaux puissent l'utiliser ? Même sur Wikipédia je ne pige pas trop :-/

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

            • [^] # Re: triste

              Posté par  . Évalué à 5.

              Pourquoi y'a-t-il autant de protocoles ?

              Parce que Wayland peut être utilisé dans des contextes différents.
              Donc tu as un protocole 'de base' (wayland) pour l'envoi de buffers graphiques plus d'autre protocole qui eux sont utiles ou pas selon le contexte.
              xdg-shell c'est le protocole pour les environnements de bureaux (gestion des fenêtres, des titres, du copier/coller(pas sûr là)), protocole dont tu n'as rien a faire si tu est dans l'embarqué par exemple.
              Je crois qu'il y a un consortium automobile qui travaille sur un protocole par exemple.

              • [^] # Re: triste

                Posté par  . Évalué à 4.

                Merci, c'est limpide expliqué comme ça, en tout cas largement plus compréhensible que ça :

                XDG-Shell protocol (see freedesktop.org for XDG) is an extended way to manage surfaces under Wayland compositors (not only Weston). The traditional way to manipulate (maximize, minimize, fullscreen, etc.) surfaces is to use the wl_shell_*() functions, which are part of the core Wayland protocol and live in libwayland-client. An implementation of the xdg-shell protocol, on the contrary, is supposed to be provided by the Wayland compositor. So you will find the xdg-shell-client-protocol.h header in the Weston source tree. Each Wayland compositor is supposed to provide its own implementation.

                Cela signifie aussi qu'il est possible d'implémenter tout ce que faisait X11 auparavant sous forme de protocoles, non ? Tel l'export display par exemple ?

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

                • [^] # Re: triste

                  Posté par  . Évalué à 5.

                  Weston a une backend RDP mais j'ignore si elle permet d'exporter juste une fenetre ou si c'est nécessairement tout le bureau.
                  Ce que tu propose me parait possible en tout cas.

                  • [^] # Re: triste

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

                    Pour l'instant, tout le bureau ; mais en utilisant fullscreen-shell (qui met une seule appli en plein écran à la fois) on obtient plus ou moins l'effet souhaité.

                    • [^] # Re: triste

                      Posté par  . Évalué à 4.

                      Tu peux développer? C'est la première fois que j'entends parler de fullscreen-shell..
                      Ça marche bien la backend RDP de Weston?

                      • [^] # Re: triste

                        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 09 octobre 2014 à 16:19.

                        Fullscreen-shell est un shell alternatif poussé par Jason Ekstrand, qui se builde avec --enable-fullscreen-shell et s'utilise avec --shell=fullscreen-shell.so. Il a la particularité de n'avoir aucune interface et de n'afficher qu'une surface à la fois, sur fond noir, comme quand on passe en mode "fullscreen" (F11) dans weston-terminal p.ex. Les applications doivent le gérer, mais toutes celles intégrées à Weston ont déjà été adaptées.

                        Je suis incapable de t'en faire une vidéo maintenant car mes installs sont custom, mais je vais voir.

                        Oui le backend RDP marche bien, voilà une vidéo sous Tizen et voilà comment l'utiliser. Tu remarques que les applis GL marchent, car j'ai ajouté le support Gallium qui "pipe" le calcul en mode software.

                        Pour l'instant le hack consiste à faire ainsi :

                        • compiler fullscreen-shell et le compositeur RDP ;
                        • lancer le compositeur RDP avec fullscreen-shell ;
                        • lancer une application dans ce compositeur, elle sera fullscreen ;
                        • se connecter à partir de xfreerdp.

                        Cela revient à dire : 1 compositeur = 1 appli. On pourrait bien sûr automatiser ces étapes avec des scripts et hacks.

                        • [^] # Re: triste

                          Posté par  . Évalué à 3.

                          Merci pour ta réponse.

                          Si je comprends bien pour obtenir l'équivalent d'un export DISPLAY avec RDP il faudrait ajouter un démon qui va faire la connexion car avec RDP se fait de la partie qui a l'écran receveur a la partie qui émet l'image de l'application au contraire d'X.

                          • [^] # Re: triste

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

                            Oui, dans l'état actuel, c'est ça.

                            L'implémentation actuelle du compositeur RDP ne peut pas faire de "vrai" seamless car elle n'interagit pas avec le shell/window manager pour cibler la fenêtre qui nous intéresse. Je suis cependant certain qu'on peut le modifier pour ça devienne possible.

  • # Touffu de chez touffu

    Posté par  . Évalué à 7.

    Quand on regarde le diagramme "pédagogique" qu'on trouve dans Wikipédia (https://fr.wikipedia.org/wiki/Wayland#mediaviewer/File:Free_and_open-source-software_display_servers_and_UI_toolkits.svg), ça fait un peu froid dans le dos…

    • [^] # Re: Touffu de chez touffu

      Posté par  . Évalué à 3.

      Ah? Je ne trouve pas moi.
      Note que ce diagramme est une simplification de ce qui se passe en réalité: les compositeurs peuvent être empilé par exemple.

      • [^] # Re: Touffu de chez touffu

        Posté par  . Évalué à 6.

        Il me semble surtout mal fait personnellement. On s'attend à ce qu'il présente, les couches mais en fait pas du tout.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Touffu de chez touffu

          Posté par  . Évalué à 1.

          Là je suis d'accord, une vue avec un axe des temps serait beaucoup plus lisible pour comprendre ce qui se passe.

          Après c'est quand même super pénible/difficile de faire des bons graphiques..

          • [^] # Re: Touffu de chez touffu

            Posté par  . Évalué à 6.

            C’est comme le schéma de l’audio sous GNU/Linux:

            • c’est facile de faire des diagrammes compliqués.
            • j’attends celui de Windows.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Touffu de chez touffu

              Posté par  . Évalué à 2. Dernière modification le 08 octobre 2014 à 07:44.

              XAudio2 : l'API qui remplace DirectSound.
              DirectSound : le son pour les jeux/multimédia depuis que DirectX existe (ou à peu près)
              WaveOut : la bonne vieille API Win32.
              DirectMusic : pour le MIDI, je doute qu'elle soit encore utilisée, mais je sais pas si elle est remplacée

              En matière vidéo, c'est pas mal :
              Video For Windows : la vieille API pour encoder et décoder vidéo et audio héritée de Windows 3 et ses Multimedia Extensions (MME)
              DirectShow : remplace VFW depuis ~1998
              Media Fondation : remplace DirectShow depuis ~Vista

              (en lisant wikipedia, j'ai oublié WASAPI, ou le vieux mixeur du noyau nommé KMix, ou encore le Multimedia Class Scheduler Service, mais ça m'a l'air d'être en plus de ces API et non pas encore d'autres API pour jouer du son ou de la musique)

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

              • [^] # Re: Touffu de chez touffu

                Posté par  . Évalué à 4.

                Sauf que mes souvenirs sont bons, il y avait aussi des bibliothèques audio comme SDL, OpenAL, etc qui faisaient partie du diagramme.

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Touffu de chez touffu

                  Posté par  . Évalué à 2.

                  Oui, dans les gros schémas Audio avec Linux, j'ai vu plein de bibliothèques genre SDL mentionnées, alors qu'elles ne font qu'utiliser les 3 systèmes réels :

                  • OSS
                  • ALSA
                  • PULSEAUDIO

                  OpenAL était le contournement pour accéder à l'accélération matérielle de certaines cartes son depuis Vista.

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

      • [^] # Re: Touffu de chez touffu

        Posté par  . Évalué à 8.

        Bah, j'aurais peut-être dû préciser, mais je trouve que la figure est imbittable parce qu'elle mélange beaucoup trop de niveaux d'information. D'une part, les boites comportent des trucs balancés comme ça un peu n'importe comment, on a G-sensor dans le hardware, mais pas la carte graphique, par exemple. D'autre part, l'organisation spatiale est, dans une grande mesure, totalement aléatoire. Les desktop widgets à gauche, les widgets for Unity à droite, wxWidgets sur la ligne du dessous; Ubuntu séparé du reste, mais d'après le schéma, Ubuntu tourne sur Android (la mienne tourne sous GNU/Linux, mais bon). Sur la même ligne on a des trucs alternatifs et/ou complémentaires et/ou totalement indépendants.

        En ce qui me concerne, l'histoire des serveurs graphiques est l'un des trucs que je comprends le moins. J'ai l'impression qu'il y a plein d'inertie historique, et plein d'empilements de couches totalement redondants. Je n'ai par exemple jamais compris de quoi X se mêlait quand il tripotait mon mapping clavier—c'est déja géré par le kernel en dessous, et par le bureau au dessus, et quand X plante, il y a une chance sur deux que le clavier soit mort. Quand on regarde le schéma, X se ballade entre netfilter et SDL (?). Sérieusement, je ne sais pas ce que ce schéma explique, mais il l'explique mal :-)

        • [^] # Re: Touffu de chez touffu

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

          En ce qui me concerne, l'histoire des serveurs graphiques est l'un des trucs que je comprends le moins. J'ai l'impression qu'il y a plein d'inertie historique, et plein d'empilements de couches totalement redondants.

          X-Window fonctionne de base sur tous les UNIX, rien que cela, c'est beau et bien moins trivial qu'il n'y parait !

        • [^] # Re: Touffu de chez touffu

          Posté par  . Évalué à 4.

          Je n'ai par exemple jamais compris de quoi X se mêlait quand il tripotait mon mapping clavier—c'est déja géré par le kernel en dessous, et par le bureau au dessus

          C’est faux. La disposition de clavier est gérée soit par kbd (dans les tty), soit xkb (qui fait partie de X.org, les environnements de bureau ne font que surcouche à X.org). Le noyau ne capte que du qwerty quand on utilise les touches système magiques.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Touffu de chez touffu

            Posté par  . Évalué à 2.

            Ah? Ben pourtant il y a des modules avec des keymaps dans le noyau pour les télécommandes?

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

            • [^] # Re: Touffu de chez touffu

              Posté par  . Évalué à 2.

              Disposition (keymap) ≠ code de touche (keycode). Un clavier ou une télécommande à des codes de touche (pour un clavier: première touche de la première rangée, deuxième touche de la première rangée, etc), et c’est interprété par rapport à la disposition de touches choisie (première touche de la première rangée = B en bépo, A en azerty, Q en qwerty, etc). Je ne crois pas que ça le fasse pour une télécommande du coup, ou alors c’est aussi géré par X.Org.

              Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Touffu de chez touffu

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

      Ce qui fait peur dans ce schéma c'est de voir que tout le monde, de l'éditeur de texte au modeleur 3D en passant par le widget de notification, va utiliser OpenGL, une API absolument pensé pour être utilisé par de nombreuses applications en même temps: tout le monde a accès à l'intégralité des ressources du GPU, par définition limitées…

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

      • [^] # Re: Touffu de chez touffu

        Posté par  . Évalué à 1.

        une API absolument pensée pour être utilisée par de nombreuses applications en même temps

        Tu as oublié un pas.
        Plus sérieusement, je n'y connais rien mais n'est-ce pas déjà ce qui se passe aujourd'hui avec X ?

      • [^] # Re: Touffu de chez touffu

        Posté par  . Évalué à 0.

        Ce qui fait peur dans ce schéma c'est de voir que tout le monde, de l'éditeur de texte au modeleur 3D en passant par le widget de notification, va utiliser POSIX, une API absolument pensé pour être utilisé par de nombreuses applications en même temps: tout le monde a accès à l'intégralité des ressources du CPU, par définition limitées…

        • [^] # Re: Touffu de chez touffu

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

          Ce n'est pas la même chose. Avec le temps CPU, un vilain processus va juste ralentir ses petits copains et il peut être calmé par le kernel.

          Avec les ressources GPU, si tu abuses des textures/shaders/buffers, plus personne ne peut rien afficher.

          Si tu veux en être convaincu, lance quelques jeux 3D et enchaînent les alt-tabs.

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

          • [^] # Re: Touffu de chez touffu

            Posté par  . Évalué à -2.

            Pour moi c'est la même chose. Il y a une ressource physique à partager. Ressource qui doit être allouée plus ou moins dynamiquement soit:
            1) par le noyau
            2) une application tierce
            3) de manière coopérative par les applications

            1) fonctionne mais est souvent un peu lent

            2) est aussi souvent lent et ajoute un tas de pbs sur les systèmes de type Unix (cf le mauvais OS, émulateur de terminal /usr/bin/X qu'ils essayent de remplacer).

            3) est la pire des solutions, cela fonctionne quand une application à l'utilisation exclusive de la ressource (c'est un cas particulier de la solution 2) mais dès que deux applications essayent de coopérer…

            Bon maintenant je ne sais pas si openGL est la bonne abstraction à utiliser.

  • # libinput

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

    Je vous conseille la lecture de l'article http://who-t.blogspot.fr/2014/09/libinput-common-input-stack-for-wayland.html qui explique d'où vient le projet libinput et à quoi il sert.

    • [^] # Re: libinput

      Posté par  . Évalué à 2.

      Hum, cet article a provoqué pas mal de réaction sur ceux qui utilisent leur touchpad de manière "non-standard": soit c'est l'article soit libinput va faire grincer des dents pas mal de monde..

      • [^] # Re: libinput

        Posté par  . Évalué à 3.

        Il ne faut jamais "sursauter" sur un article qui essaye d'expliquer calmement le chemin proposé. Bien sûr que le clic central, s'il existe sur des touchpads (j'en ai jamais vu) pourra être utilisé. C'est article explique surtout qu'il faut tailler dans la jungle actuelle pour obtenir une gestion clavier/souris/touchpad/joystick/télécommande/etc… fiable.

        Ayant essayé récemment une télécommande USB, je te garantis que ce n'est pas prêt pour le bureau. Je suis tombé sur la limitation à 8 bits des codes clavier dans le protocole X. Le noyau envoie bien la commande NEXT mais X la filtre… comprenne qui peut!

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

Suivre le flux des commentaires

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