Perform RPi builds on balenalib/raspberrypi3-* images and skip DISPMANX API usage if can't be used [build wheel armv7l]

[misl6]

Maintainer merge checklist

• Title is descriptive/clear for inclusion in release notes.
• Applied a Component: xxx label.
• Applied the api-deprecation or api-break label.
• Applied the release-highlight label to be highlighted in release notes.
• Added to the milestone version it was merged into.
• Unittests are included in PR.
• Properly documented, including versionadded, versionchanged as needed.

• The previous artifacts for RPi on buster-3.7 were not working due to an incompatibility on GCLIB.
• The previous artifacts for RPi on bullseye-3.9 were not working due to missing features (during the build we were manually downloading raspberry-specific libs and headers which are not available on bullseye-3.9)

Now, cross-builds are performed on balenalib/raspberrypi3-debian-python:3.7-buster and balenalib/raspberrypi3-debian-python:3.9-bullseye. That allows us to have almost the same environment which is available on a real RPi with Raspbian.

Additionally, since DISPMANX is not available on Raspbian Bullseye, we should check if it's usable, even if we're on an RPi. For this reason, on setup.py a new helper method check_c_source_compiles has been added.

As DISPMANX is not available on Raspbian Bullseye, vidcore_lite support is missing on the cp39 artifact. In the future (2.3.0 ?), we will need to add support for DRM instead.

⚠️ I performed the tests over a VNC session on a Raspberry Pi 3 without a display attached. For that reason, I needed to circumvent an issue manually (Can't create window since it couldn't find matching GLX visual).
Would be nice to test the artifacts on an RPi which is attached to a display, before the final 2.2.0 release.

[Gobbel2000]

I was able to test the armv7 wheels from this PR on a Raspberry Pi 4 with the 32-bit Raspberry Pi OS releases based on Debian Buster and Bullseye.

Under Bullseye everything went pretty well: On the lite OS version only the packages libgl1-mesa-glx libgles2-mesa libmtdev1 libegl1-mesa had to be installed in order to run some of the examples (mainly demo/showcase). This was possibly directly from the tty or SSH. Doing the same inside X11 worked just as well.

I tried to do the same with the cp37 wheel on the legacy Raspberry Pi OS based on Debian Buster. When running from outside any graphical environment again it started and displayed fine but I was having issues with input, where button presses sometimes wouldn't register or would appear to stick after releasing. The behavior was the same with a touchpad (using mtdev) as with a mouse. It is possible that I'm missing some configuration or proper libraries, but I haven't encountered this with previous kivy versions.

When running the same with X11 the input worked just as expected.

In all cases hardware acceleration was used (OpenGL renderer <b'V3D 4.2'>).

[misl6]

Hi @Gobbel2000,

Thank you for the detailed report!

I tried to do the same with the cp37 wheel on the legacy Raspberry Pi OS based on Debian Buster. When running from outside any graphical environment again it started and displayed fine but I was having issues with input, where button presses sometimes wouldn't register or would appear to stick after releasing. The behavior was the same with a touchpad (using mtdev) as with a mouse. It is possible that I'm missing some configuration or proper libraries, but I haven't encountered this with previous kivy versions.

I will take a look at issues, to see if someone else reported the same behavior, otherwise, I will open one. (hopefully, I will be able to grab an RPi soon [shortages are not fun 😀], in order to perform some additional tests)