@frankgould J'ai remarqué que vous utilisez un FadeTransition pour changer d'écran. J'ai eu des problèmes avec les transitions de fondu sur le Raspberry Pi il y a quelque temps (je pense que cela faisait planter l'application). J'ai donc utilisé SlideTransition, vous voudrez peut-être essayer. Merci pour les informations de configuration ci-dessus. Je viens de passer à Buster et j'ai découvert que l'interface tactile était à la traîne. Le défilement est lent et très nerveux. Avez-vous vécu cela avec Buster ? Je mettrai à jour si je trouve pourquoi.

@frankgould J'ai remarqué que vous utilisez un FadeTransition pour changer d'écran. J'ai eu des problèmes avec les transitions de fondu sur le Raspberry Pi il y a quelque temps (je pense que cela faisait planter l'application). J'ai donc utilisé SlideTransition, vous voudrez peut-être essayer. Merci pour les informations de configuration ci-dessus. Je viens de passer à Buster et j'ai découvert que l'interface tactile était à la traîne. Le défilement est lent et très nerveux. Avez-vous vécu cela avec Buster ? Je mettrai à jour si je trouve pourquoi.

Merci DanTheMan2000. Ce n'est que le test de base qui échoue en premier à déterminer si les pilotes graphiques sont fonctionnels, ce qui n'est apparemment pas le cas dans nos tests à l'aide de screenmanagertest.py, un test piloté par Kivy. Nous devrons essayer plusieurs combinaisons pour voir ce qui fonctionne pour 3B+, 3B et 4B. Plus tard.

Salut, quelqu'un a-t-il déjà exécuté kivy avec succès sur Rpi 4B ?

@ sombre02 , oui. python3 uniquement.

@frankgould , Merci pour la réponse. Pouvez-vous partager vos instructions d'installation sur Rpi 4B (python3 est très bien.) ? Aussi, quel est le pilote GL sélectionné dans raspi-config ? Il semble que nous ne puissions exécuter kivy que sur Rpi 4B via SSH et qu'il se comporte très lentement (comme si aucune accélération matérielle n'était adoptée). Je me souviens en quelque sorte que lorsque j'utilise Rpi 3B+, je dois utiliser la fenêtre egl_rpi au lieu de sdl2 pour améliorer la vitesse.

@ somber02 , j'ai utilisé les mêmes instructions d'installation ci-dessus. J'ai testé avec succès les pilotes Legacy et GL Fake, en éditant /boot/config.txt et avec raspi-config. Vous devrez peut-être définir votre variable DISPLAY lors de l'exécution sur le bureau. Ce que je viens de tester sur mon RPi4B:4G avec screenmanagertest.py a été supprimé les variables os.environ et l'application fonctionnait toujours de la même manière. Il fonctionnait même en plein écran. Donc, je dois faire plus de tests pour voir quels types de résultats j'obtiens. J'ai gpu_mem=512.

Dans mon test limité, j'ai installé master dans clean buster, avec les packages sdl2 d'apt et cela a bien fonctionné. Je n'ai pas réussi à faire fonctionner le fournisseur rpi egl_rpi.

@frankgould , merci pour l'instruction. J'ai la version 1G. Si j'utilise l'écran officiel de 7 pouces via DSI, quelle valeur dois-je utiliser pour la variable DISPLAY ? J'ai déjà testé toutes les valeurs mais cela ne fonctionne pas (ne suivant pas vos instructions, j'ai essayé lorsque 4B vient de sortir).
@matham , merci pour le commentaire. Voulez-vous dire que je dois installer sdl2 avec apt -get avant d'exécuter kivy (non inclus par buster) ?

Je devrai peut-être faire une installation propre de buster pour tester. Merci les gars.
Meilleur,

@ somber02 , Voici ce que j'utilise dans mon fichier de services pour démarrer mon application kivy à partir de systemd. Il s'agit d'un RPi4A+ exécutant l'écran tactile officiel 7" à l'aide d'un câble plat (CSI? DSI?). Je crois que la commande CLI est export DISPLAY=:0.0 que j'ai obtenue à partir de questions Linux .

Environnement="AFFICHAGE=:0.0"

Je suis tout à fait d'accord avec votre suggestion de « faire une installation propre. » Je pars toujours d'une version propre du système d'exploitation une fois que j'ai compris les pièces que je dois installer.

@frankgould . Merci. J'apprécie vraiment cela.

Avez-vous essayé le forum d'assistance de Kivy sur Discord ? Il y en a d'autres qui peuvent parfois aider avec les questions RPi.

@frankgould , je n'ai jamais utilisé Discord auparavant, mais je vais l'essayer tout de suite. Merci

Mise à jour : j'ai testé ces instructions d'installation et dupliqué les versions de Buster OS qui s'exécutent avec succès sur RPi4B : 4 Go. De plus, j'ai testé mon application SlideShow portée depuis Android et elle fonctionne avec succès.

