@frankgould I noticed that you are using a FadeTransition for switching screens. I have had issues with fade transitions on the Raspberry Pi a while back (I think it was crashing the app). So, I have been using the SlideTransition, you may want to try. Thank you for the setup info above. I just upgraded to Buster and have discovered that the touch interface is lagging. Scrolling is slow and very jittery. Have you experienced this with Buster? I'll update if I find out why.

@frankgould I noticed that you are using a FadeTransition for switching screens. I have had issues with fade transitions on the Raspberry Pi a while back (I think it was crashing the app). So, I have been using the SlideTransition, you may want to try. Thank you for the setup info above. I just upgraded to Buster and have discovered that the touch interface is lagging. Scrolling is slow and very jittery. Have you experienced this with Buster? I'll update if I find out why.

Thanks DanTheMan2000. This is just the basic test that fails first to determine if the graphics drivers a functional, which apparently they’re not in our tests using screenmanagertest.py, a kivy driven test. We’ll have to try several combinations to see what works for 3B+, 3B, and 4B. More later.

Hi, anybody have sucessfully run kivy on Rpi 4B yet?

@somber02, yes. python3 only.

@frankgould, Thank you for the reply. Can you share your installation instruction on Rpi 4B(python3 is fine.)? Also, what is the GL driver selected in raspi-config? We seem can only run kivy on Rpi 4B through SSH and it behaves very slow (as if no hardware accelartion is adopted). I somehow remember when using Rpi 3B+, I have to use egl_rpi window instead of sdl2 to improve the speed.

@somber02, I used the same install instructions above. I've successfully tested both Legacy and GL Fake drivers, editing /boot/config.txt and with raspi-config. You might need to set your DISPLAY variable when running on desktop. What I have just tested on my RPi4B:4G with screenmanagertest.py was removed the os.environ variables and the app still ran the same. It even ran with full screen set. So, I need to do more tests to see what kinds of results I get. I have gpu_mem=512.

In my limited test, I installed master in clean buster, with the sdl2 packages from apt and it worked fine. I didn't get the rpi egl_rpi provider to work though.

@frankgould , thank you for the instruction. I have the 1G version. If I use the 7 inch official display through DSI, what value shall I use for DISPLAY varible? I have tested all values before but it does not work (not following your instruction, I tried when 4B just released).
@matham , thank you for the comment. Do you mean that I have to install sdl2 with apt -get before I run kivy (not included by buster)?

I may need to make a clean buster install to test. Thank you guys.
Best,

@somber02, Below is what I use in my services file to start my kivy app from systemd. It is an RPi4A+ running the Official 7" touchscreen using ribbon cable (CSI? DSI?). I believe the CLI command is export DISPLAY=:0.0 that I got from linux questions.

Environment="DISPLAY=:0.0"

I most certainly agree with your suggestion to 'make a clean buster install.' I always start from a clean OS build once I figure out the pieces I need to install.

@frankgould . Thank you. I really appreciate it.

Have you tried the kivy support forum on Discord? There are others who can help with RPi questions sometimes.

@frankgould , I have not used Discord before, but I will try it right now. Thank you

Update: I have tested these install instructions and duplicated the Buster OS builds that run successfully on RPi4B:4GB. In addition, I have tested my SlideShow app ported from Android and it works successfully.

I am now seeking any issues with these instructions and will leave this open for any additional feedback.

@frankgould , I started with a fresh Buster OS, and followed your install instructions exactly. When I try to run the camera_puzzle.py example, it crashes with error "Unable to get a Window, abort." Do you have any suggestions? I am running RPi4B with official 7" touchscreen. I should also note that I had several compile errors, but it still continued to install Kivy.

@gtetil You may need to try the export DISPLAY suggestion in the comment above, if you didn't see that. My DISPLAY suggestion is what I use on my RPi3A+ with official 7" touchscreen. If so and you're still having problems, try experimenting with some of the kivy environment variables at link below. If those don't work for you, paste your kivy boot log (in pastebin or gist) and send a link. I also need to update my original post to include the fact I'm using 4GB RPi4B. Check your gpu_mem as well. I have mine set to 512.

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

@frankgould , I swear I did that before, but I tried it again and it worked. However, now when I try to run my application, it hangs up here. I am running gpu_mem=512.

