Utiliser la Raspberry en mode Kiosk

Le mode kiosk (ou borne) consiste à dédier l’affichage graphique à l’usage exclusif d’une application, et de plus sans faire apparaître les habituels éléments du bureau graphique (panel, icones,...).

Parmi les exemples les plus couramment rencontrés : les distributeurs de billets, les affichages d’horaires dans les (aéro)gares,...

Plusieurs aspects sont à prendre en compte pour configurer la Raspberry de cette manière, et nous allons les détailler.

Scénario et contexte

Le scénario utilisé pour l’exemple consiste à utiliser le navigateur Midori pré-installé pour se connecter à une application Web qui implémente les fonctionnalités de notre borne. C’est identique pour une application desktop écrite avec Qt ou toute autre option.

La distribution utilisée est une Raspbian installé depuis une SD Noobs. L’environnement graphique est LXDE, sélectionné par défaut sur la Raspbian lorsqu’on la démarre en mode desktop.

Lancement automatique de l’environnement graphique customisé

Tout se passe dans le fichier d’initalisation de LXDE, en l’occurrence /etc/xdg/lxsession/LXDE/autostart.

Son contenu par défaut est :

@lxpanel --profile LXDE 
@pcmanfm --desktop --profile LXDE
@xscreensaver -no-splash

En détail, cela signifie :

• lancer lxpanel qui se charge d’affficher.. les panels
• lancer le file manager pcmanfm qui va se charger d’afficher et de gérer les divers icones de navigation dans votre système
• lancer l’économiseur d’écran xscreensaver

Le "@" en début de ligne signifie que si la commande est en erreur, elle n’interrompt pas le script. Je précise ce "détail" car il m’a valu la perte de plusieurs heures et d’un paquet de neurones pour comprendre pourquoi les choses ne marchaient pas comme je le voulais. Nous en reparlerons plus loin.

Dans notre cas de figure, nous ne voulons rien de tout cela (rappelez-vous, l’appli utilise tout l’écran et on ne veut pas voir apparaître les habituels décorations et occupants du bureau graphique). Et nous ne voulons surtout pas d’économiseur d’écran, car un panneau d’affichage n’ayant pas de périphérique d’interaction utilisateur, on ne risque pas de pouvoir réactiver l’écran si l’économiseur entre en action.

Conclusion, on supprime tout cela (en gardant une copie de l’original quelque part quand même, ou en mettant les lignes en commentaire avec l’habituel "#" en tête).

A la place nous allons y mettre tout simplement la commande de lancement de notre application, soit :

@midori -e Fullscreen -a http://url/de/mon/application/web

Les options utilisées sont :

• -e qui permet l’exécution d’une commande Midori, soit la commande Fullscreen qui passe Midori en mode plein écran. Ce mode fait en sorte que le contenu des pages occupe toute la surface de l’écran, ce qui est différent de maximiser la fenêtre du navigateur, qui laisse encore apparaître les éléments d’IHM de l’application.
  Pour connaître toutes les commandes disponibles, utilisez la commande "midori —help-execute". Si vous le faites depuis ssh, il faudra donner un display X, même si la commande affiche sa sortie sur la console. Dans ce cas, ajoutez l’option "—display :0" à la commande [1]
• -a ... c’est tout simplement l’adresse où on veut naviguer

On aurait pu se passer du "@" ici, la commande étant la seule du script (et en tout cas la dernière).

C’est tout ?

Pas vraiment.

Si vous enregistrez ce fichier et que vous rebootez la RasPi, tout va très bien se passer, l’environnement graphique va se lancer, avec l’appli Web occupant tout l’écran comme voulu.

Ben alors, c’est terminé donc.

Attendez une dizaine de minutes... Tout d’un coup, écran noir. Rassurez-vous, la Raspberry n’est pas plantée, et il suffit de se connecter en ssh dessus pour le vérifier. Et pourtant il n’y a pas d’économiseur d’écran, puisqu’on a retiré son lancement du script autostart.

Oui, mais il reste le DPMS

DPMS ? Késaco ?