Je cherche maintenant tout problème avec ces instructions et je laisserai cela ouvert pour tout commentaire supplémentaire.

@frankgould , j'ai commencé avec un nouveau système d'exploitation Buster et j'ai suivi exactement vos instructions d'installation. Lorsque j'essaie d'exécuter l'exemple camera_puzzle.py, il se bloque avec l'erreur « Impossible d'obtenir une fenêtre, abandonner. » Avez-vous des suggestions? J'utilise RPi4B avec un écran tactile officiel de 7". Je dois également noter que j'ai eu plusieurs erreurs de compilation, mais il a quand même continué à installer Kivy.

@gtetil Vous devrez peut-être essayer la suggestion export DISPLAY dans le commentaire ci-dessus, si vous ne l'avez pas vu. Ma suggestion DISPLAY est ce que j'utilise sur mon RPi3A+ avec un écran tactile officiel de 7". Si c'est le cas et que vous rencontrez toujours des problèmes, essayez d'expérimenter certaines des variables d'environnement kivy au lien ci-dessous. Si celles-ci ne fonctionnent pas pour vous, collez votre kivy boot log (dans pastebin ou gist) et envoyer un lien. Je dois également mettre à jour mon message d'origine pour inclure le fait que j'utilise 4 Go de RPi4B. Vérifiez également votre gpu_mem. J'ai le mien défini sur 512.

https://kivy.org/doc/stable/guide/environment.html

@frankgould , je jure que je l'ai déjà fait, mais je l'ai réessayé et cela a fonctionné. Cependant, maintenant, lorsque j'essaie d'exécuter mon application, elle raccroche ici. J'exécute gpu_mem=512.

[INFO ] [Logger ] Enregistrez le journal dans /root/.kivy/logs/kivy_19-08-11_4.txt
[INFO ] [Kivy ] v1.11.1
[INFO ] [Kivy ] Installé dans "/usr/local/lib/python3.7/dist-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 dans "/usr/bin/python3"
[INFO ] [Usine ] 184 symboles chargés
[INFO ] [Image ] Fournisseurs : img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignoré)
Fournisseur [INFO ] [Window ] : sdl2(['window_egl_rpi'] ignoré)
erreur : XDG_RUNTIME_DIR non défini dans l'environnement.

On dirait que c'est un problème d'autorisation d'utilisateur. Recherchez cette erreur sur Google et vous trouverez plusieurs résultats.

@frankgould , Avez-vous aussi eu des erreurs de compilation ?

J'avais compilé des avertissements principalement concernant les exigences de Windoze qui n'étaient pas nécessaires. Je ne me souviens d'aucune erreur mais je n'ai pas analysé les logs puisque ça marche. Vous devriez peut-être partager les erreurs de compilation que vous avez rencontrées.

Ceci est pour signaler que l'instruction fournie par @frankgould a fonctionné sur la version Rpi 4B:1Gb. Sur l'écran tactile officiel, aucune variable d'environnement ou option raspi-config ne doit être définie sur une installation propre de Buster (date de sortie du 19/07/2019 : 10/07/2019).

Cependant, actuellement, cela ne fonctionne que sous X11. Une fois que nous avons démarré dans CLI, le programme ne peut pas démarrer.

@somber02 Avez-vous examiné les gestionnaires de fenêtres ? Il est lié à X11 et certains systèmes sont livrés avec afin que vous puissiez lancer des applications. Cherchez Openbox c'est populaire.
Un bon endroit pour lire à leur sujet : https://wiki.archlinux.org/index.php/window_manager

@frankgould , c'est assez long, mais voici quelques-unes des erreurs de compilation que je rencontre :

