Kivy: Buster RPi4B incapable de trouver un fournisseur Windows précieux à partir d'une console sans bureau

[INFO ] [Window ] Provider: egl_rpi

Je ne pense vraiment pas que Kivy (n'importe quelle version) parlera au fournisseur de egl_rpi Window parce que Kivy est lié à gles2.h plutôt qu'à une licorne nommée gles3.h qui n'existe pas d'après ce que je peux voir. Le Pi4B utilise OpenGL ES v3.

Essayez d'ajuster la configuration pour que Kivy demande sdl2 ou autre chose. Lisez les messages de Frank ici.

Existe-t-il un moyen d'installer le code Google Angle sur le Pi (pour obtenir les en-têtes OpenGL ES 3.0 peut-être), puis de corriger le fournisseur Kivy egl_rpi pour extraire le gles3.h au lieu de gles2.h (ou similaire) ?

Voici les instructions pour installer et exécuter une application Kivy au démarrage sur Buster lite :

Installez d'abord xserver-org, car nous en avons besoin pour afficher la fenêtre réelle :

sudo apt-get -y install xserver-xorg

Ensuite, j'installe nodm à partir des sources, il inclut donc le correctif suivant : https://github.com/spanezz/nodm/pull/10 :

sudo apt-get -y install libpam0g-dev help2man libx11-dev debhelper
git clone https://github.com/slashblog/nodm.git
pushd nodm
    git checkout d48a8f6266d3f464138e0e95b65896917c35c89f
    source /etc/os-release  # Will set the 'VERSION' variable
    if [ "$(echo $VERSION | sed -En 's/[0-9]+ \(([a-z]+)\)/\1/p')" == "buster" ]; then
        wget http://deb.debian.org/debian/pool/main/n/nodm/nodm_0.13-5.debian.tar.xz
    else
        wget http://deb.debian.org/debian/pool/main/n/nodm/nodm_0.13-1.3.debian.tar.xz
    fi
    tar xf nodm_0.13-*.debian.tar.xz
    sudo dpkg-buildpackage -us -uc -b
popd
sudo dpkg -i nodm_0.13-*_armhf.deb
sudo rm -rf nodm*

Activez maintenant la connexion graphique :

sudo systemctl set-default graphical.target

Configurez nodm et démarrez notre application au démarrage :

# Has the same effect as calling 'sudo dpkg-reconfigure nodm'
sudo sh -c 'echo "NODM_ENABLED=true" > /etc/default/nodm'
sudo sh -c 'echo "NODM_USER=$SUDO_USER" >> /etc/default/nodm' # Note that the variable SUDO_USER is used
sudo sh -c 'echo "NODM_FIRST_VT='\''7'\''" >> /etc/default/nodm'
sudo sh -c 'echo "NODM_XSESSION=/etc/X11/Xsession" >> /etc/default/nodm'
sudo sh -c 'echo "NODM_X_OPTIONS='\''-nolisten tcp'\''" >> /etc/default/nodm'
sudo sh -c 'echo "NODM_MIN_SESSION_TIME=60" >> /etc/default/nodm'
sudo sh -c 'echo "NODM_X_TIMEOUT=300" >> /etc/default/nodm'

# Start the app using nodm
echo '#!/bin/bash' > ~/.xsession
echo 'export DISPLAY=:0.0' >> ~/.xsession
echo "~/venv-kivy/bin/python3 ~/app.py" >> ~/.xsession

Configurez un environnement virtuel :

sudo apt-get -y install python3-pip python3-venv
sudo pip3 install -U pip
python3 -m venv venv-kivy
source ~/venv-kivy/bin/activate

Installez les dépendances Kivy :

sudo apt-get -y install python3-dev libmtdev1 libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev
sudo apt-get -y install pkg-config libgl1-mesa-dev libgles2-mesa-dev libgstreamer1.0-dev gstreamer1.0-plugins-{bad,base,good,ugly} gstreamer1.0-{omx,alsa} libmtdev-dev
pip3 install -U pygments docutils Cython==0.29.10 wheel

Il est maintenant temps de compiler et d'installer Kivy. A noter que j'utilise mon fork avec un patch, il n'utilise donc pas les drivers propriétaires Broadcom qui ne sont pas disponibles sur le Raspberry Pi 4 (https://github.com/Lauszus/kivy/commit/9cdcada34a6149b7fd6bd4c57285afc828d69948) :

export VIDEOCOREMESA=1; pip3 install git+https://github.com/Lauszus/kivy.git@rpi4_auto#egg=kivy

Créez enfin une petite application de test :

cat <<EOF > ~/app.py
from kivy.app import App
from kivy.uix.button import Button


class TestApp(App):

    def build(self):
        return Button(text='hello world')


if __name__ == '__main__':
    TestApp().run()
EOF

Maintenant, redémarrez et profitez-en :)