[INFO ] [Logger ] Record log in /root/.kivy/logs/kivy_19-08-11_4.txt
[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 ] [Window ] Provider: sdl2(['window_egl_rpi'] ignored)
error: XDG_RUNTIME_DIR not set in the environment.

Sounds like it's a user permission issue. Search google for that error and you'll find multiple results.

@frankgould , Did you have compile errors too?

I had compile warnings mostly regarding Windoze requirements that were not necessary. I do not recall any errors but I did not analyze the logs since it works. Perhaps you should share the compile errors you encountered.

This is to report that the instruction provided by @frankgould worked on Rpi 4B:1Gb version. On official touch screen, no environment varible or raspi-config option needs to be set on a clean Buster install (4.19. release date:2019-07-10).

However, currently it only works in X11. Once we boot into CLI, the program can not start.

@somber02 Have you looked into Window Managers? It's X11 related and some systems comes shipped with it so you can launch apps. Look for Openbox it's popular.
A good place to read about them: https://wiki.archlinux.org/index.php/window_manager

@frankgould , It's quite lengthy, but here's some of the compile errors I'm experiencing:

```
Error compiling Cython file:

...
#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' is not a type identifier

Error compiling Cython file:

...

   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: Cannot take address of Python object attribute '_vc_rect'

Error compiling Cython file:

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

kivy/lib/vidcore_lite/egl.pyx:679:9: 'DISPMANX_PROTECTION_T' is not a type identifier

Error compiling Cython file:

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

kivy/lib/vidcore_lite/egl.pyx:680:9: 'VC_DISPMANX_ALPHA_T' is not a type identifier

Error compiling Cython file:

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

kivy/lib/vidcore_lite/egl.pyx:681:9: 'DISPMANX_CLAMP_T' is not a type identifier

Error compiling Cython file:

...
0, ##/src/,
&(src._vc_rect),
0,
0, ##/alpha/
0, ##/clamp/
0) ##/transform/
^

kivy/lib/vidcore_lite/egl.pyx:682:9: 'DISPMANX_TRANSFORM_T' is not a type identifier
building 'kivy.lib.vidcore_lite.egl' extension
creating 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 Do not use this file, it is the result of a failed Cython compilation.
#error Do not use this file, it is the result of a failed Cython compilation.
^~~~~
error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1

Failed building wheel for Kivy
Running setup.py clean for Kivy
Failed to build Kivy
```

@gtetil What's your installation parameters? Did you take them from https://kivy.org/doc/stable/installation/installation-rpi.html or what?

@kuzeyron , I tried @frankgould method as above, but I also tried this:

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 , Thank you for pointing the directions. We have little understanding about X11 related knowledge. We will take a look into that. However, in RPi 3B+, the kivy programs runs sucessfully in CLI ( Stretch).

@gtetil When you ran apt-get. Did it say anything about errors? It might jumped over those it couldn't find. If it did exactly that you can always manually search for them with apt-cache search package_name and install them with apt-get install package_name.

And make sure before you run all of these that you have ran apt-get update && apt-get upgrade.

@somber02 You could always check if you have a Window Manager set for the one on 3B+.

@kuzeyron , I tried a few times, and it always says they're already installed. And yes, update and upgrade was performed beforehand.

I remember having the same issue as @gtetil so I had to disable the egl_rpi backend. The problem seems to be that the egl_rpi backend is not compatible with buster on the pi4, so the sdl2 or x11 backend with the mesa drivers need to be used.

I don't remember what exactly I did though. I may have cloned and manually changed c_options['use_rpi'] = platform == 'rpi' to c_options['use_rpi'] = False in setup.py.

Another thing worth a try is this fix: https://github.com/kivy/kivy/pull/6472. But, I think this fixes another error so I'm not sure it'll fix your issue. You can test by doing git fetch origin and git checkout origin/matham-patch-1.

@matham I got the following response when trying the 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 is supposed to be the place you cloned it from. If you cloned it from kivy, that's where it'd point to so the command will work if you did git clone https://github.com/kivy/kivy. If you cloned it another way (e.g. from your fork) it won't work.

You can see all the remotes you have set in git with git remote and then git remote show xxx to get info on the particular remote.

E.g.