```
Erreur lors de la compilation du fichier Cython :

...
#dispman_update = bcm.vc_dispmanx_update_start( 0 )

   dispman_element = bcm.vc_dispmanx_element_add ( dispman_update, dispman_display,
       0, ##/*layer*/,
       &(dst._vc_rect),
       <bcm.DISPMANX_RESOURCE_HANDLE_T>0, ##/*src*/,
       ^

kivy/lib/vidcore_lite/egl. pyx:677 :9: 'DISPMANX_RESOURCE_HANDLE_T' n'est pas un identifiant de type

Erreur lors de la compilation du fichier Cython :

...

   dispman_element = bcm.vc_dispmanx_element_add ( dispman_update, dispman_display,
       0, ##/*layer*/,
       &(dst._vc_rect),
       <bcm.DISPMANX_RESOURCE_HANDLE_T>0, ##/*src*/,
       &(src._vc_rect),
      ^

kivy/lib/vidcore_lite/egl. pyx:678 :8: Impossible de prendre l'adresse de l'attribut d'objet Python '_vc_rect'

Erreur lors de la compilation du fichier Cython :

...
dispman_element = bcm.vc_dispmanx_element_add ( dispman_update, dispman_display,
0, ##/ couche /,
&(dst._vc_rect),
0, ##/ src /,
&(src._vc_rect),
0,
^

kivy/lib/vidcore_lite/egl. pyx:679 :9: 'DISPMANX_PROTECTION_T' n'est pas un identifiant de type

Erreur lors de la compilation du fichier Cython :

...
0, ##/ couche /,
&(dst._vc_rect),
0, ##/ src /,
&(src._vc_rect),
0,
0, ##/ alpha /
^

kivy/lib/vidcore_lite/egl. pyx:680 :9: 'VC_DISPMANX_ALPHA_T' n'est pas un identifiant de type

Erreur lors de la compilation du fichier Cython :

...
&(dst._vc_rect),
0, ##/ src /,
&(src._vc_rect),
0,
0, ##/ alpha /
0, ##/ pince /
^

kivy/lib/vidcore_lite/egl. pyx:681 :9: 'DISPMANX_CLAMP_T' n'est pas un identifiant de type

Erreur lors de la compilation du fichier Cython :

...
0, ##/ src /,
&(src._vc_rect),
0,
0, ##/ alpha /
0, ##/ pince /
0) ##/ transformer /
^

kivy/lib/vidcore_lite/egl. pyx:682 :9: 'DISPMANX_TRANSFORM_T' n'est pas un identifiant de type
construction de l'extension 'kivy.lib.vidcore_lite.egl'
création de build/temp.linux-armv7l-3.7/tmp/pip-req-build-hmbalioz/kivy/lib/vidcore_lite
arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ pip-req-build-hmbalioz/kivy/include -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -I/ usr/include/python3.7m -c /tmp/pip-req-build-hmbalioz/kivy/lib/vidcore_lite/egl.c -o build/temp.linux-armv7l-3.7/tmp/pip-req-build-hmbalioz /kivy/lib/vidcore_lite/egl.o
/tmp/pip-req-build-hmbalioz/kivy/lib/vidcore_lite/egl.c:1:2: error: #error N'utilisez pas ce fichier, il est le résultat d'un échec de compilation Cython.
#error N'utilisez pas ce fichier, il est le résultat d'un échec de compilation Cython.
^~~~~
erreur : la commande 'arm-linux-gnueabihf-gcc' a échoué avec l'état de sortie 1

Échec de la construction de la roue pour Kivy
Exécution de setup.py clean pour Kivy
Échec de la construction de Kivy
```

@gtetil Quels sont vos paramètres d'installation ? Les as-tu pris sur https://kivy.org/doc/stable/installation/installation-rpi.html ou quoi ?

@kuzeyron , j'ai essayé la méthode @frankgould comme ci-dessus, mais j'ai aussi essayé ceci :

sudo apt update
sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev \
   pkg-config libgl1-mesa-dev libgles2-mesa-dev \
   python-setuptools libgstreamer1.0-dev git-core \
   gstreamer1.0-plugins-{bad,base,good,ugly} \
   gstreamer1.0-{omx,alsa} python-dev libmtdev-dev \
   xclip xsel libjpeg-dev

sudo pip3 install cython==0.29.10
git clone https://github.com/kivy/kivy
cd kivy
sudo pip3 install .

@kuzeyron , Merci d'avoir

@gtetil Lorsque vous avez exécuté apt-get . A-t-il dit quelque chose sur les erreurs? Il pourrait sauter par-dessus ceux qu'il n'a pas pu trouver. Si c'est exactement ce que vous avez fait, vous pouvez toujours les rechercher manuellement avec apt-cache search package_name et les installer avec apt-get install package_name .

Et assurez-vous avant d'exécuter tout cela que vous avez exécuté apt-get update && apt-get upgrade .

@somber02 Vous pouvez toujours vérifier si vous avez un gestionnaire de fenêtres défini pour celui sur 3B+.

@kuzeyron , j'ai essayé plusieurs fois, et il est toujours dit qu'ils sont déjà installés. Et oui, la mise à jour et la mise à niveau ont été effectuées au préalable.

Je me souviens avoir eu le même problème que @gtetil , j'ai donc dû désactiver le backend egl_rpi. Le problème semble être que le backend egl_rpi n'est pas compatible avec buster sur le pi4, donc le backend sdl2 ou x11 avec les pilotes mesa doit être utilisé.

Par contre, je ne me souviens plus de ce que j'ai fait exactement. J'ai peut-être cloné et modifié manuellement c_options['use_rpi'] = platform == 'rpi' en c_options['use_rpi'] = False dans setup.py .

Une autre chose qui vaut la peine d'être essayée est ce correctif : https://github.com/kivy/kivy/pull/6472. Mais, je pense que cela corrige une autre erreur, donc je ne suis pas sûr que cela résoudra votre problème. Vous pouvez tester en faisant git fetch origin et git checkout origin/matham-patch-1 .