Besoin d'instructions d'installation pour RPi4B avec Raspbian Buster complet

Test:

RPi4 4 Go
Écran HDMI 7' (fonctionne avec un micro HDMI proche du type C)
config.ini

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmi_drive=1

Raspbian Buster 2019-09-26 complet

Journal : erreur "* échec de l'ajout du service - déjà utilisé ?"

pi@raspberrypi :~/kivy-examples/3Drendering $ python main.py
[INFO ] [Logger ] Enregistrer le journal dans /home/pi/.kivy/logs/kivy_19-10-19_10.txt
[INFO ] [Kivy ] v1.11.0
[INFO ] [Kivy ] Installé dans "/usr/local/lib/python2.7/dist-packages/kivy/__init__.pyc"
[INFO ] [Python ] v2.7.16 (par défaut, 6 avril 2019, 01:42:57)
[CCG 8.2.0]
[INFO ] [Python ] Interprète dans "/usr/bin/python"
[AVERTISSEMENT] [Déprécié] La prise en charge de Python 2 Kivy a été dépréciée. La version Kivy après 1.11.0 ne supportera plus Python 2
[INFO ] [Usine ] 184 symboles chargés
[INFO ] [Image ] Fournisseurs : img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignoré)
Fournisseur [INFO ] [Fenêtre ] : egl_rpi

• n'a pas réussi à ajouter le service - déjà en cours d'utilisation ?

@Lauszus, je

@diamond2nv "...avec Raspbian Buster full" Si vous entendez par là Raspbian Buster _Desktop_, les instructions se trouvent dans un numéro Kivy ici .

Merci beaucoup !
Problème résolu par cette instruction.

PS. "2019-09-26-raspbian-buster-full.img"

@Lauszus D'accord, j'ai testé ça sur...

• Raspberry Pi 4B (4 Go)
• Écran tactile capacitif elo 10.1"
• Raspbian Buster Lite 26/09/2019 -> "Linux octopi 4.19.75-v7l+ #1270 SMP mar. 24 sept. 18:51:41 BST 2019 armv7l"
• sudo apt-get update && sudo apt-get -y upgrade pour commencer
• sudo raspi-config avec localisation, démarrage automatique sur CLI _et pour mon installation, changements d'interfaces (I2C/UART/caméra)_

Je note que j'ai préparé tout cela en effectuant le processus de récupération Raspbian car j'avais précédemment exécuté rpi-update pour tenter de faire fonctionner cela. Ceci est connu pour changer le firmware stocké sur une puce, je suis donc revenu à la version publiée.

Sinon, j'ai suivi vos instructions. De plus, j'ai mis à jour la configuration pour permettre à l'appareil à écran tactile de fonctionner.

Modifier en ~/.kivy/config.ini :

[input]
mouse = mouse
#%(name)s = probesysfs,provider=hidinput
mtdev_%(name)s = probesysfs,provider=mtdev
hid_%(name)s = probesysfs,provider=hidinput

Correction pour le plein écran

Il ne s'affiche pas en "plein écran", donc je pense que je vais devoir jouer un peu avec les paramètres. C'est peut-être 800x640 au lieu des 1280x800 attendus. Cela peut être dans le fichier Raspbian /boot/config.txt , le fichier Kivy ~/.kivy/config.ini ou la configuration xsession...

Sur une intuition, cependant, je viens d'ajuster l'application de test en incluant ce qui suit près du haut :

from kivy.core.window import Window
Window.fullscreen = True

Cela semble faire l'affaire pour ajuster l'application pour qu'elle soit en plein écran, comme prévu.

