Il me semble qu'il y a deux camps en ce qui concerne le Raspberry Pi. Certaines personnes les utilisent comme de petits PC ou même des ordinateurs portables avec un clavier et un écran connectés. Mais beaucoup d'entre nous les utilisent comme serveurs Linux bon marché. Je suis dans ce dernier camp. J'ai probablement eu une prise HDMI dans un Pi seulement deux ou trois fois si vous ne comptez pas mes boîtes de streaming multimédia. Vous pouvez même les configurer sans tête tant que vous disposez d'un câble Ethernet ou que vous souhaitez modifier la carte SD avant de démarrer la machine pour la première fois.

Cependant, avec le Raspberry Pi 4, je voulais accéder à un bureau sans pêcher un moniteur de rechange. Je vais vous montrer deux façons d'obtenir un bureau graphique KDE complet avec rien de plus qu'une connexion réseau.

Le même principe s'applique à la plupart des autres environnements de bureau, mais j'utilise KDE et Ubuntu sur le Pi, même si quelque chose de plus léger fonctionnerait probablement mieux. Mais avant d'y arriver, parlons de la façon dont le X11 a connu une grande crise d'identité au fil des ans.

Le plan

Il existe de nombreuses façons d'accéder à distance aux programmes X, dont beaucoup sont rarement utilisés aujourd'hui. Cependant, à cette fin, nous allons utiliser le tunneling SSH avec quelques astuces spéciales pour faire fonctionner l'intégralité du bureau. Il est facile d'exécuter simplement un seul programme X sur SSH, et vous l'avez probablement fait souvent. Si c'est le cas, vous pouvez passer à la section suivante.

Si vous n'avez jamais fait de tunneling SSH auparavant, ne vous inquiétez pas; C'est facile. Quand tu commences ssh au Pi, il suffit d'inclure le -X ou -Y option. Vous pouvez également configurer cela dans le ssh fichier de configuration (ForwardX11 yes ou ForwardX11Trusted yes) afin que vous n'ayez pas à le saisir tout le temps. Les programmes SSH doivent également être configurés pour permettre cela, mais c'est généralement le comportement par défaut.

Considérez cette commande.

ssh -X me@mypi.local konsole &

Cela courrait konsole sur votre Pi, mais l'écran apparaît sur votre machine principale. C'est bien, mais ce n'est pas toute l'expérience de bureau. De plus, certains programmes attendent vraiment le support d'autres services qu'un environnement de bureau comme KDE démarre. L'astuce est donc de savoir comment démarrer le bureau?

The Tunneling Desktop

Si vous souhaitez démarrer une version moderne de KDE, vous pouvez exécuter startplasma-x11. La chose évidente à faire est d'essayer cela via une connexion SSH avec le transfert X. Cela ne fonctionnera pas, cependant. Votre écran est déjà géré par autre chose – peut-être même KDE.

L'astuce consiste à créer un nouveau serveur X uniquement pour le Raspberry Pi. Bien que vous puissiez démarrer un nouveau serveur, il est plus facile de créer un faux serveur qui vit dans une fenêtre sur l'écran de votre serveur principal. Il y a deux façons de faire ça: Xnest et Xephyr. Xnest est très ancien et crée un serveur simple avec très peu de fonctionnalités. Cela dépend du serveur hôte X pour la plupart des fonctions. Xephyr est plus moderne. Il offre de nombreuses fonctionnalités modernes, quel que soit le serveur hôte. Il utilise essentiellement le serveur hôte comme tampon de trame.

Bien sûr, tout cela suppose que le bureau KDE soit installé sur le Pi. Un simple apt install pour kubuntu-desktop s'en occupera si vous ne l'avez pas déjà fait.

Utilisation de XNest

L'astuce pour XNest est qu'il crée un nouveau serveur qui se trouve juste s'appuyer sur le serveur d'origine – ils sont imbriqués. Il existe de nombreuses options, mais généralement, il suffit d'exécuter le programme avec un nouveau numéro d'affichage (inutilisé).

Xnest :11

Notez que le premier X est en majuscule. Vous voudrez peut-être définir la taille:

Xnest --geometry 800x600 :11

Vous pouvez l'exécuter sur votre machine locale ou à partir du Pi. Tant que le tunneling X est défini sur votre connexion SSH, cela n'a pas d'importance. Mais il y a toujours un problème.

Essayez de courir:

DISPLAY=:11 startplasma-x11

Très probablement, cela commencera quelques choses et semblera fonctionner. Mais à un moment donné, vous obtiendrez une erreur fatale et rien ne se passera. Le problème tourne autour de la tentative de rendu sur le GPU distant. Ce n'est peut-être pas un problème avec certains bureaux légers, mais KDE s'arrête.

L'astuce est que vous devez définir une variable d'environnement pour dire à Qt de ne pas essayer de faire le rendu matériel:

QMLSCENE_DEVICE=softwarecontext startplasma-x11

Cela fait l'affaire et maintenant vous pouvez avoir un bureau KDE complet exécuté sur le Pi et affiché sur votre moniteur principal! Vous ne voudrez pas regarder des vidéos dessus ou jouer à des jeux, mais sinon, il est parfaitement utilisable.

