Journal Wayland & Weston 1.5.0 sont publiés

Posté par  . Licence CC By‑SA.
Étiquettes :
30
21
mai
2014

Wayland et son implémentation de référence Weston sont sortis le 20 mai en version 1.5. Au programme, pas de révolution mais beaucoup de bugs corrigés.

Au menu pour cette version :

Wayland

  • Rien de particulier pour l'utilisateur lambda.

Weston

  • Intégration de xdg-shell. Tout n'est pas terminé mais c'est en bonne voie et ce sera normalement finalisé pour la 1.6 et donc présent dans GNOME 3.14.

  • La pile input de Weston a été refactorisée dans une nouvelle librairie libinput.

  • Nouveau serveur Xwayland. Ce nouveau serveur est plus simple et fonctionne à la manière de Xwin et Xquartz. De plus, Xwayland est dorénavant inclus dans la version officielle de Xorg.

  • Animation pour la fermeture des fenêtres.

  • Un mode plein écran pour une utilisation en kiosque.

  • Weston supporte différentes profondeurs de couleurs sur les différentes sorties vidéos.

Voilà pour cette version… Pour les détails je vous laisse consulter l'annonce officielle : http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html.

  • # Titre

    Posté par  . Évalué à 5.

    Intégration de xdg-shell. Tout n'est pas terminé mais c'est en bonne voie et ce sera normalement finalisé pour la 1.6 et donc présent dans GNOME 3.14.

    Vu que Gnome n'utilise pas Weston, je ne comprend pas cette phrase.

    « 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: Titre

      Posté par  . Évalué à 2.

      C'est le protocole qu'ils mettent au point: ils essayent de faire une interface 'standardisée' pour qu'il y ai interopérabilité entre les applications et les desktop.
      Qu'une appli Qt puissent fonctionner dans un desktop GNOME par exemple.

      • [^] # Re: Titre

        Posté par  . Évalué à 7.

        Si c'est le protocole, pourquoi c'est dans la section Weston ?

        « 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: Titre

          Posté par  . Évalué à 6.

          Je suppose que c'est parce que Weston est l'implémentation de référence, et donc une fois dedans on peut facilement se baser dessus pour les autres implémentations sans crainte de faire son IE6.

        • [^] # Re: Titre

          Posté par  . Évalué à 1.

          Parce que Wayland est seulement le protocole universel de "bas niveau" pour échanger des buffers.

          Universel dans le sens ou il ne dépend pas d'un cas d'utilisation particulier.

          Au dessus il y a plusieurs protocoles qui dépendent de la situation:
          -pour un desktop xdg-shell dans Weston (et les autres compositeurs de bureau)
          - je crois que l'industrie auto a un protocole au dessus de Wayland pour la centrale embarquée
          etc.

        • [^] # Re: Titre

          Posté par  . Évalué à 5.

          Les protocoles sont développés dans weston, et une fois stables ils passent dans wayland.

          C'est ce qui c'est passé pour le protocole subsurface. Ajouté ici dans wayland, retiré dans weston.

          Après certains protocoles sont vraiment spécifiques à weston et n'ont pas vocation à migrer vers wayland, mais je ne crois pas que ce soit le cas de xdg-shell. Il y a même déjà un protocole rudimentaire wl_shell que xdg-shell viendra remplacer.

          • [^] # Re: Titre

            Posté par  . Évalué à 7.

            Je crois que les poules auront des dents (et que ce sera l'année du desktop Linux) lorsque je comprendrai enfin qui sert à quoi dans Wayland et compagnie.

            • [^] # Re: Titre

              Posté par  . Évalué à 8.

              Wayland est le protocole ainsi qu'une bibliothèque qui l'implémente.
              Il permet à une application de gérer son affichage, recevoir ses évènements clavier et souris, gérer le copier-coller et probablement d'autres choses auxquelles je ne pense pas tout de suite.

              Weston est un compositeur de référence, il permet d'avoir une démonstration du fonctionnement. C'est le compositeur qui expose l'interface wayland, il utilise donc la bibliothèque wayland pour être serveur.

              Pour avoir un environnement de bureau complet il faut des interfaces supplémentaires : les commandes pour gérer les fenêtres, de demandes de capture d'écran, un moyen pour faire un clavier virtuel, de l'affichage distant etc. Ces fonctionnalités ne sont pas dans wayland directement (ou pas encore), elles peuvent être implémentées dans weston pour une démonstration ou simplement comme référence.

      • [^] # Re: Titre

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

        C'est le protocole qu'ils mettent au point: ils essayent de faire une interface 'standardisée' pour qu'il y ai interopérabilité entre les applications et les desktop.

        Alors ça je trouve que c'est une bonne initiative. Je lui souhaite bonne chance.

        Si c'est le protocole, pourquoi c'est dans la section Weston ?

        https://wiki.tizen.org/wiki/Wayland_xdg-shell_protocol
        xdg-shell, on the contrary, is supposed to be provided by the compositor. So you will find the "xdg-shell-client-protocol.h" header in the Weston source tree.

        kentoc'h mervel eget bezan saotred

  • # NX

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

    Je sais que Wayland ne s'occupe pas de la tansparence réseau mais j'ai fais quelques essais sur des liaisons TRES bas débit et pas fiable.

    • nx (x2go) : le top (ou le moins pire). Serait parfait s'il pouvait passer dans un session MOSH
    • xpra : pas si mal et très simple
    • vnc : moyen
    • spice : très moyen aussi
    • X-Window dans ssh -CX : très très bof

    Bref, j'ai été très décu par spice qu'on nous annonce depuis des années, j'ai trouvé qu'xpra fait beaucoup mieux. J'ai pas du faire les bons réglages… Le plus sympa me semble xpra mais x2go est largement devant tout le monde en terme de réactivité.

    Si on ne veut pas que des weberies, c'est important la transparence réseau, et qui marche !

    S'il y a d'autres retours, je suis preneur.

    • [^] # Re: NX

      Posté par  . Évalué à 2.

      Tu n'as pas testé RDP ?
      Tu testais avec du son ou de la vidéo ?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: NX

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

        Pas fait RDP cette fois là donc c'est pour cela que je n'en ai pas parlé.

        Pas fais de la vidéo ni du son (déjà avec une application locale dédiée, comme skype ou une autre, cela marche mal sur cette liaison), je veux par exemple utiliser firefox à distance ou un simple éditeur (nedit est mon préféré pour les tests) ou une saloperie de logiciel privateur pour des baies ou… Donc une IHM classique assez statique.

        D'ailleurs, je ne sais pas si Firefox a un greffon pour inter-connecter deux firefox distant ? Je veux que les requêtes soit réalisées sur la machine distante.

        • [^] # Re: NX

          Posté par  . Évalué à 3.

          J'oubliais, avec quel toolkit et quel thème as-tu testé ? ça peut faire de grosses différences. Dans un installation LTSP par exemple il vaut mieux ne pas utiliser KDE avec Oxygen.

          Il y a quelques années j'avais aussi mené des tests, mais sans Spice, pour aboutir aux mêmes conclusions. Peu après j'ai du pratiquer RDP et ça m'a semblé mieux que NX.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: NX

            Posté par  . Évalué à 3.

            Je confirme que le toolkit Oxygen est également inutilisable avec NX (j'utilise QtCurve qui marche très bien et qui a l'avantage d'avoir son équivalent pour Gtk).
            Avec NX, je suis également obligé de lancer KDE (ou toute application Qt) avec : QT_GRAPHICSSYSTEM=native
            Cela force les applis Qt à passer par X11 pour le rendu (au lieu de faire le rendu en interne et de filer les buffers à Xorg/NX ce qui fait saturer la liaison réseau).

            C'est également pour cette raison que je suis sceptique sur le fait d'avoir NX + Wayland (car si j'ai bien compris, dans Wayland, chaque application s'occupe du rendu de sa fenêtre et tout se fait en affichant des buffers graphiques).

            • [^] # Re: NX

              Posté par  . Évalué à 2.

              Ça dépend de ce que tu appelles NX + Wayland..

              Si c'est "les applis continue a appeler X et utiliser NX + XWayland pour l'accès distant à un bureau Wayland", je ne vois pas ou est le problème (enfin si je le vois, le proche futur où les devs GTK et Qt qui disent X11 c'est obsolète, on ne supporte plus).

              Si tu veux dire avoir l'équivalent de NX directement sur Wayland, en théorie non ça ne devrait pas bien marcher en WAN et faible BP, en pratique il faut voir ça peut dépendre des applis, des thèmes, de la méthode de compression utilisée..

          • [^] # Re: NX

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

            Pour NX, je teste presque toujours avec XFCE car j'avais remarqué qu'il charge bien moins que les autres (GNOME, KDE) et que pour mes utilisateurs lambda, il est pas trop geek ;-)

            Sinon, je fais souvent mes premiers tests avec nedit (motif) car il s'ouvre normalement instantanément, pas toutes ces merdes de dbus, gconf et autres pour éditer un fichier. Je trouve que c'est un bon cas test même si en pratique, il est de moins en moins utilisable en pratique car ne gérant pas l'UTF8.

            Avec XPra et Spice, j'avais lancé directement les applications nedit et firefox.

            J'ai fais cela il y a un mois environ… Je ne me souviens plus précisément du paramétrage exact. Je vais essayer de refaire des essais plus "scientifique".

            La liaison a un débit très variable mais rarement élevé. Par exemple, j'ai mis 30min la semaine dernière lors d'un apt-get install icetea ! Ca coupe aussi régulièrement 5, 10 30s… MOSH résiste très bien à ces coupures mais pas ssh. Du coup, x2go plante régulièrement alors que par exemple, xpra m'a semblé plus résistant (mais plus de latence).

            Bref, c'est vrai qu'il commence à y avoir plein de solution intéressante et qu'il faudra un jour une phase d'intégration / simplification.

            • [^] # Re: NX

              Posté par  . Évalué à 8.

              Par exemple, j'ai mis 30min la semaine dernière lors d'un apt-get install icetea !

              Quand on vous dit que Java c'est lent.

              « 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: NX

          Posté par  . Évalué à 3.

          D'ailleurs, je ne sais pas si Firefox a un greffon pour inter-connecter
          deux firefox distant ? Je veux que les requêtes soit réalisées sur la
          machine distante.

          Avec un proxy peut-être ?

          • [^] # Re: NX

            Posté par  . Évalué à 2.

            Tunnel ssh + l'extension foxy proxy firefox en proxy socks sur les tunnels.

            Et si la configuration et le maintien des tunnels ssh à la main est fastidieux, il y a gnome SSH Tunnel Manager (gstm): http://sourceforge.net/projects/gstm/

            Testé et approuvé.

            • [^] # Re: NX

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

              J'ai essayé le proxy sock ssh, le tunnel ssh vers un proxy squid interne… Rien n'a marché. Il s'agit d'aller sur des sites internes de l'université ayant une authentification shiboleth et il se perds dans un truc récursif. Je pense qu'il y a un soucis au niveau de la config du site web mais je n'ai pas la main sur les sites de la fac, et heureusement ;-) Ou alors, c'est la moulinette shiboleth qui foire… dans ce cas.

    • [^] # Re: NX

      Posté par  . Évalué à 6.

      Pour infos, qu'est-ce que tu appelle "très bas débit" ? Et pour les différents logiciels comparés, qu'elles étaient les paramètres (qualité, résolution…) ?

      Si on ne veut pas que des weberies, c'est important la transparence réseau, et qui marche !

      https://code.google.com/p/jsvnc/ :)

      « 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: NX

      Posté par  . Évalué à 3.

      Si on ne veut pas que des weberies, c'est important la transparence réseau, et qui marche !

      Je suis d'accord, mais la difficulté c'est que quand tu fais la combinatoire:
      (LAN ou WAN) * (client léger ou client lourd) * (machine distante normale ou machine distante type serveur sans carte graphique/carte graphique minimale), ça fait beaucoup de cas différent et les piles graphiques qui se comportent bien dans chacun des cas sont totalement différentes.

      La "solution" d'accès distant sur Wayland (envoyer les delta entre les images obtenues) devrait très bien fonctionner en LAN entre 2 machines puissantes peut-être même mieux que X, après dans les autres cas effectivement ça sera probablement pas terrible mais bon il reste X (XWayland) pour ces cas là..

    • [^] # Re: NX

      Posté par  . Évalué à 4.

      J'oubliais: Weston a une backend RDP donc il y a déjà la "transparence réseau" dans le monde Wayland en dehors de X, enfin si et seulement si tu utilise Weston bien sûr!
      Avec les compositeur Wayland de Gnome ou de KDE là..

  • # TRADUCTION

    Posté par  . Évalué à 1.

    Pour les détails je vous laisse consulter l'annonce officielle

    oui, j'aime encore mieux. Même si je ne suis pas très à l'aise avec l'anglais,
    je préfère la version originale plutôt qu'un :

    *la pile input a été REFACTORISÉE.
    *

Suivre le flux des commentaires

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