Merci beaucoup! Je serais très intéressé de savoir quand cela sera inséré dans la branche master de Kivy elle-même.

@OutsourcedGuru, veuillez consulter le PR que j'ai ouvert : https://github.com/kivy/kivy/pull/6562.

Ce serait génial si vous pouviez l'essayer avec VIDEOCOREMESA=0 et VIDEOCOREMESA=1 et voir s'il y a une différence de performance.

@Lauszus : Beau travail - fonctionne très bien.

Aussi à @OutsourcedGuru.

@Lauszus Je suis allé re-tester plus tôt mais je pensais que vous aviez supprimé cette branche... (?) donc je n'ai pas pu.

@OutsourcedGuru comme je l'ai écrit plus tôt. J'ai fini par en ouvrir un nouveau qui détectera automatiquement quand il s'exécute dans un Raspberry Pi 4. Quoi qu'il en soit, j'ai également trouvé un moyen de compiler la roue de manière croisée, afin que les utilisateurs n'aient pas à compiler Kivy eux-mêmes. Veuillez télécharger la roue ici : https://github.com/Lauszus/kivy/suites/285162135/artifacts/197175 , puis commentez le PR suivant lorsque vous l'avez testé : https://github.com/kivy/kivy/ tirer/6568.

@Lauszus Grâce à votre aide, j'ai obtenu une ancienne application de RPI3B+ fonctionnant sur RPI4 avec votre méthode nodm.
Il démarre automatiquement au démarrage et c'est génial, c'est comme ça que je compte l'utiliser.
Mais j'ai d'autres problèmes avec l'application que je dois déboguer et je ne sais pas comment en obtenir une sortie normale comme lorsque je démarre l'application à partir de la cli comme dans 'python3 app.py'.
Avez-vous des conseils sur la façon dont je peux y parvenir?
Cela serait très apprécié.
Merci encore, je ne serais pas allé aussi loin sans votre message.
À votre santé!

@lucasnzone J'utilise simplement la fonctionnalité d'enregistrement au lieu des déclarations d'impression : https://kivy.org/doc/stable/api-kivy.logger.html.

Ensuite, j'utilise le script suivant pour redémarrer Kivy et suivre le log :

#!/bin/bash -e

if [[ $* == *--restart* ]]; then
    sudo service nodm restart
    inotifywait -q ~/.kivy/logs -e create --format %w%f | xargs tail -f
