-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raspbian 4.19 Buster RPi4B Install Instructions #6413
Comments
@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). I may need to make a clean buster install to test. Thank you guys. |
@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 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 |
@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 |
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 |
@frankgould , It's quite lengthy, but here's some of the compile errors I'm experiencing:
|
@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:
|
@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 And make sure before you run all of these that you have ran |
@somber02 You could always check if you have a Window Manager set for the one on 3B+. |
@matham I got the following response when trying the
|
You can see all the remotes you have set in git with E.g.
|
@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. |
@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. |
Beautiful. I also note that you're missing a |
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...
Note some of the oddness in the reporting, however, for example: As seen on the Pi4:
Compare/contrast as seen on the Pi3 with py2 and standard HDMI display (somewhat truncated for brevity):
Likewise, Frank's |
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 |
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.
ResultsSo it looks like one could temporarily develop OctoPrint plugins (with Kivy 1.11.1 support) against the 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
Note that the OctoPrint service runs from 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: #6474 (comment). 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: #6474 (comment), 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 |
This is a request to share my successful kivy installation instructions for Raspbian 4.19 Buster Desktop OS running on Raspberry Pi 3B+ and RPi4B:4GB.
For issues relative to the Buster Lite (without Desktop), please refer to Issue #6474.
Versions
Description
These install instructions so far have been successful in initial tests using the screenmanagertest.py, code listing below. These same tests were used to prove the previous Raspbian OS exhibited memory leaks within minutes of execution. Initial tests with the latest Raspbian Buster release (2019-07-10) running on a Raspberry Pi 3B+ have exhibited no memory leaks within this same amount of time. More tests will be run over the next few days to confirm that smaller leaks don't show up after longer periods of time.
Note: On RPi3B, this test only executes successfully with max Kivy screen resolution of 800x600; any larger size and fullscreen results in system lockup after a few images are loaded. This may be a problem due to 1GB system RAM.
On 08/09/19, this was tested successfully with a RPi4B with 4GB system RAM Desktop that confirmed to run full screen at 1366x768. More tests will be tried in the near future to confirm 1920x1080 resolution works over long periods of time.
Code and Logs
screenmanagertest.py code here
The text was updated successfully, but these errors were encountered: