CI: Compile wheels for Raspberry Pi 1-3 using the CI

[Lauszus]

I have appended rpi123 to the wheel filename, as these wheels will only work on the Raspberry Pi 1-3, as they use the proprietary Broadcom drivers.

[Lauszus]

I have tested the wheel on a Raspberry Pi 3 I have remote access to and my Kivy application starts up fine. I have no physical access to it at the moment, so it's hard to tell if there is any performance differences. I'll test it more after New Years.

[matham]

Nice.

We have a script that automatically runs on the server such that nightly wheels can be installed using python -m pip install kivy[base] --pre --extra-index-url https://kivy.org/downloads/simple/. You can see that the previous pi wheels are already listed there.

Besides updating the docs to use this, I'm wondering how to handle the clash between pi1-3 and pi4? Currently, the command above will only work on pi4 and it would need to be installed manually on the pi1-3.

I'm wondering, are you definitely sure that wheels built with the Broadcom drivers cannot work on the pi4 and vice-versa? raspberrypi/firmware#1171 (comment) seems to suggest that maybe it can work? Kivy can also use sdl2 as the graphics backend when gl is not directly available: https://kivy.org/doc/stable/api-kivy.graphics.cgl.html#module-kivy.graphics.cgl.

[Lauszus]

I finally got around to test the wheel on a Raspberry Pi 4, but it keeps trying to use the egl_rpi window provider:

