URL: https://linuxfr.org/users/pepp/journaux/ecran-deporte-et-wayland Title: Écran déporté et Wayland Authors: pepp Date: 2020年11月02日T22:57:01+01:00 License: CC By-SA Tags: jitsi, libreoffice et firefox Score: 59 J'ai récemment aidé à mettre en place un système basique de visioconférence qui ensuite a dérivé sur une expérimentation Wayland et écran déporté - je me suis dit que ça pouvait intéresser d'autres personnes. Le système de visioconf est basé sur un mini-PC (Intel Atom, 2go de RAM) avec clavier/souris sans-fil, une webcam (pour l'image et le son), une TV pas smart, [Jitsi](https://meet.jit.si/)... et c'est tout. L'installation est basique : une Fedora, Weston comme compositeur, `gdm` en auto-login et une icone dans le `launcher` pour démarrer Firefox sur la bonne url. J'ai aussi testé rapidement le [kiosk-shell](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/416) de Weston qui permet d'automatiquement afficher en plein écran l'application lancée, mais ça n'apporte pas grand chose donc pour l'instant je reste sur le `desktop-shell`. Cette solution permet à des personnes de participer aux réunions sans devoir se rendre sur place pour un coût minimum et une utilisation simple et autonome. Objectif atteint. Passée cette étape, je me suis dis qu'il était dommage d'avoir un grand écran et de ne pas afficher des documents dessus pendant les réunions. La solution facile d'utiliser un câble hdmi fonctionne parfaitement... mais il se trouve que parmi les utilisateurs récurrents il y en a 1 qui a Linux sur sa machine. J'ai donc cherché comment afficher un document de ce PC sur la TV, via le mini-PC en utilisant la connexion réseau au lieu du câble parce que...euh... pourquoi pas ? Les 2 machines utilisent un compositeur Wayland (gnome-shell pour la première, et donc Weston pour celle connectée à la TV). Après quelques recherches et m'être demandé si j'allais me résigner à tester un Chromecast, j'ai trouvé le logiciel [waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe) dont j'avais déjà entendu parlé, mais que j'avais oublié. Le fonctionnement est très proche d'un `ssh -X` : il permet d'afficher sur un ordinateur une application démarrée sur un autre. Par exemple la commande suivante, lancée depuis l'ordinateur A : ```sh waypipe ssh alice@ordinateurB mon-application ``` va se connecter en tant que `alice` sur l'ordinateur B, démarrer `mon-application` et l'afficher sur l'écran de ordinateur A. Le fonctionnement est détaillé sur le [blog de l'auteur](https://mstoeckl.com/notes/gsoc/blog.html) mais l'idée générale peut-être résumée comme ceci : * sur ordinateur A : - `waypipe` est vu par le compositeur Wayland comme une application normale * sur ordinateur B : - `waypipe` est vu comme un compositeur Wayland par l'application * sur les 2 ordinateurs : - `waypipe` discute avec une socket Unix (par ex les messages du protocoles Wayland, les entrées/sorties, etc) - une connexion ssh est active et sert à relier ces deux sockets Unix (`[waypipeA <-> socket A] <- ssh -> [socket B <-> waypipeB]`) En image ça ressemble à ça : ![Une image pour faire joli](https://mstoeckl.com/notes/gsoc/processes.svg) Ces étapes sont visibles si on utilise la commande explicite indiquée dans le Readme (ces commandes sont lancées depuis l'ordinateur A, celui qui veut afficher l'application) : ```sh # on lance waypipe sur l'ordinateur A, il va utiliser /tmp/socket-local waypipe -s /tmp/socket-local client & # on se connecte sur B (ssh user@theserver) # on lance l'application "dans" waypipe (waypipe server -- mon-application) # et ssh relie /tmp/socket-remote et /tmp/socket-local (via l'option -R) ssh -R /tmp/socket-remote:/tmp/socket-local -t user@theserver \ waypipe -s /tmp/socket-remote server -- \ mon-application ``` Tout ça marche très bien, sauf que c'est l'inverse que je veux : je veux démarrer une application sur l'ordinateur de l'utilisateur mais que l'affichage soit déporté sur la celui branché sur la TV. C'est possible, il suffit de bricoler un peu les commandes. Elles seront lancées depuis l'ordinateur de l'utilisateur : ```sh ssh -L /tmp/socket-remote:/tmp/socket-local -t user@theserver \ WAYLAND_DISPLAY=wayland-0 waypipe -s /tmp/socket-local client waypipe -s /tmp/socket-remote server -- mon-application ``` Avec ça, on peut ouvrir un pdf d'une présentation et l'afficher en grand sur la TV, victoire ! Enfin... à un détail près : on ne peut plus contrôler l'application, puisqu'elle traite maintenant les clics et événements claviers de l'ordinateur connecté à la TV. J'ai dit plus haut que celui-ci dispose d'un clavier sans-fil, mais là aussi, ça serait bien de pouvoir se passer de manipulations de matériel. Et ça tombe bien, j'utilise déjà un autre logiciel pour le même besoin : [netevent](https://github.com/Blub/netevent). Il est très simple et fonctionne parfaitement : lancé sur 2 machines, avec là encore un tunnel ssh pour les données, il va lire les événements clavier/souris d'un côté (via `/dev/uinput`) et les écrire de l'autre. Il est compatible Wayland, X11 ou n'importe quoi d'autre qui fonctionne sous Linux et qui support `uinput`. ```sh netevent daemon -s config.ne2 netevent-command.sock ``` Le fichier `config.ne2` décrit quels périphériques partager, la machine avec laquelle on veut les partager et une touche de "bascule". Par exemple, sur mon clavier j'ai configuré la touche `Pause` pour basculer : un appui sur cette touche et mon clavier/souris sont "connectés" à l'autre machine. Un nouvel appui et ils reviennent sur ma machine. C'est très pratique quand on utilise plusieurs machines en même temps et la bascule est instantanée (contrairement au hub USB de mon écran qui a besoin de 34 sec pour la même opération). Donc, avec `waypipe` + `netevent` on arrive à afficher et contrôler une application à distance. Pour simplifier l'utilisation il faudrait maintenant avoir une commande `affiche-sur-la-TV mon_fichier` qui lance automatiquement `waypipe`, `netevent` et la *bonne* application (Firefox pour une url, evince pour un pdf, LibreOffice pour les odt, etc). Yaka utiliser quelque chose comme la commande ci-dessous, pensais-je naïvement : ```sh waypipe -s /tmp/socket-remote server -- GDK_BACKEND=wayland gio open mon_fichier ``` Mais non, ça ne marche pas, l'application persiste à vouloir s'afficher sur la mauvaise machine. Je suppose qu'il y a une mésentente entre `gio open` et `waypipe` sur la valeur correcte à donner à WAYLAND_DISPLAY. Pas grave, si `gio open` sait trouver la bonne application pour ouvrir un fichier, c'est que l'information doit être disponible *quelque part*... Je laisse la recherche de ce *quelque part* aux lecteurs curieux (dans mon cas j'ai fini par utiliser : `file --mime-type`, `gio mime` et `Gio.DesktopAppInfo` via python, si quelqu'un a plus direct je suis preneur :)). En mettant tout ça bout à bout on obtient un script de 60 lignes de Bash, avec du `python3 -c "$un_bout_de_python"` dedans et qui dépend de 2 logiciels pas vraiment 100% production-ready... pour éviter d'utiliser un câble hdmi de 3m. Dis comme ça, on a l'impression que c'était une perte de temps alors que pas du tout...enfin... ![Une autre image pour faire joli, il est joli mon thème non ?](https://i.paste.pics/AKN17.png) L'objectif de l'expérimentation est atteint : en une commande je peux afficher un fichier sur un autre écran, sans câble entre les 2. Les performances sont bonnes et la consommation CPU est minime, en tout cas pour mon besoin puisque j'affiche principalement du contenu statique. En Wifi ça marche bien aussi, même si `netevent` est moins fluide - je n'ai pas creusé plus que ça, je verrai en pratique si c'est gênant. Ah, et il reste une étape pour que ce soit *parfait* : une extension Nautilus pour pouvoir faire "clic-droit -> envoyer sur la TV", mais ça sera pour plus tard :-) PS : oui, on ne voit pas le code pour l'image, c'est juste pour ajouter un peu de couleurs à l'article :-) PPS : oui, je mettrai le script en ligne quelque part bientôt

AltStyle によって変換されたページ (->オリジナル) /