Buster RPi4B unable to find valuable Window provider from Desktop-less console #6474
Comments
|
same behavior found in RPi 4B: 1G version. Previously, I saw in other SBC forum, to use sdl2 window provider, needs to recompile the sdl2 with KMS support. Not sure if this will be helpful. |
|
Likewise, I spent three days of testing, attempting to find a viable Raspbian Lite configuration which would display a GUI on the SunFounder 10" touchscreen (reasonably compatible with the standard Raspberry Pi Foundation display) on a Raspberry Pi 4B with 4GB RAM. Error condition: Kivy app crash (unresponsive) requiring a |
|
Well, I've already had problems with HDMI not functioning properly due to the new dual micro-HDMI ports. I have not tested the 7" Official Touchscreen with the 4B models and can imagine there is problems with that. I've reported the micro-HDMI issue. Good luck with the DSI. |
|
I encountered I wonder if it's the same on buster lite? |
Had same problem but now got. Just disabled openGL in raspi-config |
|
@Gawezi You need to set kivy to use the egl_rpi window, not x11 by setting |
|
Having the same/similar issue on Pi 3B running Buster on #6418 thank you for posting your progress and i'm really hoping the solution comes soon! |
|
@matham Can you elaborate where to set USE_X11=1? I think this is my problem with both Buster and ALARM (haven’t tested this same issue from console boot without desktop). I’ve been trying to run kivy without desktop and think that’s my problem. I need to compile kivy with x11 support as you say. |
|
@frankgould export VIDEOCOREMESA=1 environment variable before compiling kivy (fa9932d) Otherwise it will always compile against proprietary drivers on rpi. |
|
@rnixx Thanks for the info. I’ll take a shot at that today. |
frankgould
changed the title
|
However, that is not likely to fix your issues of running kivy without desktop because if you run without desktop I'm guessing you're running without x support in the OS, so having x support in kivy won't help. Only egl_rpi is supposed to work without x support afaik. |
|
Thanks @matham. I added that key=Val combo in /etc/environment along with KIVY_GRAPHICS=“gles” and VIDEOCOREMESA=1 but none worked without the desktop. It could not open a window. I need to go dig into an older RPi3A+ to see how I installed it to get it to run without a desktop on ALARM. Update: The above test were on ALARM 4.19, not Buster. So, this comment is outside this thread but relevant. I will be testing this on Buster next. |
|
Today I tested RPi4B:4GB Raspbian 4.19 kivy installed with the following /etc/environment contents: Here is the results of the run using default environment values: |
I'm getting a |
|
I think I found my solution for Arch Linux build on RPi3A+. Below is what the boot executes on auto-login and my start screen systemd service, also below. So, it appears the boot starts X11 and that's how kivy starts (on pastebin). I need to test this on Buster to see if I get the same results. .xinitrc content: My screen-start.service: The kivy environment value at startup: |
|
This runs both ways on Buster with Pi3B+ |
|
Actually, I'm here on a Saturday testing this nonsense. Same Raspbian Lite rig as stated above, plus attempting to add the x11 interface. I tried to just get the bare minimum but that wouldn't bring up the GUI desktop. Starting it from the Pi itself having started x then worked as seen below. |
|
Same Raspbian Lite rig (with x11/Desktop added) still suffers in the Python2 world. It freezes up, isn't responsive to Ctl-C, doesn't display another window, logs normally otherwise. |
|
@OutsourcedGuru You should ignore using |
|
And yet, since January I've been working on a plugin for OctoPrint. It doesn't yet support Py3 on the |
|
“Alas, poor Yorick, I knew him well.” @OutsourcedGuru, I once read a Raspberry Pi moderator say that no one should base a business model on Raspbian, or Raspberry Pi for that matter. He could be right at the time but over time, they make progress for more possibilities. As you can see above, I got ALARM to work with my app; however, since then the HDMI audio is hosed. It’s clean in python command line but when running from systemd, it’s garbage. So, it’s a tech curve that developers are chasing. You can pound on it all day, like I did today, and still get no results. Just keep pounding, if it’s worth it for you. |
|
Did anyone try this suggestion? Looks like he's changing KIVY_TEXT as well. I will try this weekend if I get a chance. |
|
So everyone still unable to get Kivy running on Buster..? |
|
It's easy to run Kivy programs on the desktop version, but still didn't find a way to work myself to start it in console boot. Anyone else? |
|
Thanks haha, I feel pretty dumb for not trying that now... I had only been trying through ssh but just gave it a shot through vnc and it did indeed work. If it's of any interest, tkinter (other python UI library) also does not work through console but does with desktop. I do really need a reliable way to start from console or at least startup but thank you for mentioning this I finally have a workaround! |
|
@masynthetic On ALARM, my .xinitrc starts windows then my Kivy app autoruns after windows are up. I can give more info if you need it. I’m not in my office right now and need to boot the tablet to see exactly how I implemented it. |
|
That would be extremely helpful thanks, no rush as I mostly just need a
development environment at this time
…On Sat, Sep 14, 2019, 3:17 AM Frank Gould ***@***.***> wrote:
@masynthetic <https://github.com/masynthetic> On ALARM, my .xinitrc
starts windows then my Kivy app autoruns after windows are up. I can give
more info if you need it. I’m not in my office right now and need to boot
the tablet to see exactly how I implemented it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6474?email_source=notifications&email_token=AEOWUVKTRWPPLKDVSMG2ERDQJS25HA5CNFSM4IL7DFSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6WY6MA#issuecomment-531468080>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEOWUVMTOIQUCNBD7EKOK3TQJS25HANCNFSM4IL7DFSA>
.
|
|
That would be useful. @frankgould I do think we need a good solution for the the Desktop-less version of this. I'm hoping to just return to this later and the underlying operating system and driver set works as it did before. Being cynical, I kind of doubt it though. |
|
yes @Lauszus |
|
Try to just cat the output i.e. |
|
@Lauszus it does, random characters |
|
Super that means that the container is getting the input. What you are seeing is the raw byte stream, so it will not make sense to you. Anyway this means that it's something in your Kivy configuration is not correct. Can you try to compile and run this C code (it's some old code I used for debugging my screen): #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;
}You can compile and run it like so: gcc touch.c -o touch && ./touch |
|
@Lauszus 1584058230, 998152, 1, 330, 1 that's bottom left corner |
|
Okay. Try to add the following to the very top of the code (it's important that's it's above any other imports): from kivy.config import Config
Config.set('input', 'mtdev_%(name)s', 'probesysfs,provider=mtdev') |
|
ok, this is the output when I run my app, with that code at the very top: [INFO ] Logger: Record log in /root/.kivy/logs/kivy_20-03-13_3.txt it still doesn't respond to touch |
|
Can you try to install the |
|
sure can, i'll try now and run it again |
|
@Lauszus it was already installed, same issues |
|
@Lauszus I got it working! Thanks for all your help mate! |
|
@lucasnzone great to hear that :) |
|
For anyone reading this; #6769 has now been merged, so no changes to Kivy is no longer needed, but you still need to compile SDL2 from source. Instructions can be found in the official docs: https://kivy.org/doc/master/installation/installation-rpi.html. |
|
@Lauszus , Best, |
|
@somber02 It would be better if you ask for further support on our official support channels (e.g. discord). We prefer to use github issues primarily for actual bugs and not support. |
|
@matham the issue is that there is a problem with the CI workflow that generates the docs, so it's not updated on the website: https://github.com/kivy/kivy/runs/506000991. @somber02 for now you can find the documentation here: https://github.com/Lauszus/kivy/blob/45f7ec3851e09220b2b5dc8f34523d6eebff17c2/doc/sources/installation/installation-rpi.rst until the website gets updated. |
|
Ok, my bad, I forgot to merge kivy/kivy-server#17. Should be fixed now. |
|
@Lauszus , Hi Lauszus. Thank you for the instruction. I followed the link with updated information but it still failed with "Unable to find any window provider". and "sdl2-runtimeError"could not initialze EGL" Test condition:
Am I doing something wrong? |
|
@somber02 did you compile Kivy from the master branch? If not please do so, as the pre-built wheels has not been updated yet. |
|
@somber02 also note that you should NOT install these dependencies using apt: libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-devAs you want to use the version you compiled yourselves. |
|
@Lauszus Thank you. I just copied the dependencies without close look.... Thank you that is the reason. After I purged these package and reinstalled the compiled sdl2 package, it works. Thank you so much for your hard work. |
|
@Lauszus , I can confirm that it is hardware accelerated. Thank you |
In a case like this for the Kivy installation instructions you might even suggest that the user actively do a |
|
@Lauszus Amazing work - this resolved all the issues of getting kivy running on buster lite for me. Can I suggest just for clarification that the guide state that step 2 altogether is skipped if you are doing a buster lite setup on pi 4? Additionally, is there a work around for maintaining hardware acceleration that would enable you to rotate orientation for configuration? The only way I can see that this works is with x11 or by disabling the V3D driver. |
|
@pwdavari step 2 should not be skipped if you are using Buster lite, as you need to compile SDL2 from source unless they have updated the SDL2 package? You can rotate the display by adding the following kernel commands in video=HDMI-A-1:1920x1080M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0,rotate=90,reflect_xSee: https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md If you only want to rotate the display in Kivy: from kivy.config import Config
Config.set('input', 'mtdev_%(name)s', 'probesysfs,provider=mtdev,param=rotation=90,param=invert_y=1') |
|
@Lauszus Thanks for the reply I was just referring to this point from step 3 of the documentation:
Should we not just skip step 2 of the normal Pi 1-4 setup if you have already installed sdl packages from source and followed the steps -> sudo make install for each? Or is it saying that you should follow the steps but do not install with apt so you would do:
|
|
I wasn't putting the video= parameters on the same line. Wasn't until you pointed me back to the documentation that I noticed it very explicitly states that all cmdline.txt parameters/configs need to be on one line. Rookie mistake. Thanks for your help! |
|
@pwdavari yes you need to skip step 2 under "Raspberry Pi 1-4 installation". |
and others
After logging on the Raspberry Pi 4B to the command line (using raspi-config boot to CLI), cannot execute kivy because of critical error when attempting to use any kivy Window provider: egl_rpi, sdl2, pygame, or x11. This issue lists the attempts and results of each of these Window providers. These providers are listed on the following page:
https://kivy.org/doc/stable/guide/environment.html
Versions
Description
The same test.py program listed below was used to test all of the Window providers listed above. The second line is changed for each test results.
When no (default) KIVY_WINDOW defined (test.py above), gets the following results:
After changing line 2 by removing the # sign, got the following results:
After changing line 2 to
os.environ['KIVY_WINDOW'] = 'sdl2', got the following results:After changing line 2 to
os.environ['KIVY_WINDOW'] = 'pygame', got the following results:After changing line 2 to
os.environ['KIVY_WINDOW'] = 'x11', got the following results:The text was updated successfully, but these errors were encountered: