Journal wlfreerdp: un client Wayland pour FreeRDP

Posté par (page perso) . Licence CC by-sa
Tags :
34
13
oct.
2014

Cher journal,

Je viens d'implémenter un client Wayland pour FreeRDP.

Comme tu le sais peut-être, RDP (ou Remote Desktop Protocol) est un protocole d'accès distant plus performant que VNC et consorts. Il est notamment implémenté par un serveur X intégré à FreeRDP (xfreerdp-server) et le compositeur RDP de Weston.

Nous avions des clients X11, Android, Mac OS X, Windows… mais une version pure Wayland, ne nécessitant pas XWayland, manquait ! Alors bien sûr, ce n'est qu'un visionneur pour l'instant, mais je prévois de gérer les entrées bientôt :-) !

Voic la pull request et une vidéo (Weston vers Weston), !

PS : personnellement, je ne builde pas la dernière version mais une ancienne qui marche bien pour moi, en voici la branche.

  • # Roue libre

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

    wlfreerdp, ça fait un peu RDP en roue libre (free wheel, wheel free, wl free…). Voilà, désolé pour ce commentaire pas très intéressant.

    • [^] # Re: Roue libre

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

      Y a pas de problème :-), de toute façon on n'y peut pas grand-chose car le nom était plus ou moins "forcé" (xfreerdp pour X11, wfreerdp pour Windows…). Mais je peut garantir que je maintiendrai ce code et qu'il ne partira pas en roue libre !

  • # FreeRDS

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

    C'est donc compatible avec FreeRDS ?

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: FreeRDS

      Posté par (page perso) . Évalué à 4. Dernière modification le 13/10/14 à 15:14.

      Je viens de discuter avec les gens de FreeRDS, cela devrait. Cependant j'avoue n'avoir testé que le compositeur RDP de Weston pour l'instant (je ne sais pas builder ni utiliser FreeRDS). Un retour là-dessus serait donc utile.

  • # un troll de moins ?

    Posté par . Évalué à 2.

    Si j'ai bien compris, le troll « Xorg au moins fonctionne en réseau, pas wayland » est mort et enterré, c'est plutôt une bonne nouvelle :)

    • [^] # Re: un troll de moins ?

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

      Pas sûr, avec X11 on peut ne déporter qu'une ou plusieurs fenêtres, ce qui est super parce que ça permet par conséquent de déporter un bureau entier si on veut. Reste à voir si c'est possible avec Wayland et RDP, je demande à voir.

      • [^] # Re: un troll de moins ?

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

        C'est techniquement possible, mais nécessite du travail dans le compositeur RDP. En gros, il faut y tracker les fenêtres. Je vois comment faire, mais doute avoir le temps durant les prochains semaines.

        En attendant, une solution de contournement est d'utiliser ce hack. La mise en place est plus lourde, mais le résultat visuel proche.

      • [^] # Re: un troll de moins ?

        Posté par . Évalué à 3.

        avec X11 on peut ne déporter qu'une ou plusieurs fenêtres

        C'est ce qui ce passe quand on fait un ssh -X user@host <command> ?

        kentoc'h mervel eget bezan saotred

        • [^] # Re: un troll de moins ?

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

          Oui, entre autres. ssh -X, ça fait plusieurs choses en fait :

          1. ça transfère le socket du serveur X du poste client SSH /tmp/.X11-unix/X$n, où $n est le numéro du $DISPLAY sur un socket créé pour l'occasion sur le poste serveur SSH sous le nom /tmp/.X11-unix/X$m, où $m est un numéro choisi pour ne pas créer de collision ;
          2. ça exporte dans le shell distant la variable DISPLAY=:$m ;
          3. ça exporte dans le shell distant le cookie d'identification X11, avec xauth (pas envie de détailler ça, vous pouvez regarder les pages de manuel et regarder ce que donne xauth list sur les deux postes).

          Ainsi :

          • les logiciels clients X lancés dans le shell distant essaieront de causer avec le serveur X correspondant à ce DISPLAY=:$m, c'est à dire un serveur prétendument local au poste serveur SSH, accessible sur le socket Unix /tmp/.X11-unix/X$m ;
          • leurs requêtes à ce socket Unix sont transférés par SSH au socket Unix du serveur X du poste client SSH /tmp/.X11-unix/X$n ;
          • ces requêtes sont donc traitées par le serveur X du poste client SSH.

          À noter que, si OpenSSH est capable de faire des transferts de ports TCP et UDP arbitraires, il est en revanche codé pour ne pouvoir transférer en matière de sockets Unix que ceux dont le chemin correspond à ceux utilisés dans le cadre du système X11.

          • [^] # Re: un troll de moins ?

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

            À noter également, que le déport d'affichage X11 par SSH n'utilise pas la « transparence » réseau d'X11, puisque, pour les clients X11 comme pour le serveur, toutes les requêtes ont lieu sur socket Unix.

            Ceci m'amène à la question suivante : si avec Wayland, la communication entre le serveur Wayland et les clients Wayland se fait par socket Unix (je n'arrive pas à imaginer comment il pourrait en être autrement), faire du déport d'affichage par réseau pourrait se faire de la même façon, avec SSH ou autre chose transférant tout ça par réseau pour exposer sur un autre poste un socket Wayland utilisable ?

          • [^] # Re: un troll de moins ?

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

            À noter que, si OpenSSH est capable de faire des transferts de ports TCP et UDP arbitraires, il est en revanche codé pour ne pouvoir transférer en matière de sockets Unix que ceux dont le chemin correspond à ceux utilisés dans le cadre du système X11

            Le transfert de socket est dans la dernière version de ssh qui est sorti la semaine dernière ;-)

            Ceci dis, ils auraient du intégré à ssh la session NX afin de pouvoir utiliser le protocole NX comme avec x2goclient…

            • [^] # Re: un troll de moins ?

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

              Le transfert de socket est dans la dernière version de ssh qui est sorti la semaine dernière ;-)

              Ah tiens, curieux, la dernière fois que j'avais parlé de ça, sur IRC ou sur ML, je ne sais plus, on m'avait répondu que pour X ils n'avaient pas vraiment le choix mais que même ça, ils auraient préféré l'éviter.

              Bref, c'est chouette, ça permettra de pouvoir faire des trucs comme du transfert de son avec PulseAudio par exemple.

              • [^] # Re: un troll de moins ?

                Posté par . Évalué à 2.

                Le transfert de son avec pulseaudio, c'est… de la mémoire partagée :).
                Tu remarqueras une tendance lourde vers le zero-copy chez les softs systèmes récents, et c'est normal.

                Bon, dans le cas de pulse audio je troll un peu : tu peux faire passer les données sur le fil. En même temps, pulse propose nativement un protocole réseau !

            • [^] # Re: un troll de moins ?

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

              Alors ça c'est chic, on va avoir des notifications sur le bureau pour le client IRC, le client mail… voire, on pourra afficher localement (avec l'application Xorg un fichier distant)…

    • [^] # Re: un troll de moins ?

      Posté par . Évalué à 2.

      Un troll?

      Pas vraiment non: à l'heure actuelle pour avoir le déport d'écran avec Wayland il faut que le compositeur le supporte ce qui est loin d'être toujours le cas! Avec X, dans la majorité des cas ça fonctionnait sans problème, avec Wayland c'est optionnel (et immature).

      En plus, par conception le déport d'écran Wayland est en théorie moins efficace qu'avec X (puisqu'avec X on peut envoyer des buffers comme Wayland mais pas l'inverse: on ne peut pas dire affiche moi une ligne avec Wayland), là c'est effectivement plus discutable car la qualité de l'implémentation l'emporte souvent sur des avantages "théoriques".

      • [^] # Re: un troll de moins ?

        Posté par . Évalué à 4. Dernière modification le 15/10/14 à 17:52.

        En plus, par conception le déport d'écran Wayland est en théorie moins efficace qu'avec X (puisqu'avec X on peut envoyer des buffers comme Wayland mais pas l'inverse: on ne peut pas dire affiche moi une ligne avec Wayland),

        On n'utilise plus du tout les commandes du genre "fais moi une ligne" dans Xorg. Ça fait longtemps que X est network capable et non pas network transparent.

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

        • [^] # Re: un troll de moins ?

          Posté par . Évalué à 1.

          Merci je sais. Mais pour qu'un serveur X soit un serveur X il doit supporter tout le protocole même si les toolkit modernes ne s'en servent plus.
          Dessiner une ligne a peu d'intérêt mais avec X tu peux cacher les lettres côté serveur d'affichage ce qui permet d'afficher du texte avec une utilisation de bande passante réduite (la plupart du temps, ça peut dépendre du rendu).

          Donc en théorie X peut avoir des avantages en efficacité sur Wayland en distant pour comparer en pratique il va falloir attendre que Wayland devienne mature..

          PS: je sais bien que tout nouveau tout beau, mais je ne comprends pas pourquoi le poste précédent a été moinsser..

          • [^] # Re: un troll de moins ?

            Posté par . Évalué à 3.

            Donc en théorie X peut avoir des avantages en efficacité sur Wayland en distant pour comparer en pratique il va falloir attendre que Wayland devienne mature..

            En théorie tellement théorique que ça n'a aucun intérêt alors. Ce n'est pas que les toolkits qui n'utilisent plus ces commandes, c'est Xorg lui-même (voir les liens ci-dessus) en utilisant constamment le direct rendering.

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

  • # Plus clairement ?

    Posté par . Évalué à 5.

    Je suis très intéressé par tout ce qui touche à Wayland et le réseau (j'ai pas mal de terminaux X sur des serveurs LTSP), mais je suis un peu largué par le journal.

    Si je devine entre les lignes, Weston propose maintenant un export en RDP ? Est-ce qu'il est fonctionnellement similaire à ce que l'on fait avec X ? Est-ce que je vais pouvoir connecter plusieurs terminaux sur un même serveur, chacun (chaque utilisateur) ayant son propre bureau ?

    Les questions bonus: Est-ce que l'audio est pris en charge ? Est-ce que le stockage local est pris en charge ?

    • [^] # Re: Plus clairement ?

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

      Weston propose maintenant un export en RDP ?

      C'est disponible depuis longtemps. Cette page et cette vidéo pourront te renseigner.

      Le journal parle de la création d'un client Wayland ; c'est-à-dire, un "visualiseur" qui lui tourne sur Wayland à l'instar des versions X11, Android…

      Est-ce que je vais pouvoir connecter plusieurs terminaux sur un même serveur, chacun (chaque utilisateur) ayant son propre bureau ?

      Oui. Il faut démarrer un compositeur par utilisateur.

      Les questions bonus: Est-ce que l'audio est pris en charge ? Est-ce que le stockage local est pris en charge ?

      Avec le compositeur RDP de Weston, non. Avec FreeRDS, peut⁻être, mais cela nécessite des informations (voir ci-dessus).

  • # Clavier GNU/Linux vs Windows en RDP

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

    Le souci avec RDP, c'est la gestion du clavier. Si on se connecte à un serveur TSE sous Windows depuis un poste client sous GNU/Linux, le clavier est géré par GNU/Linux et les ennuis commencent quand on travaille sur sa session Windows TSE : gestion des majuscules différentes de Windows, plus d'accès aux codes ASCII (ALT+code ASCII) bien utiles pour écrire certains symboles comme "diamètre" etc.
    Je n'ai jamais trouvé de solution qui marche correctement. Il y a 2 logiciels pour émuler le clavier GNU/Linux sur un serveur Windows mais ils ne marchent pas bien en TSE.

    • [^] # Re: Clavier GNU/Linux vs Windows en RDP

      Posté par . Évalué à 0. Dernière modification le 14/10/14 à 07:55.

      ALT+code ASCII

      Mouhahaha ça existe encore ce truc de grand père ?
      Essaye de faire CTRL+ALT+u puis le code Unicode (2300 pour le diamètre ⌀) pour passer à la vitesse supérieure ou entrer dans le 21e siècle à toi de voir :-D

      kentoc'h mervel eget bezan saotred

      • [^] # Re: Clavier GNU/Linux vs Windows en RDP

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

        pour passer à la vitesse supérieure ou entrer dans le 21e siècle

        Il faut qu'il atteigne les quatre-vingt-huit miles à l'heure, pour pouvoir entrer dans le 21e siècle.

      • [^] # Re: Clavier GNU/Linux vs Windows en RDP

        Posté par . Évalué à 5.

        Tu ne voulais pas dire CTRL+SHIFT+u plutôt ?
        cf : http://en.wikipedia.org/wiki/Unicode_input#In_X11_.28Linux_and_other_Unix_variants.29

        Merci pour l'astuce en tout cas, je ne connaissais pas :)

        • [^] # Re: Clavier GNU/Linux vs Windows en RDP

          Posté par . Évalué à 1.

          Tu ne voulais pas dire CTRL+SHIFT+u plutôt

          J'ai honte, ça m'apprendra à poster des messages aux aurores.
          Et dire que j'ai fait la manip pour mettre le symbole ⌀, franchement il y a des fois ou je ☢☠

          Du coup j'en profite pour passer un lien sympa pour trouver des symboles unicodes

          Merci pour l'astuce en tout cas, je ne connaissais pas :)

          Ce fut un plaisir. ☺

          kentoc'h mervel eget bezan saotred

      • [^] # Re: Clavier GNU/Linux vs Windows en RDP

        Posté par . Évalué à 4. Dernière modification le 14/10/14 à 14:26.

        Non seulement ça existe encore, mais ça fait plus souffrir aujourd'hui qu'à l'époque. Essai un rdp depuis un xp vers une "tty locale" présentée par Vsphère en passant par un serveur 2003.
        Tu souffres ;
        Tu maudis l'admin windows ;
        Tu maudis microsoft jusqu'à la 15è lignée de ballmer et gates ;
        Tu pestes contre vmware.

        Au final, il te faut : connaitre les codes tel que 124 pour le pîpe, anticiper que pour d'autres caractères tu peux les échapper en plus ( \$ = ctrl puis ton dollars) et tout ça de manière un peu aléatoire. Ben oui, si ça fonctionnait vraiment on serait juste obligé d'apprendre 50 trucs inutiles, mais en plus il faut compter avec la désatreuse gestion de la pile du copier/coller, qui part en vrille sur rdp dès que tu l'utilises dans excell localement. Et qui aussi, d'autres fois, t'obliges à cliquer sur ton desktop local, et au pire à relancer la connection rdp. Ajoute ça quelques problèmes du client Vsphère, qui a tendance a de temps temps déchargé sa pile comme un étudiant un soir de première cuite (tape un "a" et un seul "a", il fait : aaaaaaaaaa).

        Technologie Microsoft à 100% ;
        Merveilleux.
        Au final tu obtiens un ensemble dans lequel tu n'as aucune confiance.

        Avec X11 y a pas le son, et y a besoin d'un plus gros tuyaux, mais qu'est ce que ça marche bien !
        Et avec SSH + X11, j'aime bien un ssh -X login@machin :display Xnest -query localhost.

        • [^] # Re: Clavier GNU/Linux vs Windows en RDP

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

          Avec X11 y a pas le son, et y a besoin d'un plus gros tuyaux, mais qu'est ce que ça marche bien !

          Maintenant qu'on peut faire du transfert de PulseAudio par SSH, si. Et pour les imprimantes, on pourrait faire pareil si les clients CUPS pouvaient utiliser une variable d'environnement pour déterminer où trouver le serveur CUPS, mais ça n'a malheureusement pas l'air d'être le cas.

        • [^] # Re: Clavier GNU/Linux vs Windows en RDP

          Posté par . Évalué à 5.

          Tu souffres ;
          Tu maudis l'admin windows ;
          Tu maudis microsoft jusqu'à la 15è lignée de ballmer et gates ;
          Technologie Microsoft à 100% ;
          Merveilleux.
          Au final tu obtiens un ensemble dans lequel tu n'as aucune confiance.

          Avant j'étais heureux et épanoui avec Linux, maintenant c'est encore mieux :-D

          kentoc'h mervel eget bezan saotred

Suivre le flux des commentaires

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