bullseye: Fresh install not working on Pi Zero 2 or Pi 3B

[sapnho]

I just did a fresh install on the latest Raspberry Pi Zero 2 and received the same error message from another user on a Pi 3.

Following the usual instructions, I get this error message:

pi@PiZero2PictureFrame:~ $ picframe ~/picframe_data/config/configuration.yaml
INFO:start.py:starting ['/home/pi/.local/bin/picframe', '/home/pi/picframe_data/config/configuration.yaml']
INFO:model.Model:Open config file: /home/pi/picframe_data/config/configuration.yaml:
Traceback (most recent call last):
File "/home/pi/.local/bin/picframe", line 8, in
sys.exit(main())
File "/home/pi/.local/lib/python3.9/site-packages/picframe/start.py", line 136, in main
c.start()
File "/home/pi/.local/lib/python3.9/site-packages/picframe/controller.py", line 317, in start
self.__viewer.slideshow_start()
File "/home/pi/.local/lib/python3.9/site-packages/picframe/viewer_display.py", line 416, in slideshow_start
self.__display = pi3d.Display.create(x=self.__display_x, y=self.__display_y,
File "/home/pi/.local/lib/python3.9/site-packages/pi3d/Display.py", line 569, in create
display.opengl.create_display(x, y, w, h, depth=depth, samples=samples, layer=layer,
File "/home/pi/.local/lib/python3.9/site-packages/pi3d/util/DisplayOpenGL.py", line 120, in create_display
assert self.context != EGL_NO_CONTEXT and self.context is not None
AttributeError: 'DisplayOpenGL' object has no attribute 'context'

Did anything change with the latest Raspberry Pi operating system release?

[sapnho]

I just tried it on a Pi 3 following my usual instructions: Same error message

Using Raspbian GNU/Linux 11 (bullseye) and the latest version of Pi3D PictureFrame.

picframe -v
INFO:start.py:starting ['/home/pi/.local/bin/picframe', '-v']
picframe version: 2021.11.04

Checking required packages......
PIL : 8.1.2
exifread : 2.3.2
pi3d : 2.49
yaml : 5.3.1
paho.mqtt : 1.6.1
iptcinfo3 : 2.1.4
numpy : 1.19.5
ninepatch : installed, but no version info

Checking optional packages......
pyheif : Not found!

[paddywwoof]

Hi, I'm away this week so can't test of RPi, but that does look odd. I think the previous versions when the RPi was not v4 defaulted to using the broadcom driver but as of Bullseye they default to using KMS (or Fake KMS maybe?). Hopefully there is an option in raspi-config to set the driver back to legacy, otherwise the older versions will have to start using x11 which will slow them down quite a bit.

If you get a chance to see which driver is being used, and if it can be set back to legacy, I'd be interested to know.

Paddy

[sapnho]

Hi @paddywwoof: In the raspi config menu there is still the option to choose legacy.

Is there a command-line way to check which driver is being used to make sure?

[vinyli85]

Hi @sapnho
I did a fresh install on an RPi4 with 64Bit Version of raspbian and I think I got the same error Message. I edited the file /boot/config.txt and changed this line to the following and then everything was working.

# Enable DRM VC4 V3D driver
dtoverlay=vc4-fkms-v3d

Maybe this helps

[sapnho]

Thanks for your suggestion @vinyli85. I just tried that on the Pi 3 but that didn't make it work. But I am glad that it works on the Pi 4.

[vinyli85]

Did you do a reboot After the change? Otherwise there is no effect of the change.

[sapnho]

Did you do a reboot After the change? Otherwise there is no effect of the change.

Yes, I did. And I also tried it on the Pi Zero. The Pi 4 and the Pi 3 apparently have different graphics engines.

[paddywwoof]

Previously the rpi4 had to have that line uncommented but previous versions had to have the hash in front. As I understand it the default in bullseye, ie for the last few days, is that this has changed. It might be that the driver detection as done in DisplayOpenGL or elsewhere now needs to be modified

[helgeerbe]

I installed bullesye today on a spare pi 3B.

I found only one setup, that was working without any issue.

1. In raspi-config set GL driver to full KMS
2. install picframe as root (the pi4 way): sudo pip install picframe
3. in configuration.yaml set use_glx=True
4. start picframe sudo xinit /usr/bin/python3 /home/pi/picframe_data/run_start.py /home/pi/picframe_data/config/configuration.yaml

[sapnho]

Thanks, @helgeerbe, that works indeed. (You also have to change to console login instead of desktop.)
One thing I noticed, the fading is very slow now. Did anybody else see the same?

[helgeerbe]

@sapnho yes, indeed performance is very poor.

Can you try this:

1. In raspi-config set GL driver to full KMS
2. In raspi-config "Advanced Options" and enable "Glamor"
3. install picframe as root (the pi4 way): sudo pip install picframe
4. in configuration.yaml set use_glx=False
5. start picframe sudo xinit /usr/bin/python3 /home/pi/picframe_data/run_start.py /home/pi/picframe_data/config/configuration.yaml

[paddywwoof]

Back now so I will try and find a Pi I can use. As the hardware hasn't changed I'm not sure that the KMS driver will run anything but sluggishly. Hopefully it's just an issue with pi3d not being able to verify that it's running on a Pi 0,1,2 or 3.

If you have a pre-4 RPi you should be able to open a terminal then

$ python3
>>> import pi3d
>>> pi3d.constants.PLATFORM
0

0 is the value of PLATFORM_PI, 3 is the value of PLATFORM_LINUX. So if bullseye is giving a 3 instead of a 0 that means that the code that's trying to find the platform is failing because something has changed in bullseye. As you can see in the code I had to make a few hacks for stretch! I would be interested to hear what you find.

Probably won't do much tomorrow I'm afraid but I will get onto this as soon as possible.

Paddy

[helgeerbe]

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pi3d
>>> pi3d.constants.PLATFORM
3

[paddywwoof]

@helgeerbe, thanks. I forgot to say that 3 will result from having the KMS driver specified, even on an older Pi. To get 0 you need legacy GLES driver.

[helgeerbe]

@paddywwoof, you are right. Then it's 0 So this seems to be OK. But I run into this issue:

Exception has occurred: AttributeError       (note: full exception trace is shown but execution is paused at: _run_module_as_main)
'DisplayOpenGL' object has no attribute 'context'
  File "/home/pi/dev/pi3d/pi3d/util/DisplayOpenGL.py", line 120, in create_display
    assert self.context != EGL_NO_CONTEXT and self.context is not None

The call of

r = openegl.eglChooseConfig(self.display,
                                    attribute_list,
                                    poss_configs, EGLint(len(poss_configs)),
                                    byref(numconfig))

seems to fail. numconfigis 0. So there is no frame buffer.

[helgeerbe]

If I run startx numconfig is 4. But I get libEGL warning: DRI2: failed to authenticate and no images will be rendered.

[paddywwoof]

Yes. Me too. The libGLESv2.so and libEGL.so have moved, names changed and no sign of old ones apart from in /use/lib/chromium-browser/swiftshader/ I will try that if I get the chance

[paddywwoof]

That should be usr. But that gives illegal instruction. I will check out files from buster.

[helgeerbe]

I installed bullseye desktop

pi@raspberrypi:~ $ find / -name libGLES* 2>/dev/null
/usr/lib/chromium-browser/swiftshader/libGLESv2.so
/usr/lib/arm-linux-gnueabihf/libGLESv2.so
/usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0
/usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1
/usr/lib/arm-linux-gnueabihf/libGLESv2.so.2
/usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0

pi@raspberrypi:~ $ find / -name libEGL* 2>/dev/null
/usr/lib/chromium-browser/swiftshader/libEGL.so
/usr/lib/arm-linux-gnueabihf/libEGL.so
/usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0
/usr/lib/arm-linux-gnueabihf/libEGL.so.1.1.0
/usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0.0.0
/usr/lib/arm-linux-gnueabihf/libEGL.so.1

But I linked manually:

libEGL.so -> libEGL.so.1
libGLESv2.so -> libGLESv2.so.2

[paddywwoof]

Yes, also trying bullseye desktop SD but at command line without X. I copied the GLESv2, EGL and bcm_host libraries from buster but ctypes won't load the first two as missing symbols. Annoying thing all round.

[helgeerbe]

You could run apt install libgles-dev libegl-dev

[helgeerbe]

This is the only configuration that works for me with good performance. #195 (comment)

• KMS is now the default on a fresh Raspberry Pi OS Bullseye. Fake KMS is not longer available as an option in raspi-config.
• glamour has to be enabled. Otherwise egl is not working (libEGL warning: DRI2: failed to authenticate)

[paddywwoof]

I've not managed to get pi3d running without X11 on bullseye. With xinit performance is pretty dire on anything other than RPi4

My conclusion is that the Raspberry Pi Foundation aren't really interested in developing the OS for the older versions or without X11 and we should advise users to use the old version of the OS available here There are 20 pages of issues and reports of non-functioning stuff on the RPi forum so this might be something that gets fixed but I somehow doubt it. It's a pity in many ways.

I will carry on searching through the forum to see if anyone has any tips on running OpenGL without X11

[helgeerbe]

@paddywwoof this is exactly what I observed. So I cross my fingers, hoping that there will be significant improvements.

How do you measure the performance? With glamor enabled, I had the impression, that the performance is not so bad at all.

[paddywwoof]

@helgeerbe, When the RPi 4 first came out and the foundation started pushing the new KMS driver I did some test (see here) using bcm with and without desktop and with X11 with and without desktop. I test Pi4, 3 and zero but I can only find a Pi B v 2 so I tested on that and assume it's near or should be better than the zero. The three demos I used were

Billboard now 12.FPS (bcm no desktop 23FPS)
Slideshow now 19FPS (PictureFrame_new bcm no desktop 58FPS, very screen size sensitive)
Shapes now 11FPS (bcm no desktop 19FPS)

On top of this each program takes 40s or so to load which seems a long time, don't have figures from before to hand but the RunTests program leaves 5 to 20s for each program to load and run enough frames to determine if there are any bugs and it was previously fine.

[helgeerbe]

My tests with Billboard on a pi3 B+

- Buster
 - Fake KMS, Desktop: 12.45 fps
 - Legacy, Desktop: 18.30 fps
 - Legacy, Console: 20.36 fps

- Bullsey
 - Full KMS, Desktop: 14.08 fps

[shurushetr]

pi3d having the same problem on pi4 with PiOS 10 and PiOS 11. Fresh install, can't start the picframe.

'pi@phfr:~ $ picframe -i .
Traceback (most recent call last):
  File "/home/pi/.local/bin/picframe", line 6, in <module>
    from picframe.start import main
  File "/home/pi/.local/lib/python3.7/site-packages/picframe/start.py", line 9, in <module>
    from picframe import model, viewer_display, controller, interface_kbd, interface_http, __version__
  File "/home/pi/.local/lib/python3.7/site-packages/picframe/viewer_display.py", line 2, in <module>
    import pi3d
  File "/home/pi/.local/lib/python3.7/site-packages/pi3d/__init__.py", line 10, in <module>
    from pi3d.constants import (USE_PYGAME, PIL_OK,
  File "/home/pi/.local/lib/python3.7/site-packages/pi3d/constants/__init__.py", line 198, in <module>
    PLATFORM, bcm, openegl, opengles = _detect_platform_and_load_libraries()
  File "/home/pi/.local/lib/python3.7/site-packages/pi3d/constants/__init__.py", line 193, in _detect_platform_and_load_libraries
    set_gles_function_args(opengles) #function defined in constants/gl.py
  File "/home/pi/.local/lib/python3.7/site-packages/pi3d/constants/gl.py", line 387, in set_gles_function_args
    gles.glActiveTexture.argtypes = [GLenum] #
AttributeError: 'NoneType' object has no attribute 'glActiveTexture'
pi@phfr:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"'

[paddywwoof]

Hi, that looks like a different error. The loading of libGLESv2.so didn't happen during constants init so the symbol GLES is None.

Did you have pi3d working fine before and just upgraded the OS to the buster legacy? Or might anything else be different in setup? On pi4 you must have Kms graphics driver and be running with X11 up. i.e your listing is from terminal window not cmd line.

[shurushetr]

Hi, that looks like a different error. The loading of libGLESv2.so didn't happen during constants init so the symbol GLES is None.

Did you have pi3d working fine before and just upgraded the OS to the buster legacy? Or might anything else be different in setup? On pi4 you must have Kms graphics driver and be running with X11 up. i.e your listing is from terminal window not cmd line.

Brand new setup, I was following the - https://www.thedigitalpictureframe.com/how-to-set-up-your-raspberry-pi-for-your-digital-picture-frame/
but with pi lite os. Installed x11 and did 6 Advanced Options > A2 GL Driver > Choose G2 GL Fake KMS. I only have 1gb of ram so trying to save some by not running desktop env. I'm able to run x apps, xterm, xeyes on my screen vie HDMI.
Tried to start picframe from xterm -same error. Both Bullseye and Buster (fresh installs).
I assumed that pi3d doesn't even need x11 to run, but I guess I'm wrong.
@paddywwoof - you are correct, I guess it's my setup env. had to manually install missing libs for picframe -h to output no errors.
sudo apt-get install libgles2-mesa libopenjp2-7 libtiff5 libatlas-base-dev

[paddywwoof]

Sadly the old dispmanx Broadcom display manger, that used to provide a display surface OpenGLES could use doesn't work with the new, improved KMS drivers.

You can get the minimal X11 required by pi3d by

sudo xinit /usr/bin/python3 /home/pi/pi3d_demos/Earth.py

Or for picframe using the listing by Helge above #195 (comment)

[helgeerbe]

There is a new legacy (based on buster) image. https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy/

This has long term support.

[sapnho]

Thanks, @helgeerbe This is great that they integrate it into the Raspberry Pi Installer. Will make the changes to the blog post soon.

[sapnho]

Ok, I added some comments https://www.thedigitalpictureframe.com/how-to-set-up-your-raspberry-pi-for-your-digital-picture-frame/ and https://www.thedigitalpictureframe.com/how-to-add-crossfading-slide-transitions-to-your-digital-picture-frame-using-pi3d/.

Buster rulez!

[paddywwoof]

Well done, that seems clear. At some point I might have a go at making the DRM/KMS C code usable from python. It's never a very smooth process so I just keep off looking into it!

[sapnho]

Well done, that seems clear. At some point I might have a go at making the DRM/KMS C code usable from python. It's never a very smooth process so I just keep off looking into it!

That would be interesting to see. Maybe it does even bring some advantages like even smoother fading for large frames? But anyway, we are safe with Buster, that is good to know.

[helgeerbe]

I haven't tested bullseye with a pi4. How good/bad is the performance compared to buster?

[sapnho]

I haven't tested bullseye with a pi4. How good/bad is the performance compared to buster?

I don't have a spare Pi 4 at the moment (they are really hard to get these days!), so I can't run a test, unfortunately.

[OliverJennrich]

Thanks, @helgeerbe, that works indeed. (You also have to change to console login instead of desktop.) One thing I noticed, the fading is very slow now. Did anybody else see the same?

Just to chime in because I just got picframe working on my Raspberry Zero 2W with the solution provided by @helgeerbe - crossfading seems to take more or less the time it is configured (10s) - I haven't tried anything faster than that, though. Smooth fading no jerking or jumping.

[paddywwoof]

Thanks @OliverJennrich

I think, with Glamor enabled, the 'heavy weight' Cortex-A53 and Cortex-A72 RPis can cope with the extra work of running X11 at the same time without slowing down too much. However I think the older Cortex-A7 or ARM1176 will struggle and need to stick to buster