@matham J'ai obtenu la réponse suivante en essayant le git fetch origin :

fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

origin est censé être l'endroit à partir duquel vous l'avez cloné. Si vous l'avez cloné à partir de kivy, c'est là qu'il pointerait donc la commande fonctionnera si vous avez fait git clone https://github.com/kivy/kivy . Si vous l'avez cloné d'une autre manière (par exemple à partir de votre fork), cela ne fonctionnera pas.

Vous pouvez voir toutes les télécommandes que vous avez définies dans git avec git remote puis git remote show xxx pour obtenir des informations sur la télécommande en particulier.

Par exemple

$ git remote
origin
pyodide

$ git remote show origin
Enter passphrase for key '/home/matte/.ssh/gh':
* remote origin
  Fetch URL: [email protected]:matham/kivy.git
  Push  URL: [email protected]:matham/kivy.git
  HEAD branch: master
  Remote branches:
  ...

@matham Merci. Je pense que je devrais réinitialiser là où j'ai des problèmes maintenant. Nous essayons d'exécuter kivy à partir de la CLI sur RPi4B et l'application ne peut pas obtenir un "fournisseur Windows précieux". Nous avons essayé openbox-session et obtenons toujours les mêmes résultats. Nous avons remarqué que RPi4B est configuré avec les graphiques OpenGL ES 3.0 et kivy dit 2.0. Cette incompatibilité de version pourrait-elle être notre problème ?

Mon RPi4B exécute kivy très bien depuis le bureau avec une fenêtre de terminal. C'est juste la CLI qui ne trouve pas de fenêtre.

J'ai fusionné ce PR pour que vous puissiez essayer master maintenant. Il devrait être compilé avec la prise en charge des fenêtres sdl2 et egl_rpi. Cependant, je ne peux pas exécuter le fournisseur de fenêtres egl car il se bloque lors de l'exécution. Je pense que le fournisseur doit être mis à jour pour le nouveau pilote graphique ou quelque chose du genre.

Je me souviens avoir eu le même problème que @gtetil , j'ai donc dû désactiver le backend egl_rpi. Le problème semble être que le backend egl_rpi n'est pas compatible avec buster sur le pi4, donc le backend sdl2 ou x11 avec les pilotes mesa doit être utilisé.

Par contre, je ne me souviens plus de ce que j'ai fait exactement. J'ai peut-être cloné et modifié manuellement c_options['use_rpi'] = platform == 'rpi' en c_options['use_rpi'] = False dans setup.py .

@matham , Essayé, mais n'a pas fonctionné. :/

J'ai aussi des problèmes avec Buster dans RPi 3B. Bien que Kivy fonctionne, l'application se bloque lorsque j'essaie de lire de l'audio et même Ctrl+C n'a pas pu tuer l'application. Des idées? Ou devrais-je simplement m'en tenir à l'étirement ?

Pour tester chacun des fournisseurs de Kivy Window, j'ai créé un nouveau problème avec les résultats de chacun d'entre eux. Ces tests utilisent l'interpréteur de ligne de commande sans qu'aucun bureau ne démarre. Kivy fonctionne correctement depuis le terminal de bureau, mais pas lorsque le système d'exploitation démarre sur la console. Ce problème est mentionné ci-dessus.

@frankgould , Merci d'avoir créé la publication du problème ! Espérons que ce soit une solution facile.

Je viens de m'abonner à ce fil, mais je rappelle à tout le monde, lorsque vous indiquez votre plate-forme, d'inclure également s'il s'agit de Lite ou de Desktop. Je peux deviner d'après certaines discussions qu'il s'agit de la version Desktop (x11). Je recommanderais de mettre à jour le titre du problème pour inclure cela.

Je note également que Buster 4.19 est également connu depuis sa date de sortie du 2019-07-10, (en gardant les choses de pommes à pommes).

Ma propre plate-forme jusqu'à présent est Raspbian Buster Lite, ce qui, selon moi, est important pour des discussions comme celle-ci.

@OutsourcedGuru Merci de l'avoir signalé. J'ai essayé d'affiner ces instructions et je vois que j'ai raté ce point important. Je l'ai mis à jour en conséquence.

Si vous souhaitez discuter de problèmes avec Buster Lite (sans Desktop), veuillez vous référer et commenter le lien ci-dessous.

https://github.com/kivy/kivy/issues/6474

Beau.

Je note également qu'il vous manque un sudo apt upgrade après ce sudo apt update . Vous devez l'avoir exécuté et l'avoir simplement omis dans vos instructions, n'est-ce pas ?

Ouais, les choses sont supprimées d'une manière ou d'une autre avec le copier/coller. Merci pour votre contrôle qualité. C'est exactement pourquoi j'ai posté ceci avant que quiconque ne le publie. Nous pourrions même nous retrouver avec deux ensembles d'instructions basées sur le Desktop par rapport à Lite.