$ 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 Thanks. I think I should reset where I'm having problems now. We’re trying to run kivy from the CLI on RPi4B and the app cannot get a ‘valuable Window provider.’ We’ve tried openbox-session and still get the same results. We noticed RPi4B is configured with OpenGL ES 3.0 graphics and kivy says 2.0. Could this version mismatch be our problem?

My RPi4B runs kivy fine from the desktop with a terminal window. It's just the CLI that can't find a window.

I merged that PR so you can try master now. It should compile with both sdl2 and egl_rpi window support. However, I cannot run the egl window provider because at runtime it crashes. I believe the provider needs to be updated for the new graphics driver or something.

I remember having the same issue as @gtetil so I had to disable the egl_rpi backend. The problem seems to be that the egl_rpi backend is not compatible with buster on the pi4, so the sdl2 or x11 backend with the mesa drivers need to be used.

I don't remember what exactly I did though. I may have cloned and manually changed c_options['use_rpi'] = platform == 'rpi' to c_options['use_rpi'] = False in setup.py.

@matham , Tried, but didn't work. :/

Having problems with Buster in RPi 3B too. Although Kivy runs, the app freezes when I try to play audio and even Ctrl+C couldn't kill the app. Any ideas? Or should I just stick with stretch?

To test each of the kivy Window providers, I created a new issue with the results of each of these. These tests are using the command line interpreter with no desktop started. Kivy works fine from the desktop terminal but not when the OS boots to the console. That issue is referenced above.

@frankgould , Thank you for creating the issue post! Hopefully it's an easy fix.

Just subscribed to this thread but I'd remind everyone when indicating your platform to also include whether this is Lite or Desktop. I can guess from some of the discussion that this is for the Desktop (x11) version. I'd recommend updating the issue title to include this.

I also note that Buster 4.19 is also known from its release date of 2019-07-10, (keeping things apples-to-apples).

My own rig so far is Raspbian Buster Lite, which I'd suggest is significant to discussions like this.

@OutsourcedGuru Thank you for pointing this out. I have been trying to refine these instructions and see I have missed this important point. I have updated it accordingly.

If you want to discuss issues with Buster Lite (without Desktop), please refer and comment on the issue link below.

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

Beautiful.

I also note that you're missing a sudo apt upgrade after that sudo apt update. You must have run that and just omitted it in your instructions, right?

Yeah, stuff gets dropped somehow with copy/paste. Thank you for your quality control. That's exactly why I've posted this before anyone publishes it. We might even end up with two sets of instructions based on the Desktop versus Lite.

We're just in a tough situation because the Raspberry Pi Foundation is like "no way we'll have this until 2020... oh wait, here, let's ship them mid-2019..." All the while, the people writing the drivers must be like "wtffffffffff!!!!!"

Great news! I have finally been able to get a basic Button app to display graphically on...

• Raspberry Pi 4B with 4GB
• Raspbian Buster Desktop 7-10-2019
• Kivy 1.11.1
• Python 3.7.3
• SunFounder 10.1" capacitive TFT display

Note some of the oddness in the reporting, however, for example: <b'2.1 Mesa 19.1.0-devel'> with that b'something' notation.

As seen on the 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...

Compare/contrast as seen on the Pi3 with py2 and standard HDMI display (somewhat truncated for brevity):

