Compatibility with Raspberry Pi Zero 2

[p3p1]

trafficstars

Apparently the driver does not work properly with Raspbian Bullseye on Raspberry Pi Zero 2. Indeed the screen just flash during the boot for few seconds (with Raspbian boot logo) and it turns to blank. If after the boot I try to launch demo.py or clock.py with following command sudo SDL_FBDEV=/dev/fb0 python3 clock.py I got the following and blank screen:

pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Driver "rpi" failed: No available video device
Driver "kmsdrm" failed: No available video device
Using driver: fbcon, Framebuffer size: 720 x 480

I also verified i2c connection through sudo i2cdetect -y 11 output:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

The screen works flawlessly on Rasp Pi 3 B+ (Raspbian Buster)

Small Update: it works with Rasp Pi Zero 1.2 (Raspbian Buster)

[F1p]

I have this working on Pi Z 2 running 32bit bullseye,

Please check GL Driver is set to Legacy by running sudo raspi-config > Advanced Options > GL Driver > G1 Legacy

The default GL (Full KMS) driver doesn't seem to work.

[Gadgetoid]

All of our display products need kms panel drivers, so full support on Bullseye is probably not going to happen this side of next year. It's a lot of work (plus a lot of depending upon other people to approve, merge and release changes) and there's only one of me.

[p3p1]

All of our display products need kms panel drivers, so full support on Bullseye is probably not going to happen this side of next year. It's a lot of work (plus a lot of depending upon other people to approve, merge and release changes) and there's only one of me.

Maybe it is worth to mention the limited capabilities with Bullseye on the vendor page

[helgibbons]

I've added some notes about Bullseye compatibility to the Hyperpixel shop pages.

[dotMorten]

Any progress update on bullseye support? I'm not getting my zero2 to run a stable arm64 build of Buster, and would really like to have touch support on bullseye

[sherpa003]

any update about Bullseye support? I'm really confused about it. It shows something only with legacy GL driver but all examples display only on top half of the screen and duplicated (left and right). On the other hand https://github.com/pimoroni/hyperpixel4 says the hyperpixel drivers are baked into the system. Is that true only for the hp4 and not hp2r? What is the recommended way forward as of 2023Q4?

[a1ecbr0wn]

I have this working on Pi Z 2 running 32bit bullseye,

Please check GL Driver is set to Legacy by running sudo raspi-config > Advanced Options > GL Driver > G1 Legacy

The default GL (Full KMS) driver doesn't seem to work.

This solved things for me, why does the default install not set this or mention it in the README?

[tomblackshaw]

All of our display products need kms panel drivers, so full support on Bullseye is probably not going to happen this side of next year. It's a lot of work (plus a lot of depending upon other people to approve, merge and release changes) and there's only one of me.

If someone paid for the implementation of Bullseye support for this hardware, would that make a difference?

[Gadgetoid]

If someone paid for the implementation of Bullseye support for this hardware, would that make a difference?

Regrettably I’ve still not found a way to turn money into time.

That said, HyperPixel 2 Round at least has “dtoverlay=vc4-kms-dpi-hyperpixel2r” which gets the display up and running.

Unfortunately the hardware - made for a time when display timings were mangled into config.txt on the Pi and display init was a standalone script - is incompatible with the modern Linux mainline approach.

This could maybe be worked around by removing display init from the panel driver and making it a script which loads a touch dtoverlay when it’s done…🤔

curses that’s a real nerd snipe challenge 😭

[theschles]

If someone paid for the implementation of Bullseye support for this hardware, would that make a difference?

Regrettably I’ve still not found a way to turn money into time.

That said, HyperPixel 2 Round at least has “dtoverlay=vc4-kms-dpi-hyperpixel2r” which gets the display up and running.

Unfortunately the hardware - made for a time when display timings were mangled into config.txt on the Pi and display init was a standalone script - is incompatible with the modern Linux mainline approach.

This could maybe be worked around by removing display init from the panel driver and making it a script which loads a touch dtoverlay when it’s done…🤔

curses that’s a real nerd snipe challenge 😭

Please, if that'll work, do it! 💪