Nous sommes juste dans une situation difficile parce que la Fondation Raspberry Pi est comme "pas question que nous ayons cela avant 2020... oh attendez, ici, expédions-les mi-2019..." Pendant tout ce temps, les gens écrivent les pilotes doivent être comme "wtffffffffff!!!!!"

Bonne nouvelle! J'ai enfin pu obtenir une application Button de base à afficher graphiquement sur...

• Raspberry Pi 4B avec 4 Go
• Bureau Raspbian Buster 7-10-2019
• Kivy 1.11.1
• Python 3.7.3
• Écran TFT capacitif 10,1" SunFounder

Notez cependant certaines bizarreries dans le rapport, par exemple : <b'2.1 Mesa 19.1.0-devel'> avec cette notation b'something' .

Comme vu sur le Pi4 :

[INFO   ] Kivy: v1.11.1
[INFO   ] Kivy: Installed at "/usr/local/lib/python3.7/dist-packages/kivy/__init__.py"
[INFO   ] Python: v3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0]
[INFO   ] Python: Interpreter at "/usr/bin/python3"
[INFO   ] Factory: 184 symbols loaded
[INFO   ] Image: Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] Text: Provider: sdl2(['text_pango'] ignored)
[INFO   ] Window: Provider: sdl2(['window_egl_rpi'] ignored)
[INFO   ] GL: Using the "OpenGL" graphics system
[INFO   ] GL: Backend used <sdl2>
[INFO   ] GL: OpenGL version <b'2.1 Mesa 19.1.0-devel'>
[INFO   ] GL: OpenGL vendor <b'Broadcom'>
[INFO   ] GL: OpenGL renderer <b'V3D 4.2'>
[INFO   ] GL: OpenGL parsed version: 2, 1
[INFO   ] GL: Shading version <b'1.20'>
[INFO   ] GL: Texture max size <8192>
[INFO   ] GL: Texture max units <16>
[INFO   ] Window: auto add sdl2 input provider
[INFO   ] Window: virtual keyboard not allowed, single mode, not docked
[INFO   ] ProbeSysfs: device match: /dev/input/event5
[INFO   ] MTD: Read event from </dev/input/event5>
[INFO   ] ProbeSysfs: device match: /dev/input/event3
[INFO   ] MTD: Read event from </dev/input/event3>
[INFO   ] ProbeSysfs: device match: /dev/input/event1
[INFO   ] MTD: Read event from </dev/input/event1>
[INFO   ] ProbeSysfs: device match: /dev/input/event4
[INFO   ] MTD: Read event from </dev/input/event4>
[INFO   ] ProbeSysfs: device match: /dev/input/event2
[INFO   ] MTD: Read event from </dev/input/event2>
[INFO   ] ProbeSysfs: device match: /dev/input/event0
[INFO   ] MTD: Read event from </dev/input/event0>
[INFO   ] ProbeSysfs: device match: /dev/input/event5
[INFO   ] HIDInput: Read event from </dev/input/event5>
[INFO   ] ProbeSysfs: device match: /dev/input/event3
[INFO   ] HIDInput: Read event from </dev/input/event3>
[INFO   ] ProbeSysfs: device match: /dev/input/event1
[INFO   ] HIDInput: Read event from </dev/input/event1>
[INFO   ] ProbeSysfs: device match: /dev/input/event4
[INFO   ] HIDInput: Read event from </dev/input/event4>
[INFO   ] ProbeSysfs: device match: /dev/input/event2
[INFO   ] HIDInput: Read event from </dev/input/event2>
[INFO   ] ProbeSysfs: device match: /dev/input/event0
[INFO   ] HIDInput: Read event from </dev/input/event0>
[INFO   ] Base: Start application main loop
[INFO   ] MTD: </dev/input/event5> range position X is 0 - 16384
[INFO   ] MTD: </dev/input/event3> range position X is 0 - 0
[INFO   ] MTD: </dev/input/event5> range position Y is 0 - 9600
[INFO   ] MTD: </dev/input/event1> range position X is 0 - 0
[INFO   ] MTD: </dev/input/event3> range position Y is 0 - 0
[INFO   ] MTD: </dev/input/event5> range touch major is 0 - 0
[INFO   ] MTD: </dev/input/event4> range position X is 0 - 16384
[INFO   ] MTD: </dev/input/event1> range position Y is 0 - 0
[INFO   ] MTD: </dev/input/event1> range touch major is 0 - 0
[INFO   ] MTD: </dev/input/event2> range position X is 0 - 0
[INFO   ] MTD: </dev/input/event3> range touch major is 0 - 0
[INFO   ] HIDMotionEvent: using <ILITEK ILITEK-TP >
[INFO   ] MTD: </dev/input/event5> range touch minor is 0 - 0
[INFO   ] HIDMotionEvent: using <USB OPTICAL MOUSE  >
[INFO   ] MTD: </dev/input/event4> range position Y is 0 - 9600
[INFO   ] MTD: </dev/input/event0> range position X is 0 - 0
[INFO   ] MTD: </dev/input/event0> range position Y is 0 - 0
[INFO   ] MTD: </dev/input/event0> range touch major is 0 - 0
[INFO   ] HIDMotionEvent: using <ILITEK ILITEK-TP Mouse >
[INFO   ] MTD: </dev/input/event2> range position Y is 0 - 0
[INFO   ] MTD: </dev/input/event2> range touch major is 0 - 0
[INFO   ] GL: NPOT texture support is available
[INFO   ] HIDMotionEvent: using <SEM USB Keyboard >
[INFO   ] MTD: </dev/input/event3> range touch minor is 0 - 0
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP > range ABS X position is 0 - 16384
[INFO   ] MTD: </dev/input/event5> range pressure is 0 - 255
[INFO   ] MTD: </dev/input/event4> range touch major is 0 - 0
[INFO   ] MTD: </dev/input/event0> range touch minor is 0 - 0
[INFO   ] MTD: </dev/input/event1> range touch minor is 0 - 0
[INFO   ] HIDMotionEvent: using <SEM USB Keyboard Consumer Control >
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP Mouse > range ABS X position is 0 - 16384
[INFO   ] HIDMotionEvent: using <SEM USB Keyboard System Control >
[INFO   ] MTD: </dev/input/event2> range touch minor is 0 - 0
[INFO   ] MTD: </dev/input/event3> range pressure is 0 - 255
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP > range ABS Y position is 0 - 9600
[INFO   ] MTD: </dev/input/event5> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event4> range touch minor is 0 - 0
[INFO   ] MTD: </dev/input/event0> range pressure is 0 - 255
[INFO   ] MTD: </dev/input/event1> range pressure is 0 - 255
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP Mouse > range ABS Y position is 0 - 9600
[INFO   ] MTD: </dev/input/event2> range pressure is 0 - 255
[INFO   ] MTD: </dev/input/event3> axes invertion: X is 0, Y is 0
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP > range position X is 0 - 16384
[INFO   ] MTD: </dev/input/event5> rotation set to 0
[INFO   ] MTD: </dev/input/event2> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event0> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event1> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event4> range pressure is 0 - 255
[INFO   ] MTD: </dev/input/event3> rotation set to 0
[INFO   ] HIDMotionEvent: <ILITEK ILITEK-TP > range position Y is 0 - 9600
[INFO   ] MTD: </dev/input/event2> rotation set to 0
[INFO   ] MTD: </dev/input/event0> rotation set to 0
[INFO   ] MTD: </dev/input/event1> rotation set to 0
[INFO   ] MTD: </dev/input/event4> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event4> rotation set to 0
[INFO   ] WindowSDL: exiting mainloop and closing.
[INFO   ] Base: Leaving application in progress...

