Cette source constitue un bon exemple de l’utilisation de ZimaOS comme hôte d’appliance, plutôt que d’essayer de transformer sa couche système en lecture seule en distribution de bureau. Comme ZimaOS ne dispose pas d’un apt environnement ou bureau X.Org intégré, l’auteur a construit toute la pile du kiosque dans Docker : Debian + X.Org + Chromium pour l’affichage, ainsi qu’un petit conteneur nginx pour le tableau de bord local.
Le résultat est un kiosque tactile fonctionnel de 22 pouces connecté à une ZimaBoard 2 1664. Il s’agit toujours d’une réalisation avancée de la communauté, et non d’un mode bureau pris en charge par IceWhale. Il utilise le réseau de l’hôte, un accès direct aux périphériques graphiques et d’entrée, ainsi qu’un conteneur kiosque privilégié ; les utilisateurs doivent donc comprendre les compromis en matière de sécurité et d’accès aux périphériques avant de le reproduire.
Le kiosque exécute une pile de bureau dans Docker
Le Dockerfile source part de Debian Bookworm Slim et installe X.Org, libinput, Openbox, Chromium, des utilitaires X11, des polices et Mesa. L’hôte reste sous ZimaOS ; l’espace utilisateur graphique se trouve dans le conteneur.
C’est exactement le type d’isolation des charges de travail que le modèle d’appliance ZimaOS est conçu pour encourager.
Le GPU Intel est exposé au conteneur kiosque
Le guide utilise le modesetting pilote et transmet le périphérique DRM Intel au conteneur. L’auteur a spécifiquement constaté que la prise en charge Mesa requise nécessitait les rétroportages de Bookworm pour la pile graphique N100 utilisée par ZimaBoard 2.
Le matériel actuel de ZimaBoard 2 utilise un Intel N150 ; les utilisateurs qui recréent ce guide doivent donc vérifier la prise en charge actuelle de Mesa/X.Org plutôt que de supposer que les informations historiques concernant le N100 sont identiques.
L’entrée tactile passe par la couche d’entrée/Udev de l’hôte
Le signal d’affichage utilisait HDMI/miniDP, tandis que le contrôleur de l’écran tactile était connecté en USB. Le guide examine /proc/bus/input/devices, mappe le périphérique d’événement approprié dans X.Org et partage /run/udev afin que le conteneur puisse identifier le matériel d’entrée.
Un conteneur nginx séparé sert le tableau de bord
La source s’exécute nginx:alpine sur un port différent de celui de ZimaOS (8888 dans l’exemple) et monte les fichiers du tableau de bord en lecture seule. Chromium ouvre cette URL locale en mode kiosque.
L’utilisation d’un conteneur web séparé facilite la mise à jour des fichiers du tableau de bord sans reconstruire le conteneur graphique.
Ne réutilisez pas le port 80 de ZimaOS pour le tableau de bord
Le guide indique explicitement que ZimaOS utilise déjà le port 80 pour son tableau de bord. Si Chromium ouvre la mauvaise page, vérifiez le port du tableau de bord personnalisé et la KIOSK_URL valeur plutôt que de modifier ZimaOS de manière inattendue.
L’auteur a ajouté une solution de contournement fondée sur les événements de pointeur pour les pressions tactiles
Dans le tableau de bord de la source, un léger mouvement du doigt pouvait empêcher Chromium de déclencher les onclick gestionnaires. L’auteur a remplacé la gestion des clics par pointerup ainsi qu’un seuil de déplacement.
Ce JavaScript est spécifique à l’application. Les interfaces web modernes conçues pour le tactile devraient privilégier des commandes adaptées au pointeur et au toucher plutôt que d’exécuter globalement des onclick chaînes.
Le mode privilégié est le principal compromis en matière de sécurité
La source lance le conteneur kiosque avec --privileged. Cela fournit un accès étendu aux périphériques et au noyau de l’hôte, et est bien plus permissif qu’un conteneur de tableau de bord ordinaire.
Si vous reproduisez la compilation, testez d’abord si l’accès explicite /dev/dri, les montages des périphériques d’entrée et de udev, ainsi que des capacités limitées, suffisent. Gardez le tableau de bord sur un réseau local de confiance.
La source utilise unless-stopped pour la récupération automatique
Les conteneurs nginx et kiosque utilisent tous deux restart: unless-stopped comportement afin que l’affichage réapparaisse après un redémarrage de ZimaOS. Stockez le Dockerfile, la configuration X.Org, le point d’entrée et le tableau de bord dans un /DATA stockage.
La version actuelle de ZimaOS peut empaqueter cela de manière plus reproductible avec Compose
La version actuelle de ZimaOS prend en charge les imports Docker Compose/YAML standard. Au lieu de gérer plusieurs fichiers longs docker run commandes, un utilisateur avancé peut définir les deux services, les politiques de redémarrage, les périphériques, les volumes et le réseau dans un seul fichier Compose vérifié.
Utilisez le modèle Compose actuel de ZimaOS.
FAQ du kiosque à écran tactile
ZimaOS doit-il avoir apt ou un environnement de bureau installé sur l’hôte ?
Non. La source conserve intentionnellement X.Org, Openbox, Mesa et Chromium à l’intérieur de Docker.
S’agit-il d’un mode bureau officiel de ZimaOS ?
Non. Il s’agit d’une version créée par la communauté, qu’IceWhale a demandé l’autorisation de partager avec mention de l’auteur.
Pourquoi le conteneur kiosque présente-t-il un risque élevé par rapport à une application normale ?
La source lui accorde le mode privilégié ainsi qu’un accès direct aux graphiques et aux périphériques d’entrée, ce qui réduit l’isolation de Docker.
