URL: https://linuxfr.org/users/tarnyko/journaux/waypipe-affichage-distant-natif-pour-wayland Title: waypipe, affichage distant natif pour Wayland Authors: Tarnyko Date: 2020年02月16日T14:03:34+01:00 License: CC By-SA Tags: wayland et x11 Score: 66 Coucou nal, Je viens de découvrir un projet GSoC qui n’a bizarrement pas eu beaucoup d’écho : **[waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe/)**. Si un reproche a fréquemment été fait à [Wayland](https://fr.wikipedia.org/wiki/Wayland) — comparativement à l’ancêtre [X11](https://fr.wikipedia.org/wiki/X_Window_System) — depuis le départ, c’est bien qu’il ne prend pas en charge la « [transparence réseau](https://doc.ubuntu-fr.org/tutoriel/xforwarding) » chère à nos cours d’université (et jamais utilisée en vrai ; non non, ne pas se lancer là‐dessus...). En effet, le protocole _!techpro!_ ne fournit pas de _sockets_ réseau, mais uniquement un _socket_ local permettant d’initier un canal de négociation de mémoire partagée _!/techpro!_. Il y a bien des solutions basées sur [RDP](https://fr.wikipedia.org/wiki/Remote_Desktop_Protocol) (voir [ici](https://linuxfr.org/users/tarnyko/journaux/wlfreerdp-un-client-wayland-pour-freerdp) ;-)) ou [VNC](https://fr.wikipedia.org/wiki/Virtual_Network_Computing), mais le reproche restait vu qu’il s’agissait d’autres protocoles établis et surtout que l’exportation était faite au niveau « bureau » — pas « fenêtre ». Voici donc ce que donne **waypipe** : ![Weston avec waypipe](http://www.tarnyko.net/repo/waypipe.png) J’utilise ici le compositeur _Weston_ et lance des applications Wayland pures (l’éditeur de texte _gedit_ et le lecteur vidéo _celluloid_) hébergées sur une machine distante via [SSH](https://fr.wikipedia.org/wiki/Secure_Shell). Concrètement, c’est aussi simple que de lancer `waypipe ssh (utilisateur)@(mdp) monprog` entre deux machines équipées du binaire `waypipe` dans leur `$PATH`. L’**[explication](https://mstoeckl.com/notes/gsoc/blog.html)** est un peu technique ; alors, en résumé : sur la machine distante, waypipe prétend être un compositeur et « sérialise » les messages Wayland vers un _socket_ réseau UNIX établi en collaboration avec le waypipe de la machine locale. Le reste est du classique :). Sont gérés : - la compression réseau (via [LZ4](https://lz4.github.io/lz4/)) ; - la redirection de tampons opaques Mesa (OpenGL notamment) via le couple GBM/DRM (fonction DMABUF), ce qui permet à des applications 3D telles [SuperTuxKart](https://linuxfr.org/users/andrianarivony/journaux/supertuxkart-1-1-est-arrive) de tourner ; - l’accélération de flux vidéo — non testée pour ma part — via le couple FFmpeg/[libVA](https://fr.wikipedia.org/wiki/Video_Acceleration_API). L’auteur fournit même une métrique : en désactivant la compression LZ4 et activant toutes les autres accélérations, un SuperTuxKart distant tourne à 40 images par seconde en consommant ~130 Mo/s de bande passante. _(Si l’on considère que la partie réseau « sérialisation/compression » qui est le vrai spécifique de waypipe fonctionne au niveau « buffer Wayland » plutôt que « compositeur complet » comme VNC/RDP, qu’elle est « auto‐contenue » — interne + LZ4 —, et que les autres dépendances — GBM, DRM et libVA — sont déjà trouvées dans les compositeurs tels Weston, on peut sans trop de problèmes dire que c’est natif)_ Je vous encourage à tester !