Comparez/contraste comme on le voit sur le Pi3 avec py2 et un écran HDMI standard (un peu tronqué par souci de concision) :

[INFO   ] Kivy: v1.11.1
[INFO   ] Kivy: Installed at "/home/pi/.local/lib/python2.7/site-packages/kivy/__init__.pyc"
[INFO   ] Python: v2.7.16 (default, Apr  6 2019, 01:42:57) 
[GCC 8.2.0]
[INFO   ] Python: Interpreter at "/usr/bin/python"
[WARNING] Deprecated: Python 2 Kivy support has been deprecated. The Kivy release after 1.11.0 will not support Python 2 anymore
[INFO   ] Factory: 184 symbols loaded
[INFO   ] Image: Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] Text: Provider: sdl2
[INFO   ] Window: Provider: egl_rpi
[INFO   ] GL: Using the "OpenGL ES 2" graphics system
[INFO   ] GL: Backend used <gl>
[INFO   ] GL: OpenGL version <OpenGL ES 2.0>
[INFO   ] GL: OpenGL vendor <Broadcom>
[INFO   ] GL: OpenGL renderer <VideoCore IV HW>
[INFO   ] GL: OpenGL parsed version: 2, 0
[INFO   ] GL: Shading version <OpenGL ES GLSL ES 1.00>
[INFO   ] GL: Texture max size <2048>
[INFO   ] GL: Texture max units <8>

De même, le screenmanagertest.py Frank avec une paire de graphiques de chaton semblait également fonctionner.

Test Python 2 (Buster Desktop)

Je note que le journal Kivy est identique entre un Pi4B et un Pi3B pour la version Python 2 (2.7.16) équivalente de celui-ci. Dans le cas du Pi3B, il s'affiche à l'écran. Dans le cas du Pi4B, il ne s'affiche tout simplement pas et ne répond pas à Ctl-C pour tenter d'arrêter l'application.