else
    ls -t -d ~/.kivy/logs/* | head -n1 | xargs tail -f
fi

Je n'ai pas pu tester, désolé pour le retard. Il s'agit d'environ deux semaines pour FormNext, nous nous efforçons donc ici, pour ce que ça vaut.

Si je me souviens de mes tests précédents, le petit programme de test Kivy fonctionnait mais le plugin OctoPrint qui utilisait Kivy ne semblait pas être content. J'ai passé pas mal de temps à essayer de modifier le mode de chargement d'OctoPrint (pour permettre à nodm de contrôler ce service). Le plugin OctoPrint doit se charger dans un environnement virtuel et se produit normalement en tant que service. Je n'ai pas eu le temps de chasser ce lapin jusqu'au fond de son trou.

@Lauszus Merci beaucoup pour cela, je n'y avais pas pensé, je vais essayer.
Merci encore mon pote

Journée Frabjous. J'ai réussi à obtenir une plate-forme de travail pour les éléments suivants :

• Kivy 1.10.1 installé dans un environnement virtuel
• Python 2.7
• Raspbian Buster Lite
• OctoPrint 1.3.12 (à partir de l'OctoPi 0.17.0 IMG)
• ffpyplayer (a dû revenir au gstplayer en raison d'incompatibilités Pi4B)
• nom
• Plugin OctoPrint utilisant Kivy

Il affiche avec succès une interface graphique plein écran au démarrage et aux redémarrages.

Du code Python...

    if pi_type == '4B':
        os.environ['VIDEOCOREMESA'] =       '1'
        os.environ['KIVY_WINDOW'] =         'sdl2'
        os.environ['KIVY_GL_BACKEND'] =     'gl'
        os.environ['rpi'] =                 '0'
        from kivy.core.window               import Window
        Window.fullscreen =                 True

Le fichier config.ini doit inclure les dimensions de l'écran et s'adapter au périphérique d'entrée de l'écran TFT.

Besoin d'instructions d'installation pour RPi4B avec Raspbian Buster complet

Test:

RPi4 4 Go
Écran HDMI 7' (fonctionne avec un micro HDMI proche du type C)
config.ini

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmi_drive=1

Raspbian Buster 2019-09-26 complet

Journal : erreur "* échec de l'ajout du service - déjà utilisé ?"

pi@raspberrypi :~/kivy-examples/3Drendering $ python main.py
[INFO ] [Logger ] Enregistrer le journal dans /home/pi/.kivy/logs/kivy_19-10-19_10.txt
[INFO ] [Kivy ] v1.11.0
[INFO ] [Kivy ] Installé dans "/usr/local/lib/python2.7/dist-packages/kivy/ init .pyc"
[INFO ] [Python ] v2.7.16 (par défaut, 6 avril 2019, 01:42:57)
[CCG 8.2.0]
[INFO ] [Python ] Interprète dans "/usr/bin/python"
[AVERTISSEMENT] [Déprécié] La prise en charge de Python 2 Kivy a été dépréciée. La version Kivy après 1.11.0 ne supportera plus Python 2
[INFO ] [Usine ] 184 symboles chargés
[INFO ] [Image ] Fournisseurs : img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignoré)
Fournisseur [INFO ] [Fenêtre ] : egl_rpi

• n'a pas réussi à ajouter le service - déjà en cours d'utilisation ?

Salut @diamond2nv , Pouvez-vous déjà exécuter kivy depuis la CLI ?

@elisandrom s'il vous plaît voir mon commentaire: https://github.com/kivy/kivy/issues/6474#issuecomment -542679712

@elisandrom s'il vous plaît voir mon commentaire: #6474 (commentaire)

Merci !!!!!! Fonctionne parfaitement !!!

Pour toute personne intéressée, une roue compilée de manière croisée peut être téléchargée ici : https://github.com/kivy/kivy/suites/364981942/artifacts/751103.

Suivez simplement ces instructions pour savoir comment installer toutes les dépendances : https://github.com/kivy/kivy/issues/6474#issuecomment -542679712, mais au lieu de compiler Kivy à partir de la source, vous devriez pouvoir l'installer à l'aide de la roue précompilée :

pip install Kivy-2.0.0.dev0-cp37-cp37m-linux_armv7l.whl

Ce serait formidable si nous pouvions faire tester cela par quelques personnes, afin que #6568 puisse être fusionné.

@Lauszus Pouvons-nous confirmer la version Kivy sur cette roue? Je dois supposer que c'est 2.0.0.dev0 du titre de la roue. Je ne sais vraiment pas ce qu'il y a dedans. Je suppose que cela nécessite Python 3 pour l'environnement virtuel, cependant.

@OutsourcedGuru oui c'est correct. Il s'agit essentiellement de la branche master avec les commits dans #6568. Voici l'action où elle a été construite : https://github.com/kivy/kivy/runs/354828981.

Oui, il nécessite Python 3.7, car c'est la norme dans Buster. Vous pouvez l'installer globalement ou dans un environnement virtuel, c'est à vous de décider.

Pour ce que ça vaut, j'ai réussi à mettre à niveau ma plate-forme de production vers Python 3 + Kivy 1.11.1 sur Raspbian Lite, après avoir installé nodm avec une prise en charge limitée de x Windows, comme indiqué ci-dessous. Cela fonctionne comme prévu sur le Pi 4B. L'installation était simplement pip install kivy==1.11.1 dans l'environnement virtuel.

sudo apt-get -y install xserver-xorg libpam0g-dev help2man libx11-dev debhelper

Compte tenu de https://github.com/kivy/kivy/issues/6474#issuecomment -542679712, il semble que la seule solution à ce jour sur le Raspberry Pi 4 soit d'utiliser X11. N'y a-t-il plus de support pour le framebuffer non-X comme c'était le cas sur les RPis précédents ? J'essaie de mettre à niveau mon projet d'un Raspberry Pi 3B+ vers un Raspberry Pi 4, mais je ne veux pas commencer à installer X11 juste pour pouvoir afficher des choses.

@whitelynx J'ai expérimenté la compilation de SDL2 sans X sur le Raspberry Pi 4. Cependant, il n'arrêtait pas de se plaindre de ne pas pouvoir trouver de fenêtre : https://github.com/kivy/kivy/pull/6662#issuecomment -573423540. Jusqu'à présent, je ne peux le faire fonctionner que si j'utilise un gestionnaire de fenêtres comme nodm.

Voici un exemple de code qui crée une fenêtre opengles sur rpi4 sans X.
https://github.com/matusnovak/rpi-opengl-without-x/blob/master/triangle_rpi4.c
https://www.raspberrypi.org/forums/viewtopic.php?t=243707#p1499181
Est-il possible qu'un code similaire puisse être utilisé pour dessiner une fenêtre Kivy ?

Notez que le premier exemple apporte gl2.h. Au meilleur de ma connaissance, le Pi4B utilise gl3.

Je les ai testés tous les deux sur mon rpi4b et ils ont fonctionné sans problème. Le premier exemple écrit dans un fichier brut et vous pouvez afficher le triangle à l'écran en décommentant la ligne 384.

@Lauszus Le problème de l'impossibilité de trouver une fenêtre lors de l'exécution avec SDL2 sans X11 est dû au fait que le code de création de fenêtre SDL2 spécifie 8 bits alpha pour la fenêtre. S'il est remplacé par 0 bits alpha dans kivy.core.window._window_sdl2.pyx, cela fonctionnera.

@ddimensia j'ai essayé de changer
138 : SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 8)
à
138 : SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 0)
Mais j'obtiens toujours les mêmes erreurs lorsque j'essaie de créer une fenêtre :
[CRITICAL] [Window ] Unable to find any valuable Window provider. Please enable debug logging (e.g. add -d if running from the command line, or change the log level in the config) and re-run your app to identify potential causes sdl2 - RuntimeError: Could not initialize EGL File "/usr/local/lib/python2.7/dist-packages/Kivy-1.11.0-py2.7-linux-armv7l.egg/kivy/core/__init__.py", line 71, in core_select_lib cls = cls() File "/usr/local/lib/python2.7/dist-packages/Kivy-1.11.0-py2.7-linux-armv7l.egg/kivy/core/window/window_sdl2.py", line 152, in __init__ super(WindowSDL, self).__init__() File "/usr/local/lib/python2.7/dist-packages/Kivy-1.11.0-py2.7-linux-armv7l.egg/kivy/core/window/__init__.py", line 969, in __init__ self.create_window() File "/usr/local/lib/python2.7/dist-packages/Kivy-1.11.0-py2.7-linux-armv7l.egg/kivy/core/window/window_sdl2.py", line 289, in create_window self.fullscreen, resizable, state) File "kivy/core/window/_window_sdl2.pyx", line 225, in kivy.core.window._window_sdl2._WindowSDL2Storage.setup_window File "kivy/core/window/_window_sdl2.pyx", line 75, in kivy.core.window._window_sdl2._WindowSDL2Storage.die

Avez-vous un dépôt avec toutes les modifications nécessaires pour que sdl2 + kivy fonctionne sur un rpi4 sans X ?

Je suis essentiellement les instructions Amiberry pour compiler SDL2 (https://github.com/midwan/amiberry/wiki/Compile-SDL2-from-source) avec les exigences minimales et compiler également SDL2_mixer à partir de la source, ce qui nécessite quelques autres bibliothèques si vous voulez un support mp3, flac, etc. Ensuite, j'ai modifié les bits Alpha à 0 dans le fichier _window_sdl2.pyx. Enfin, j'ai modifié le setup.py pour forcer use_x11 à False (à un endroit, il le définit sur True) et j'ai exécuté export VIDEOCOREMESA=1 puis pip install . . Je crois que c'était ça. Une chose que j'ai faite de différent lors de la compilation de toutes les bibliothèques SDL2 est que lorsque j'ai exécuté configure, j'ai ajouté --prefix=/usr aux arguments pour installer les bibliothèques à l'emplacement normal plutôt que /usr/local/lib.

@ddimensia merci ! Ça a marché :)

@ddimensia Je viens d'ouvrir un PR avec les changements : https://github.com/kivy/kivy/pull/6769. J'attends que le CI termine la construction, donc je peux vérifier que la roue construite par celui-ci fonctionnera également.

@ddimensia le VIDEOCOREMESA=1 n'était pas nécessaire, alors je l'ai laissé de côté.

@Lauszus Re-bonjour mon pote.
J'ai trouvé votre conteneur Kivy sur https://hub.docker.com/u/lauszus
Je me demandais si vous pouviez m'orienter dans la bonne direction en faisant courir Kivy à l'intérieur d'un conteneur.
Je veux dire, je l'ai bien fonctionné, il s'affiche sur un écran tactile.
Mais quoi que je fasse, je n'arrive pas à faire fonctionner l'écran tactile à l'intérieur du conteneur.
En saurais-tu quelque chose ?
Merci d'avance.
À votre santé

@lucasnzone c'est un ancien conteneur que j'ai utilisé lors de l'expérimentation de la compilation croisée Kivy pour accélérer mes constructions. Je n'ai jamais fait tourner Kivy à l'intérieur du conteneur, je l'ai juste utilisé pour le compiler.

Quoi qu'il en soit, une recherche rapide me dit qu'il devrait être possible d'utiliser l'argument --device lors de l'exécution du conteneur, c'est-à-dire :

--device /dev/input/event0

devrait ajouter votre écran tactile au conteneur.

Voir : https://docs.docker.com/engine/reference/commandline/run/

@Lauszus salut mon pote, merci pour ta réponse.
c'est dans ma commande docker run
--privileged --net host --device /dev/gpiomem:/dev/gpiomem --device /dev/ttyAMA0:/dev/ttyAMA0 -v /boot/overlay:/boot/overlay
Je viens de le tester en ajoutant --device /dev/input/event0
mais toujours pas de chance.
Je suis sur le point d'arrêter d'essayer avec un conteneur tous ensemble. Je n'arrive même pas à faire fonctionner les échantillons de kivy.
J'exécute même le conteneur avec --privileged sans succès.
Diriez-vous qu'il s'agit d'un problème de configuration de docker ou d'un problème de configuration de kivy ?
Je suis honnêtement perdu, j'ai passé une semaine là-dessus et je ne pouvais pas le comprendre.
merci encore pour ta réponse mon pote, vraiment apprécié

Avez-vous vérifié que votre écran tactile est bien /dev/input/event0 ?

Pourquoi voulez-vous l'exécuter dans un conteneur de toute façon si vous vous contentez de jouer avec les exemples ? Utilisez simplement un environnement virtuel Python et installez les dépendances requises pour votre système d'exploitation à l'aide du package manage, c'est- apt dire

@lucasnzone J'ai oublié de demander si vous utilisez un Raspberry Pi ou une autre plate-forme ? Et tu utilises quel OS ?

@Lauszus RPI4 avec raspbian lite
oh, non, j'ai une application actuelle que je veux exécuter dans un conteneur car cela facilitera la distribution et le contrôle de version.
J'essayais avec les exemples parce que si je les faisais fonctionner, je pourrais faire la même chose avec mon application kivy.
Comment puis-je vérifier que quel périphérique se trouve mon écran tactile dans /dev/input ? je ne l'ai pas fait, non

@lucasnzone voici la sortie sur mon système :

$ cat /proc/bus/input/devices | grep -P '^[NH]: ' | paste - -
N: Name="eGalax Inc. eGalaxTouch EXC3110-3883-08.00.00" H: Handlers=mouse0 event0

Cela signifie que l'écran tactile est à /dev/input/event0 .

ouais, le mien est un événement - aussi
N: Name="ADS7846 Touchscreen" H: Handlers=mouse0 event0

D'accord. L'application fonctionne-t-elle avec l'écran tactile à l'extérieur du conteneur ?

@Lauszus
oui, je l'ai fait avec la roue Kivy-2.0.0rc1-cp37-cp37m-linux_armv7l.whl
à l'origine avec votre fork qui n'utilise pas les drivers broadcom

D'accord. Quelles erreurs obtenez-vous ? Est-ce que le /dev/input/event0 ? dispositif présent à l'intérieur du conteneur?

oui @Lauszus
j'ai crw-rw---- 1 root i2c 13, 64 Mar 12 22:56 event0 et crw-rw---- 1 root i2c 13, 64 Mar 12 22:56 mouse0 à l'intérieur du conteneur

Essayez simplement de catégoriser la sortie, c'est- cat /dev/input/event0 dire

@Lauszus c'est le cas, caractères aléatoires
maintenant je suis plus confus qu'avant

Super cela signifie que le conteneur reçoit l'entrée. Ce que vous voyez est le flux d'octets brut, donc cela n'aura aucun sens pour vous. Quoi qu'il en soit, cela signifie que quelque chose dans votre configuration Kivy n'est pas correct.

Pouvez-vous essayer de compiler et d'exécuter ce code C (c'est un ancien code que j'ai utilisé pour déboguer mon écran):

#include <stdio.h>
#include <linux/input.h>
#include <signal.h>
#include <fcntl.h>
#include <unistd.h>

static volatile sig_atomic_t run = 1;

void sigint(int sig) {
    run = 0;
}

int main() {
    signal(SIGINT, sigint);

    int fd = open("/dev/input/event0", /*O_NONBLOCK |*/ O_RDONLY);
    if (fd < 0) {
        printf("Failed to open device\n");
        return 1;
    }

    while (run) {
        struct input_event ev;
        int num_bytes = read(fd, &ev, sizeof(ev));
        if (num_bytes != sizeof(ev)) {
            printf("Failed to read device\n");
            return 1;
        }
        printf("%u, %u, %u, %u, %d\n", ev.time.tv_sec, ev.time.tv_usec, ev.type, ev.code, ev.value);
    }

    printf("Closing device\n");
    close(fd);
    return 0;
}