DPMS : Display Power Management System. En d’autres termes, le gestionnaire du mode économie d’énergie, qui coupe la vidéo au bout de 10 minutes environ par défaut, de telle sorte que le moniteur passe en mode veille, car ne recevant plus de signal vidéo.

Et comment on s’en débarrasse ?

Simple : en ajoutant les lignes suivantes dans le fichier autostart, avant le lancement de Midori :

@xset -dpms
@xset s off

xset est un utilitaire du server X qui permet d’en configurer un grand nombre d’aspects. Ici, on l’utilise pour respectivement :

• désactiver le DPMS
• désactiver le screensaver

Mais au fait, pourquoi on désactive le screensaver puisqu’on l’a supprimé de l’autostart ? En fait, xscreensaver (notez le "x" en tête) est un screensaver "décoratif", du genre qui affiche des jolis graphismes animés sur votre écran (ce n’est rien d’autre qu’une appli qui s’arroge la totalité du display pour faire ses gribouillis). Le screensaver dont il est question ici est un dispositif beaucoup plus bas niveau et qui fait partie de la gestion de l’énergie au niveau du serveur X.

A noter que pas mal de recettes disponibles sur le Web ajoutent l’instruction "xset s noblank". Cette commande configure X pour ne pas utiliser le signal blank video mais d’afficher un pattern graphique à la place lorsque le screensaver entre en action. Sauf qu’ici cela n’a aucune utilité puisqu’on l’a désactivé. J’ai pu vérifier que le fait de mettre ou non cette commande ne change rien. Donc autant ne pas la mettre.

Et voilà c’est terminé cette fois-ci.

Sauf que...

Le préfixe "@" est un piège. En effet, quelle que soit la manière dont la commande se déroule (erreur ou pas) on passe à la suivante. Et une erreur de commande, c’est aussi une commande qui n’est pas trouvée.

C’est précisément ce qui m’est arrivé et que j’évoquais en début d’article. La commande xset n’était tout simplement pas installée sur le système, et par conséquent le DPMS n’était pas désactivé alors que je pensais qu’il l’était. Par conséquent l’affichage de ma borne persistait à s’éteindre au bout de 10 minutes. Comment je m’en suis rendu compte ? Tout simplement en essayant d’exécuter la commande "xset -q -display :0.0" qui affiche la configuration actuelle du display par défaut. Quand on vous renvoie "xset : command not found" comme réponse tout devient clair.

Pour corriger cela, il suffit d’installer le paquet x11-xserver-utils (qui fournit la commande xset) via un classique "sudo apt-get install".

J’ai mis un moment à trouver la cause, car ayant installé deux RasPi identiques, toutes deux à partir d’une SD Noobs, je ne comprenais pas pourquoi ça fonctionnait parfaitement sur la première et pas sur la deuxième. Vérification faite, la première avait bien la commande xset car le package était installé. Pourquoi il ne l’était pas sur la deuxième ? Grand mystère.

J’ai peut-être une explication possible. Il y a deux choix pour sélectionner l’installation de la Raspbian à partir de la SD Noobs. Celui qui est cochée par défaut installe à partir de la distrib contenue dans la SD, et l’autre (juste au-dessus) la télécharge depuis le réseau. J’ai sélectionné cette option pour la deuxième config, pensant disposer ainsi d’une version plus récente. En fait elle doit être différente et ne pas inclure tout à fait le même contenu.

Un petit cadeau pour finir

Il reste un petit détail peu esthétique : le pointeur de la souris au milieu de l’écran. Ce serait bien de pouvoir le masquer.

Il existe une application pour cela : unclutter

Elle fait disparaître le curseur au bout d’un délai d’inactivité et s’installe depuis le repository standard, soit par l’habituel "sudo apt-get install unclutter". Ajoutez la ligne correspondante dans le fichier autostart pour le lancer au démarrage. unclutter —help ou man unclutter vous donneront toute l’information utile sur les options disponibles.

Là c’est parfait, - ah ah ah ah - ah... comme dit l’autre dans la pub.

Petite mise à jour [2017]

Les versions actuelles de Jessie ayant remplacé Midori par Chromium, il suffit de remplacer la commande de lancement du browser telle qu’illustrée plus haut par :

@chromium-browser --kiosk http://url/vers/mon/site