Après avoir tué l'application, les tentatives répétées d'arrêter la journalisation à la ligne [INFO][Window] Provider: egl_rpi (pas de journalisation de la partie GL) de sorte qu'elle a été laissée dans un état de plantage au niveau OpenGL.

Juste en notant le chemin d'installation que j'ai maintenant emprunté pour tenter d'obtenir une plate-forme de travail dans l'espace OctoPrint. Cette tentative consiste à tout construire à partir de zéro en commençant par une plate-forme Kivy fonctionnelle connue de Buster Desktop avec Python3.

• Visiter le dossier OctoPi nightly télécharger 2019-09-07_2019-07-10-octopi-buster-lite-0.17.0.zip et utiliser Etcher sur une carte microSD, en modifiant le /boot/octopi-wpa-supplicant.txt
• Démarrez-le (en le regardant redimensionner la 2ème partition)
• ssh [email protected]
• Depuis http://octopi.local/ , Assistant de configuration : utilisateur/mot de passe, désactiver la vérification de la connectivité, etc.
• sudo apt-get update && sudo apt-get upgrade
• sudo raspi-config # Paramètres de localisation partout
• sudo service octoprint stop
• mv oprint oprint.py2 # Retrait de l'environnement virtuel python2
• virtualenv -p python3 oprint
• source oprint/bin/activate
• pip install pip --upgrade
• En utilisant les instructions de la branche devel ici , ~/scripts/add-octoprint-checkout
• cd ~/OctoPrint && git fetch
• git checkout devel
• python setup.py clean
• pip install .
• sudo service octoprint start
• Visitez http://octopi.local/ pour confirmer la version : OctoPrint 1.4.0.dev2236+gdbe07af4 fonctionnant sur OctoPi 0.17.0

Remarque : vous devrez basculer le plug-in de mise à jour de logiciels sur le suivi « Commit », sinon vous serez invité à revenir à une version stable.

• sudo service octoprint stop
• source oprint/bin/activate # Au cas où vous ne l'auriez pas fait plus tôt
• sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev pkg-config libgl1-mesa-dev libgles2-mesa-dev python3-setuptools libgstreamer1.0-dev git-core gstreamer1.0-plugins-{bad,base,good,ugly} gstreamer1.0-{omx,alsa} python3-dev libmtdev-dev xclip xsel libjpeg-dev
• pip install setuptools # Déjà satisfait
• pip install Cython==0.29.10 pillow
• deactivate
• sudo ~/scripts/install-desktop # "oui" pour installer le bureau Raspbian Buster pour le démarrage automatique
• sudo reboot
• source oprint/bin/activate
• sudo service octoprint stop
• pip install kivy
• mkdir tmp && cd tmp
• touch test.py && nano test.py

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

• python test.py # Depuis ssh : _[CRITICAL] [App] Impossible d'obtenir une fenêtre, abandonnez._
• python test.py # Depuis le terminal local pi, ayant source'd : fonctionne avec une souris branchée
• nano ~/.kivy/config.ini # Section [saisie] :

# %(name)s = probesysfs,provider=mtdev
mtdev_%(name)s = probesysfs,provider=mtdev
hid_%(name)s = probesysfs,provider=hidinput

Résultats

Il semble donc que l'on puisse développer temporairement des plugins OctoPrint (avec le support Kivy 1.11.1) contre la branche devel OctoPrint (qui supporte Python 3). Cela ne convient pas aux applications de production contre une version non stable, bien sûr.

Il y a encore un certain nombre d'obstacles à surmonter car une application de production ne veut pas ou n'a pas besoin que le bureau Raspbian essaie de s'afficher à l'utilisateur. Le comportement habituel serait d'afficher un graphique de démarrage jusqu'à ce que l'application soit chargée, puis d'afficher l'application en plein écran. C'est un petit progrès cependant, après avoir travaillé là-dessus depuis plusieurs semaines maintenant.

Malheureusement, et après une bonne partie du portage de mon code vers Python 3 et la branche devel d'OctoPrint, cela ne fonctionne pas avec mon plugin. Nous revenons au message d'erreur standard. Je suis sur le dernier Buster Desktop pour master , j'ai installé Kivy selon les instructions précédentes de Frank.