[INFO   ] Logger: Record log in /home/pi/.kivy/logs/kivy_20-01-05_64.txt
[INFO   ] Kivy: v2.0.0.dev0, git-3593e7f, 20191223
[INFO   ] Kivy: Installed at "/home/pi/venv-kivy-rpi123/lib/python3.7/site-packages/kivy/__init__.py"
[INFO   ] Python: v3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.2.0]
[INFO   ] Python: Interpreter at "/home/pi/venv-kivy-rpi123/bin/python"
[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

Is there anyway to ignore the egl_rpi window provider via some flag?

[matham]

Yeah, set KIVY_WINDOW to whatever provider you want to use. I think it should be just sdl2?

I was wondering, could you not build the wheel on the pi4 with both x11 and sdl2 support? Then people could use the wheel on older PIs using the x11 provider and sdl2 on PI4? Or maybe the opposite, build for pi3 with x11/sdl2 and that should also work on pi4? Then we could have one wheel for all PIs. I'm not sure if the sdl2 provide works on older PIs.

[Lauszus]

You were right! Setting KIVY_WINDOW=sdl2 does indeed work. I did not have to install the khronos-api package.

I'll update the PR, so it checks this if statement: https://github.com/kivy/kivy/blob/master/kivy/core/window/__init__.py#L2064 so the egl_rpi window provider is not used on the Raspberry Pi 4.

[Lauszus]

I just pushed: 732f93a. Do you have a good suggestion where I can put the pi_version() method?

[matham]

Do you have a good suggestion where I can put the pi_version() method?

I think in utils is probably best: https://github.com/kivy/kivy/blob/master/kivy/utils.py.

Can you summarize the situation now? So, sdl2 works for all pi versions. Perhaps we can enable x11 support as well so people can use that as an alternate provider. Or maybe it's already enabled? This solves the window provider.

Regarding the graphics backend (i.e. gl support), you can control that with KIVY_GL_BACKEND (https://kivy.org/doc/stable/api-kivy.graphics.cgl.html). By default on the pi it should be gl, using the gl drivers directly. But we can also set it to sdl2, thereby avoiding having to link to the drivers ourselves. It'd be worth checking if both options work.

I guess I also wonder about the egl_rpi window provider now. It'd be nice if the wheel supports it for pi < 4, but I'm guessing that could only work if the correct drivers are installed during building and that cannot work for both 3 and 4 in one wheel? Is that correct?

[Lauszus]

I think in utils is probably best: https://github.com/kivy/kivy/blob/master/kivy/utils.py.

This is fixed in: dee79da

Can you summarize the situation now? So, sdl2 works for all pi versions. Perhaps we can enable x11 support as well so people can use that as an alternate provider. Or maybe it's already enabled? This solves the window provider.

Currently sdl2 works on the Raspberry Pi 4. I have not tested sdl2 on the Raspberry Pi 3, only egl_rpi. I can do that tomorrow.

No x11 is not enabled at the moment: https://github.com/Lauszus/kivy/runs/380422538#step:3:7164.

If I set USE_X11=1, should I set USE_EGL=1 as well?

Regarding the graphics backend (i.e. gl support), you can control that with KIVY_GL_BACKEND (https://kivy.org/doc/stable/api-kivy.graphics.cgl.html). By default on the pi it should be gl, using the gl drivers directly. But we can also set it to sdl2, thereby avoiding having to link to the drivers ourselves. It'd be worth checking if both options work.

Both KIVY_GL_BACKEND=gl and KIVY_GL_BACKEND=sdl2 works fine:

[INFO   ] GL: Using the "OpenGL ES 2" graphics system
[INFO   ] GL: Backend used <gl>
[INFO   ] GL: OpenGL version <b'2.1 Mesa 19.2.0-rc1'>
[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 <4096>
[INFO   ] GL: Texture max units <16>

[INFO   ] GL: Using the "OpenGL ES 2" graphics system
[INFO   ] GL: Backend used <sdl2>
[INFO   ] GL: OpenGL version <b'2.1 Mesa 19.2.0-rc1'>
[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 <4096>
[INFO   ] GL: Texture max units <16>

I guess I also wonder about the egl_rpi window provider now. It'd be nice if the wheel supports it for pi < 4, but I'm guessing that could only work if the correct drivers are installed during building and that cannot work for both 3 and 4 in one wheel? Is that correct?

Yes the wheel supports egl_rpi on Pi < 4.

[matham]

If I set USE_X11=1, should I set USE_EGL=1 as well?

I don't think so. Looking at setup.py, it is not normally set for the pi.

Currently sdl2 works on the Raspberry Pi 4. I have not tested sdl2 on the Raspberry Pi 3, only egl_rpi. I can do that tomorrow.

Yes the wheel supports egl_rpi on Pi < 4.

So ideally, there would be a normal window provider that works for pi 1-4, as well as the egl_rpi on Pi < 4. egl_rpi, doesn't count as a normal provider for me because it has such weird touch behaviors. It's more meant when running without any windowing support.

But I suspect that sdl2 can work on pi3 at least (I think I tested it a while ago? maybe with the right drivers). Any hopefully x11 also, assuming xorg or whatever is installed by apt.

[Lauszus]

I can confirm that the wheels works both on Raspberry 1-3 and Raspberry Pi 4 :)

And x11 is enabled as well.

I noticed that you set USE_GSTREAMER=0 for the manylinux wheel. Do you want me to do that as well? Or is that just disabled so it is compatible with manylinux?

[matham]

I can confirm that the wheels works both on Raspberry 1-3 and Raspberry Pi 4 :)

Nice! Is this sdl2 for all of them, or egl_rpi/sdl2?

I noticed that you set USE_GSTREAMER=0 for the manylinux wheel.

That's so that the wheel doesn't become huge when it pulls in gstreamer, for people who don't use video/audio. But that would only happen because on manylinux we use auditwheel to stuff all binary deps into the wheel. For rpi that doesn't happen (in fact people need to run apt commands first), so that's not an issue. But I guess it cannot hurt, since eventually there may be something like manylinux for arm.

[Lauszus]

Nice! Is this sdl2 for all of them, or egl_rpi/sdl2?

All of them support sdl2 and x11 :) egl_rpi only works on Pi 1-3.

Currently Pi 1-3 defaults to egl_rpi and Pi 4 defaults to sdl2.

FYI I have not tested it on Pi 1-2, but assume they work the same as Pi 3.

Next I will look into compiling sdl2 from source, so it does not depend on x11, as it currently does that. This will allows us to set the default window provider to sdl2 for all of them and it will work both on Raspbian desktop and lite without having to install a display manager like nodm on the Pi 4.

That's so that the wheel doesn't become huge when it pulls in gstreamer, for people who don't use video/audio. But that would only happen because on manylinux we use auditwheel to stuff all binary deps into the wheel. For rpi that doesn't happen (in fact people need to run apt commands first), so that's not an issue. But I guess it cannot hurt, since eventually there may be something like manylinux for arm.

Okay. I will set the flags like you have done it for manylinux i.e:

KIVY_SPLIT_EXAMPLES=1 USE_X11=1 USE_SDL2=1 USE_PANGOFT2=0 USE_GSTREAMER=0

[matham]

Also, if you like, it may be nice to make like a table in the docs or just a sentence documenting which of the backends, (or that all of them) work on which pi versions.

Something like:

Window provider (KIVY_WINDOW=)	GL backend (KIVY_GL_BACKEND=)	p1	p2	p3	p4	Install
SDL2	sdl2/gl	?	?	?	y	apt install xxx
X11	gl	y	y	y	y	apt install xxx
egl_rpi	gl	y	y	y	n	drivers xxx

[matham]

Next I will look into compiling sdl2 from source, so it does not depend on x11, as it currently does that

Do you mean for the user or when compiling the wheel on the CI? Because if for the user, you compiling sdl2 on the CI, will not fix that, since they'll get whatever sdl2 they install with their package manager because sdl2 is not included in the wheel.

[Lauszus]

Also, if you like, it may be nice to make like a table in the docs or just a sentence documenting which of the backends, (or that all of them) work on which pi versions.

I updated the documentation in: eaa5113

Do you mean for the user or when compiling the wheel on the CI? Because if for the user, you compiling sdl2 on the CI, will not fix that, since they'll get whatever sdl2 they install with their package manager because sdl2 is not included in the wheel.

Doh, you are right. I'm getting too tired :)

The thing is that I have an application were I would really want to avoid using X11, so I will try to compile SDL2 without the dependency on X11 on a Raspberry Pi 4. I'll update the documentation and send another PR if I figure it out.

[Lauszus]

FYI I'm just going to do a final test, then it should be ready to merge.

[Lauszus]

@matham it should be ready to merge now if you do not have any more comments :)

[matham]

Thanks for your work!

I'll update the documentation and send another PR if I figure it out.

I'm not sure we should add this to the docs because this is likely to be a speciality requirement to not have a x11 dependency? And I'm guessing most people won't be compiling sdl2.

[Lauszus]

I'm not sure we should add this to the docs because this is likely to be a speciality requirement to not have a x11 dependency? And I'm guessing most people won't be compiling sdl2.

I tried to make it work yesterday, but it seems like it would never create a window without using a window manager.