Doesn't work on anything other than stock Raspberry OS, please fix

[phalkon13]

IT seems like the packages required are only available if you install stock Raspberry OS. I tried installing this on the 1.5 build of Pimiga (which I believe is Raspberry Pi OS lite) as well as multiple builds of Kali Linux. On Pimiga, it will bring up the screen, but it is in the wrong orientation, and your rotate command fails, stating that the command code is incorrect. In Kali Linux, it either won't even install, or if it does, it then locks up on boot after install.
Please add a list of repos and packages required to successfully install this software, so that if someone is installing this on a different OS than Raspbian/RPiOS, it will function properly.

Addendum: Just to test, I installed RPiOS stock, and installed the HP4.0 right after, and it worked great (except touch was backwards), but after installing the Katoolin packages that are available, the HP4.0 does not work at all. The curl command goes through, the the screen stays backlit black.
I also tried waiting until installing all of the Katoolin packages before installing the screen, and it immediately just goes backlit black screen.

[Gadgetoid]

There simply aren't enough hours in the day for me to test and ship support for all permutations of packages and OS variants on the Pi- there are so many that you've already managed to mention one distro that - in 8 years of this stuff - I haven't even heard of.

Generally the only thing truly required for HyperPixel display is to enable the Pi's DPI output in 18-bit mode using the config.txt settings. The dtoverlay handles bringing up the relevant touch driver and will usually need built against your running kernel.

For example, HyperPixel 2.0 Rectangular on a Pi 4 would use something like:

dtoverlay=hyperpixel4
enable_dpi_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x7f216

In /boot/config.txt and then depending on whether or not you're using 3D acceleration you'll need a compositor capable of rotation (or an app capable of rotation), or otherwise use the display_rotate setting.

The rotate tool is just a convenience wrapper around the Raspberry Pi display configuration tool (screenlayout) which is, itself, just a wrapper around xrandr which is just the "Resize and Rotate" tool for X.

While I agree a list of requirements or step-by-step install instructions might be helpful, they may always be incomplete. Sooner or later the list just ends up as "install Raspberry Pi OS" since there are so many gotchas.

[Gadgetoid]

Added some generic Xorg configuration instructions in cf175cc

[Gadgetoid]

Working on the ability to save out a basic Xorg configuration for non-Raspberry-Pi-OS distributions that still use X and don't have the xrandr/lightdm configuration that we usually depend on:

236fb21

[Kabouik]

Thank you for your efforts towards making this screen more generic across distributions. Just to be sure as I'm about to order one, would the Hyperpixel 4 work on an x64 machine running Debian (where xrandr is available) and having Pi-compatible pins (I'm thinking about the Seeedstudio Odyssey X86J4125)?

[Edit] Note that apparently the Odyssey SBC doesn't support I2S (not sure if they meant I2C there) yet: https://forum.seeedstudio.com/t/are-40-pin-screens-for-raspberry-pi-compatible/261574/3 Does that mean the Hyperpixel 4 can't work on this machine until they implement I2S support?

[Gadgetoid]

i2s is audio, i2c is data so it should have no bearing on compatibility.

There's almost no chance the Odyssey SBC or any other random SBC supports DPI in the same configuration across the same pins as the Pi. Only Seeed could really elaborate upon this.

[Kabouik]

i2s is audio, i2c is data so it should have no bearing on compatibility.

Thanks for the answer. Yes, that's what I found later but it's good to have your confirmation.

There's almost no chance the Odyssey SBC or any other random SBC supports DPI in the same configuration across the same pins as the Pi. Only Seeed could really elaborate upon this.

That I don't understand. These are the pins of the Odyssey SBC. Are they not exactly the same as the Pi pins?

[Gadgetoid]

Are they not exactly the same as the Pi pins?

Very, very superficially yes. For anything non-trivial - like GPU-based DPI (Display Parallel Interface) support - you're out of luck.

RPi's GPIOs have up to six alt modes that are - afaik - not replicated by any "pin compatible" SBC. See: https://elinux.org/RPi_BCM2835_GPIOs

[Kabouik]

Thank you very much for the detailed answer. I think it's pretty clear then that no pin-based display would work for the Odyssey, since the vast majority of pin displays are designed around the Pi models. I'll have to focus on HDMI displays then.

Great screen though, wish I could have used it!

[Gadgetoid]

SPI displays should work but driver support is spotty and a lot of the nice utilities for mirroring framebuffers are very Pi-specific 😬

HDMI is definitely the path of least resistance. I wish we'd do a little HDMI display and smol cable. So much less hassle 😆

[Kabouik]

You're giving me some hope again! It is not clear to me which utilities I would miss because I have never used SPI displays so don't know what are the limitations and how the driver help working around them. My understanding is it's not really plug-and-play, so I assume rotation would be difficult if not all utilities work on the SBC, and maybe the orientation of the touch matrix too? Also, I am not sure if SPI displays can be combined with HDMI displays to make multi-monitor setups within the OS, or whether they are completely separate things.

My concern is the one-liner installation script you developed may not work at all, partly because, as you said, the pins won't be an exact match with those of a Pi, and also because the Odyssey SBC is an x64 architecture and may lack dependencies in Debian if they have been compiled only for the Pi. Another concern, but that one is not related to this issue on distribution compatibility, is I couldn't find what voltage the Pimoroni SPI displays require. Apparently the Odyssey IO voltage is 1.8V.

[Kabouik]

HDMI is definitely the path of least resistance. I wish we'd do a little HDMI display and smol cable. So much less hassle laughing

To end the hardware off-topic I started (sorry), wouldn't this solve my first issue by making the Hyperpixel4 an HDMI display (and hence hardware agnostic), even on x86_64? This would bring me back on topic in this issue since I would like to use it on Debian Bullseye.

[Gadgetoid]

There's some upstream - at least to Pi's Linux fork - support for HyperPixel 4 and HyperPixel 4 Square now available in Raspberry Pi OS. It may take some time, but I'd expect this to trickle over to other distributions and start to smooth over the issues.

@Kabouik I don't know if the linked board would work with HyperPixel. It would certainly be a pain to set up.

Hopefully once the mentioned distros get updated the instructions in #177 will apply.

[Kabouik]

Thanks a lot for the clarification on compatibility with that specific board @Gadgetoid!