2019-09-24 14:55:42,476 - octoprint.util.pip - INFO - ==> pip ok -> yes
2019-09-24 14:55:42,558 - kivy - INFO - Logger: Record log in /home/pi/.kivy/logs/kivy_19-09-24_13.txt
2019-09-24 14:55:42,557 - kivy - INFO - Kivy: v1.11.1
2019-09-24 14:55:42,558 - kivy - INFO - Kivy: Installed at "/home/pi/oprint/lib/python3.7/site-packages/kivy/__init__.py"
2019-09-24 14:55:42,559 - kivy - INFO - Python: v3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0]
2019-09-24 14:55:42,559 - kivy - INFO - Python: Interpreter at "/home/pi/oprint/bin/python"
2019-09-24 14:55:42,592 - kivy - INFO - Factory: 184 symbols loaded
2019-09-24 14:55:42,680 - kivy - INFO - Image: Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
2019-09-24 14:55:42,962 - kivy - INFO - Text: Provider: sdl2(['text_pango'] ignored)
2019-09-24 14:55:43,035 - kivy - INFO - Loader: using a thread pool of 2 workers
2019-09-24 14:55:43,163 - kivy - INFO - Window: Provider: sdl2(['window_egl_rpi'] ignored)
2019-09-24 14:55:43,525 - kivy - 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
egl_rpi - ImportError: cannot import name 'bcm' from 'kivy.lib.vidcore_lite' (/home/pi/oprint/lib/python3.7/site-packages/kivy/lib/vidcore_lite/__init__.py)
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/__init__.py", line 63, in core_select_lib
    fromlist=[modulename], level=0)
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/window/window_egl_rpi.py", line 12, in <module>
    from kivy.lib.vidcore_lite import bcm, egl

sdl2 - RuntimeError: b'Could not initialize EGL'
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/__init__.py", line 71, in core_select_lib
    cls = cls()
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/window/window_sdl2.py", line 152, in __init__
    super(WindowSDL, self).__init__()
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/window/__init__.py", line 981, in __init__
    self.create_window()
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/window/window_sdl2.py", line 290, in create_window
    self.get_gl_backend_name())
  File "kivy/core/window/_window_sdl2.pyx", line 224, in kivy.core.window._window_sdl2._WindowSDL2Storage.setup_window
  File "kivy/core/window/_window_sdl2.pyx", line 74, in kivy.core.window._window_sdl2._WindowSDL2Storage.die

x11 - ModuleNotFoundError: No module named 'kivy.core.window.window_x11'
  File "/home/pi/oprint/lib/python3.7/site-packages/kivy/core/__init__.py", line 63, in core_select_lib
    fromlist=[modulename], level=0)

2019-09-24 14:55:43,631 - kivy - INFO - VideoGstplayer: Using Gstreamer 1.14.4.0
2019-09-24 14:55:43,631 - kivy - INFO - Video: Provider: gstplayer

Notez que le service OctoPrint fonctionne à partir de init.d . Si à la place, j'arrête le contrôleur de service, démarre le répertoire virtuel pour Python 3 et lance OctoPrint manuellement, il semble essayer d'instancier une autre fenêtre.

Je me rapproche un peu plus, mais j'ai besoin que la fenêtre Kivy soit en plein écran comme avant. Des pensées?

Salut @frankgould @OutsourcedGuru , pouvez-vous maintenant exécuter kivy directement depuis la console CLI ? J'ai suivi les étapes indiquées ci-dessus mais sans succès, renvoie toujours l'erreur "Window". J'utilise Pi4 2 Go avec Raspian Buster

@elisandrom s'il vous plaît voir mon commentaire ici: https://github.com/kivy/kivy/issues/6474#issuecomment-542679712. Au fait, veuillez ne pas poster la même question dans plusieurs numéros :)

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 demander à quelques personnes de tester cela, afin que #6568 puisse être fusionné.

@elisandrom J'ai maintenant des images de travail pour Py2 et Py3 pour le Raspberry Pi 4B sur Raspbian Buster Lite. Recherchez tout ce que j'ai écrit ici et incluez le mot nodm pour plus d'informations.

Pouvez-vous m'aider à résoudre le problème ci-dessous?

Je suis confronté à l'erreur ci-dessous lorsque j'exécute la commande "buildozer -v android debug",

Apache ANT trouvé dans /home/pi/.buildozer/android/platform/apache-ant-1.9.4

SDK Android trouvé sur /home/pi/.buildozer/android/platform/android-sdk-20

NDK Android trouvé dans /home/pi/.buildozer/android/platform/android-ndk-r9c

Exécutez '/home/pi/.buildozer/android/platform/android-sdk-20/tools/android list sdk -u -e'

Cwd /home/pi/.buildozer/android/platform

b"Le dossier SWT '/home/pi/.buildozer/android/platform/android-sdk-20/tools/lib/arm' n'existe pas.\nVeuillez exporter ANDROID_SWT pour pointer vers le dossier contenant swt.jar pour votre plate-forme. \n"# La commande a échoué : /home/pi/.buildozer/android/platform/android-sdk-20/tools/android list sdk -u -e

Buildozer n'a pas réussi à exécuter la dernière commande

L'erreur peut être masquée dans le journal au-dessus de cette erreur

Veuillez lire le journal complet et le rechercher avant

soulevant un problème avec buildozer lui-même.

En cas de rapport de bogue, veuillez ajouter un journal complet avec log_level = 2