[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>

Likewise, Frank's screenmanagertest.py with a pair of kitten graphics seemed to work as well.

Python 2 test (Buster Desktop)

I note that the Kivy log is identical between a Pi4B and Pi3B for the equivalent Python 2 (2.7.16) version of this. In the case of the Pi3B it displays on the screen. In the case of the Pi4B it simply fails to display and is unresponsive to Ctl-C in an attempt to stop the app.

Having killed the app, repeat attempts stop logging at the [INFO][Window] Provider: egl_rpi line (not logging the GL part) so it's been left in some crashed state at the OpenGL level.

Just noting the installation path I've now taken to attempt to get a working platform within the OctoPrint space. This attempt is to build everything from scratch starting with a known working Kivy platform of Buster Desktop with Python3.

• Visiting OctoPi nightly folder download 2019-09-07_2019-07-10-octopi-buster-lite-0.17.0.zip and use Etcher to a microSD card, editing the /boot/octopi-wpa-supplicant.txt
• Boot it (watching it resize the 2nd partition)
• ssh [email protected]
• From http://octopi.local/, Setup Wizard: user/password, disable Connectivity Check, etc
• sudo apt-get update && sudo apt-get upgrade
• sudo raspi-config # Localisation settings throughout
• sudo service octoprint stop
• mv oprint oprint.py2 # Retire the python2 virtual environment
• virtualenv -p python3 oprint
• source oprint/bin/activate
• pip install pip --upgrade
• Using the devel branch instructions here, ~/scripts/add-octoprint-checkout
• cd ~/OctoPrint && git fetch
• git checkout devel
• python setup.py clean
• pip install .
• sudo service octoprint start
• Visit http://octopi.local/ to confirm the version: OctoPrint 1.4.0.dev2236+gdbe07af4 running on OctoPi 0.17.0

Note: You'll want to switch the Software Update plugin to "Commit" tracking, otherwise you'll get prompted to reverting to a stable release.

• sudo service octoprint stop
• source oprint/bin/activate # In case you didn't earlier
• 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 # Already satisfied
• pip install Cython==0.29.10 pillow
• deactivate
• sudo ~/scripts/install-desktop # "yes" to install the Raspbian Buster Desktop to autoboot
• 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 # From ssh: _[CRITICAL] [App] Unable to get a Window, abort._
• python test.py # From pi local terminal, having source'd: works with a plugged-in mouse
• nano ~/.kivy/config.ini # [input] section:

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

Results

So it looks like one could temporarily develop OctoPrint plugins (with Kivy 1.11.1 support) against the devel OctoPrint branch (which supports Python 3). It's not suitable for production apps against a non-stable release, of course.

There are a number of hurdles to still jump over since a production app doesn't want or need the Raspbian Desktop trying to display itself to the user. The usual behavior would be to display a splash graphic until the app is loaded then to show the app fullscreen. This is a small advancement though, having worked at this for several weeks now.

Unfortunately—and after a fair amount of porting over of my code to Python 3 and the devel branch of OctoPrint, this isn't working with my plugin. We're back to the standard error message. I'm on the latest Buster Desktop for master, installed Kivy per Frank's earlier instructions.

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

Note that the OctoPrint service runs from init.d. If instead, I stop the service controller, start the virtual directory for Python 3 and run OctoPrint manually, it seems to try to instantiate another window.

I'm getting baby steps closer but I do need to have the Kivy window be fullscreen as it was before. Any thoughts?

Hi @frankgould @OutsourcedGuru, can you now run kivy direct from the CLI console? I did the steps informed above but was unsuccessful, always returns "Window" error. I am using Pi4 2GB with Raspian Buster

@elisandrom please see my comment here: https://github.com/kivy/kivy/issues/6474#issuecomment-542679712. Btw please do not post the same question in multiple issues :)

For anyone that is interested, then a cross compiled wheel can be downloaded here: https://github.com/kivy/kivy/suites/364981942/artifacts/751103.

Simply follow these instructions on how to install all the dependencies: https://github.com/kivy/kivy/issues/6474#issuecomment-542679712, but instead of compiling Kivy from source you should be able to install it using the precompiled wheel:

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

It would be great if we could get a couple of people to test this, so #6568 can get merged.

@elisandrom I now have working images for both Py2 and Py3 for the Raspberry Pi 4B on Raspbian Buster Lite. Search for anything that I've written on here and include the word nodm for more information.

Can you help me to resolve below issue?

I am facing below error when execute the command "buildozer -v android debug",

Apache ANT found at /home/pi/.buildozer/android/platform/apache-ant-1.9.4

Android SDK found at /home/pi/.buildozer/android/platform/android-sdk-20

Android NDK found at /home/pi/.buildozer/android/platform/android-ndk-r9c

Run '/home/pi/.buildozer/android/platform/android-sdk-20/tools/android list sdk -u -e'

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

b"SWT folder '/home/pi/.buildozer/android/platform/android-sdk-20/tools/lib/arm' does not exist.\nPlease export ANDROID_SWT to point to the folder containing swt.jar for your platform.\n"# Command failed: /home/pi/.buildozer/android/platform/android-sdk-20/tools/android list sdk -u -e

Buildozer failed to execute the last command

The error might be hidden in the log above this error

Please read the full log, and search for it before

raising an issue with buildozer itself.

In case of a bug report, please add a full log with log_level = 2