Vous pouvez le compiler et l'exécuter comme ceci :

gcc touch.c -o touch && ./touch

@Lauszus
J'obtiens une sortie de toucher:

1584058230, 998152, 1, 330, 1
1584058230, 998152, 3, 0, 477
1584058230, 998152, 3, 1, 3477
1584058230, 998152, 3, 24, 64790
1584058230, 998152, 0, 0, 0
1584058231, 15687, 1, 330, 0
1584058231, 15687, 3, 24, 0
1584058231, 15687, 0, 0, 0

c'est en bas à gauche

D'accord. Essayez d'ajouter ce qui suit tout en haut du code (il est important qu'il soit au-dessus de toute autre importation) :

from kivy.config import Config
Config.set('input', 'mtdev_%(name)s', 'probesysfs,provider=mtdev')

ok, voici le résultat lorsque j'exécute mon application, avec ce code tout en haut :

[INFO ] Logger : Enregistrez le journal dans /root/.kivy/logs/kivy_20-03-13_3.txt
[INFO] Kivy : v2.0.0.dev0, git-cef99e4, 20191024
[INFO ] Kivy : Installé dans "/root/venv-kivy/lib/python3.7/site-packages/kivy/__init__.py"
[INFO ] Python : v3.7.3 (par défaut, 3 avril 2019, 05:39:12)
[CCG 8.2.0]
[INFO ] Python : Interprète à "/root/venv-kivy/bin/python3"
[INFO ] Usine : 184 symboles chargés
[INFO ] Image : Fournisseurs : img_tex, img_dds, img_sdl2, img_gif (img_pil, img_ffpyplayer ignoré)
[INFO ] Texte : Fournisseur : sdl2
[INFO ] Fenêtre : Fournisseur : sdl2(['window_egl_rpi'] ignoré)
[INFO ] GL : Utilisation du système graphique "OpenGL ES 2"
[INFO ] GL : Backend utilisé
[INFO ] GL : version OpenGL [INFO ] GL : fournisseur OpenGL [INFO ] GL : moteur de rendu OpenGL
[INFO ] GL : version analysée OpenGL : 2, 1
[INFO ] GL : version Ombrage
[INFO ] GL : Taille max de la texture <4096>
[INFO ] GL : Unités max de texture <16>
[INFO] Fenêtre : ajouter automatiquement le fournisseur d'entrée sdl2
[INFO ] Fenêtre : clavier virtuel non autorisé, mode unique, non ancré
[INFO] Base : Lancer la boucle principale de l'application
[INFO ] GL : la prise en charge des textures NPOT est disponible

il ne répond toujours pas au toucher