J'ai tout enveloppé dans un script:

#!/bin/bash
Xnest -geometry 3840x2050 :2 &
export QMLSCENE_DEVICE=softwarecontext
DISPLAY=:2 startplasma-x11 &

Ou un peu plus chic:

#!/bin/bash
X="${1:-1024}"
Y="${2:-768}"
S="${3:2}"
Xnest -geometry ${X}x${Y} :$S &
export QMLSCENE_DEVICE=softwarecontext 
DISPLAY=:$S startplasma-x11 &

Utiliser Xephyr

Xephyr n'est généralement pas installé et vous devrez peut-être rechercher de quel package il s'agit sur votre système d'exploitation. Pour Ubuntu, le package est xserver-xephyr. Pour une raison quelconque, son exécution sur le Pi a simplement provoqué le blocage du programme et n'a rien fait – du moins sur ma configuration. Cependant, en théorie, vous devriez pouvoir l'utiliser en remplacement de Xnest.

À la place, j'ai créé le serveur sur ma machine locale, puis demandé au Pi de l'utiliser. Donc:

 
Xephyr :1 -screen 1200x720 -resizeable &
DISPLAY=:1 ssh -X ubuntu@192.168.1.39 "QMLSCENE_DEVICE=softwarecontext startplasma-x11" &

Cela fonctionne, mais c'est très lent. Xephyr fait beaucoup de travail seul, donc le Xnest la solution est plus rapide.

Le X qui était

Lorsque X11 a commencé, il avait un grand plan. Depuis votre écran de connexion, vous devriez pouvoir vous connecter à n'importe quel ordinateur auquel vous avez accès. Ensuite, vous devriez pouvoir exécuter des programmes sur votre écran depuis n'importe quel ordinateur, pas seulement celui que vous utilisiez comme ordinateur principal. Cela fonctionne toujours, en quelque sorte. Cependant, la plupart des distributions Linux ne sont pas vraiment configurées pour en tirer pleinement parti.

L'astuce pour savoir comment les choses étaient censées être est la variable DISPLAY. Cela définit où les clients X (programmes) se connectent à un serveur X (votre écran). Vous pouvez définir cela comme étant distant. Par exemple:

DISPLAY=mydesktop.local:0 konsole

En théorie, cela devrait avoir à peu près le même effet, mais cela suppose que votre réseau est ouvert sur les ports autour de 9000 et que votre Xserver est ouvert ou qu'un schéma d'authentification par les pairs est configuré.

En fait, vous pouvez prendre de nombreux messages d'accueil (le programme auquel vous donnez votre nom d'utilisateur et votre mot de passe) et les reconfigurer pour écouter les connexions réseau et créer des connexions réseau vers d'autres machines, tout comme le souhaitaient les concepteurs X11. Mais la plupart des distributions ont désactivé cette fonctionnalité et je ne sais même pas si certains des nouveaux messages d'accueil proposent cette option.

Dans une utilisation moderne, le système X11 est devenu un pilote de quasi-affichage pour votre moniteur, et c'est triste. X a tellement de capacités qu’environ 90% du monde Linux n’utilisent pas. (Rappelant que 88,35% de toutes les statistiques sont faites sur place.)

Si vous voulez essayer de le configurer à l'ancienne, jetez un œil à xhost, xauthet préparez-vous à modifier le démarrage de votre serveur X pour supprimer l'indicateur qui l'empêche d'écouter les sockets TCP. Ça peut être fait. Bien sûr, la sécurité sur le réseau n'est peut-être pas ce que vous voulez. Le tunneling sur SSH résout cela en une seule ligne, cependant.

La solution

Même après tout ce travail, je vais toujours me connecter à mon Pi à partir de la ligne de commande pour la plupart des travaux. Je pourrais inclure le transfert X11 afin que je puisse exécuter le programme étrange sur mon bureau. Cependant, pour les moments où vous voulez vraiment travailler avec l'ensemble du bureau, le Xnest solution fonctionne assez bien. Xephyr était lent. Je ne sais pas si cela aurait été plus rapide s'il avait fonctionné sur le Pi, mais cela n'a jamais fonctionné pour moi. Je soupçonne qu'il s'agit d'une interaction avec les pilotes d'affichage NVidia, mais je ne l'ai pas retrouvé.

En attendant, si vous essayez cela, pensez à agrandir la fenêtre et à la garer sur un bureau virtuel. Il s'agit d'une solution intéressante, car vous pouvez retourner les ordinateurs de bureau pour accéder au Pi ou à votre ordinateur normal. Ajoutez un autre bureau avec VirtualBox exécutant Windows et vous avez le système d'exploitation trifecta. Si vous utilisez Wayland, cela peut toujours fonctionner avec Xwayland, mais je ne l'ai pas testé.

Si vous voulez vraiment remplacer votre bureau par un Pi, vous voudrez peut-être envisager cet essai. Ou peut-être préféreriez-vous un ordinateur portable.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici