Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Novembre 2020 -
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… 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 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 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 :
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 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 :
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) :
# 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 :
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.
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.
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 :
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…
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
Commentaires :
voir le flux Atom
ouvrir dans le navigateur
