pimoroni/hyperpixel4

PSA: HyperPixel 4 (Square & Rectangular) on Raspberry Pi OS 64bit 2022-04-04

Gadgetoid opened this issue · 108 comments

ℹ️ See this comment for rotation in Raspberry Pi Desktop screen configuration - #177 (comment)

⚠️ PSA: Make sure you disable i2c, SPI and any other interfaces since these will cause a conflict in device-tree with HyperPixel ⚠️

⚠️ A fresh image is recommended, but otherwise make sure you also disable the hyperpixel4-init system service! ⚠️

Pi 3B and Pi 4 users running the latest and greatest Raspberry Pi OS should forego our installer and use the instructions below.

ℹ️ If you're tied to an older OS and you want to install the legacy drivers, use:
curl -sSL get.pimoroni.com/hyperpixel4-legacy | bash

This new OS can currently be found in Raspberry Pi Imager under "Raspberry Pi OS (Other)"

image

Once installed you need only one line in /boot/config.txt:

  • Rectangular: dtoverlay=vc4-kms-dpi-hyperpixel4
  • Square: dtoverlay=vc4-kms-dpi-hyperpixel4sq

You can rotate these in config.txt by adding the rotate= parameter, like so:

dtoverlay=vc4-kms-dpi-hyperpixel4sq,rotate=90

This supports rotation in console, too, for all you CyberDeck builders!

HyperPixel 4 Rectangular Rotations

Ensure rotation is set to "Normal" in "Display Configuration"

And that the dtoverlay is in /boot/config.txt:

dtoverlay=vc4-kms-dpi-hyperpixel4

Finally use one of the following dtparam lines immediately underneath to set the parameters:

  • The default is portrait with header on the right, no extra line needed
  • dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y - Landscape with header on the bottom
  • dtparam=rotate=180 - Portrait with header on the left
  • dtparam=rotate=270,touchscreen-swapped-x-y,touchscreen-inverted-x - Landscape with header on the top

HyperPixel 4 Square Rotations

HyperPixel 4 Square does not correctly swap or invert touch input, so you may want to use the Xorg config method below.

Ensure rotation is set to "Normal" in "Display Configuration"

And that the dtoverlay is in /boot/config.txt:

dtoverlay=vc4-kms-dpi-hyperpixel4sq

Finally use one of the following dtparam lines immediately underneath to set the parameters:

  • Default is header on the top
  • dtparam=rotate=90 - Header is on the left (wonky touch, see below)
  • dtparam=rotate=180 - Header still on the top (doesn't work? Same as default)
  • dtparam=rotate=270 - Header is on the right (wonky touch, see below)

⚠️ The touchscreen-swapped-x-y parameter does not seem to work with Square. You may need to use the script below for Raspberry Pi OS with Desktop.

On the fly rotation

Rotating the display via "Screen Configuration" ("arandr") results in inverted touch input and other weirdness- use the dtoverlay params.

If you want to rotate on the fly you can use the below bash script to rotate either display and persist settings into Xorg configuration files.

⚠️ Note: You must remove the rotate= argument from /boot/config.txt for these to make sense.

You can remove the rotation config by deleting the /usr/share/X11/xorg.conf.d/88-hyperpixel4-touch.conf and /usr/share/X11/xorg.conf.d/88-dsi-1-rotate.conf files.

#!/bin/bash

UTILITY="hyperpixel4-rotate (Rectangular)"
XORG_TOUCH_CONF_FILE="/usr/share/X11/xorg.conf.d/88-hyperpixel4-touch.conf"
XORG_CONF_FILE="/usr/share/X11/xorg.conf.d/88-dsi-1-rotate.conf"

OVERLAY_S="vc4-kms-dpi-hyperpixel4sq"
OVERLAY_R="vc4-kms-dpi-hyperpixel4"

function success() {
    echo -e "$(tput setaf 2)$1$(tput sgr0)"
}

function inform() {
    echo -e "$(tput setaf 6)$1$(tput sgr0)"
}

function warning() {
    echo -e "$(tput setaf 1)$1$(tput sgr0)"
}

function set_xorg_conf {
    if [ "$DISPLAY" == "" ]; then
        inform "No DISPLAY variable set, trying :0.0"
        export DISPLAY=:0.0
    fi

    inform "Rotating display $1";
    xrandr --output DPI-1 --rotate $1

    MATRIX="$2 $3 $4 $5 $6 $7 $8 $9 ${10}"

    inform "Setting libinput Calibration Matrix: 1 0 0 0 1 0";
    xinput set-prop "pointer:$DEVICE" "libinput Calibration Matrix" 1 0 0 0 1 0 0 0 1

    inform "Setting Coordinate Transformation Matrix: $MATRIX";
    xinput set-prop "pointer:$DEVICE" "Coordinate Transformation Matrix" $MATRIX

    inform "Saving xorg touch config to $XORG_TOUCH_CONF_FILE";
    sudo tee $XORG_TOUCH_CONF_FILE > /dev/null <<EOF
# Auto generated by $UTILITY, edit with care!

Section "InputClass"
    Identifier "HyperPixel4 $DEVICE"
    MatchProduct "$DEVICE"
    Option "CalibrationMatrix" "1 0 0 0 1 0 0 0 1"
    Option "TransformationMatrix" "$MATRIX"
EndSection
EOF

    inform "Saving xorg rotate config to $XORG_CONF_FILE";
    sudo tee $XORG_CONF_FILE > /dev/null <<EOF
# Auto generated by $UTILITY, edit with care!

Section "Monitor"
    Identifier "DPI-1"
    Option "Rotate" "$1"
EndSection
EOF
}

printf "HyperPixel 4: Display & Touch Rotation\n"
printf "This utility requires the Raspberry Pi OS desktop or an *Xorg-based* alternative.\n\n"

ORIENTATION=$1

grep -e "^dtoverlay=$OVERLAY_S.*" /boot/config.txt > /dev/null
if [ $? -ne 0 ]; then
    grep -e "^dtoverlay=$OVERLAY_R.*" /boot/config.txt > /dev/null
    if [ $? -ne 0 ]; then
        warning "Rotation requires hardware support on the Pi 4 or Pi 400"
        warning "Ensure your HyperPixel4 is enabled in /boot/config.txt"
	printf "\nSquare:      dtoverlay=$OVERLAY_S\n"
	printf "Rectangular: dtoverlay=$OVERLAY_R\n\n"
        exit 1
    else
        inform "Detected HyperPixel 4 Rectangular (found \"$OVERLAY_R\" in config.txt)"
        DEVICE="Goodix Capacitive TouchScreen"
    fi
else
    inform "Detected HyperPixel 4 Square (found \"$OVERLAY_S\" in config.txt)"
    DEVICE="EP0110M09"
fi

case $ORIENTATION in
    "right")
        set_xorg_conf $ORIENTATION 0 1 0 -1 0 1 0 0 1
        ;;
    "left")
        set_xorg_conf $ORIENTATION 0 -1 1 1 0 0 0 0 1
        ;;
    "inverted")
        set_xorg_conf $ORIENTATION -1 0 1 0 -1 1 0 0 1
        ;;
    "normal")
        set_xorg_conf $ORIENTATION 1 0 0 0 1 0 0 0 1
        ;;
    *)
        printf "Unsupported orientation: $ORIENTATION\n\n";
        printf "Usage:\n"
        printf "    $0 <orientation>\n\n"
        printf "Where orientation is one of: left, right, normal, inverted.\n"
        exit 1
esac

This is almost working for me: it only works in the non-rotated orientation on boot.

I bought my HyperPixel 4 Rectangular a month ago to use with a Pi 400 & Adafruit’s Cyberdeck HAT. I removed the diode on the HAT, and then ran into a black screen (backlight but no picture), and found some of the issues linked above. I was really happy to see this update.

With only dtoverlay=vc4-kms-dpi-hyperpixel4 in /boot/config.txt it’ll boot and display, albeit rotated 90° clockwise. This is working well, as far as I can tell.

If I try to use either ,rotate=270 appended to the dtoverlay line or the separate dtparam line that includes the touchscreen options, the display doesn’t work.

If I remove the rotation settings from /boot/config.txt and try to use the embedded script (xrandr, etc), it works on that particular session. When I reboot, it breaks.

The failure looks like either a black screen, or a screen where one pixel (the first??) in each row is repeated all the way across the screen (the latter seems to be more common, but I’m not sure). I haven’t been able to determine when each behavior is triggered.

I’ve been trying both with an HDMI monitor connected, and also with only the hyperpixel (aka DP1) and changing config over ssh. There may be behavior differences, but neither setup is working correctly.

Is there helpful information I can gather, either for this issue or to file a new one? Sometimes, but not always, there’s a register + call trace dump visible inside of dmesg output, related to the goodix_ts_driver. I’ve captured several sets of dmesg logs, but didn’t keep any notes on what the particulars of each were 😞

Could you paste the lines you have in your config.txt when you're trying to get rotation work? Would help me to recreate.

Weird, same config and same SD card in my Pi 3B+ versus my Pi 4 results in two different rotations...

😱

Edit (For posterity and to nobody in particular):

I have a suspicion that "/usr/share/dispsetup.sh" did this. It's the script that gets updated by Screen Configuration (arandr) and then run on boot via lightdm.conf.

There's also a .config/monitors.xml which I guess used by Mutter on Pi 4? Screen Configuration also updates this file, but manually editing it to different rotations doesn't seem to affect my display setup. which is for Gnome and unrelated to the Pi config afaict.

And any touch or rotation dropped into /usr/share/X11/xorg.conf.d/ can potentially cause issues, too.

I've tried three different /boot/config.txt variations. Full contents, summary of changes from default:

dtoverlay=vc4-kms-dpi-hyperpixel4
dtoverlay=vc4-kms-dpi-hyperpixel4,rotate=270
dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=270,touchscreen-swapped-x-y,touchscreen-inverted-x

I have an (occasionally) working setup with the first one (no parameters to the overlay), and having run the bash script you provided 🎉 After having ran that bash script, I haven't deleted / reset those settings to go back to a dtoverly + dtparam only solution.


Unfortunately, sometimes it fails. I thought the failure was deterministic, but I don't think that's true. I've seen three different failure modes:

  • A black screen. The backlight is on and the OS knows a display is connected, but nothing is being drawn.
  • One pixel repeated all the way across the screen, maybe skipping every other column? Here's a brief video, in which I move the mouse, and then touch & drag (and the selection rectangle it should be displaying also causes colors to change):
IMG_1856.mov
  • every other (I think?) column is skipped, and it throws off the locations of touches:
IMG_1851.mov
  • initially I was also trying to get multi-monitor to work (mostly so I had an attached display I could use while fiddling with the hyperpixel4). I observed touches on the hyperpixel being interpreted as happening within the bounds of the HDMI display

I have seen all three display failure modes in each of these cases:

  • on a cold boot (as usb-c cable initially plugged in), a software-based reboot (command line or GUI), and a boot using the pi400 power key (after a software-based shutdown command)
  • with multiple monitors, with the hyperpixel as the primary and not the primary (configured through arandr since I don't know xrandr well).
  • with only the hyperpixel plugged in (I've done most of my testing like this)

I haven't figured if there's a configuration/sequence that always fails, nor do I know if one is more likely to succeed. ex: I thought cold boot was pretty reliable yesterday, but so far today it's failed 3 out of 4 times. Similarly, my initial assertion that it only worked non-rotated on cold boot could have just been random good luck across 3-4 attempts.


Here's an example of the Goodix-TS failure logs from dmesg: dmesg-goodix-failure.txt

My guess is that the TS is for touch screen. I don't know if this is a red herring / unrelated. It's not always there when the display fails to work.


Late additions:

  • the screen is inverted in the horizontal direction:
    IMG_1857

  • inverted with some columns missing:
    IMG_1858

  • looks like every other column is white instead of black?
    IMG_1859


environment:
Pi 400

$ uname -a
Linux pi400 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux

apt says it's fully up to date, and as far as I can remember the only significant thing I've really done with this device / SD card was run the old hyperpixel4 script. I'd be willing to wipe & re-image if you want.

There's a good chance the old hyperpixel script will break this in ways I can't imagine, but it should suffice to run:

sudo systemctl disable hyperpixel4-init.service

It could easily be this init script half-working that's messing up the display.

Also make sure nothing from the legacy installer is in config.txt.

A wipe and re-image is probably the safest bet though, the old installer is fundamentally a bunch of nasty hacks based around the old config.txt way of setting up DPI.

There's a good chance the old hyperpixel script will break this in ways I can't imagine, but it should suffice to run:

sudo systemctl disable hyperpixel4-init.service

It could easily be this init script half-working that's messing up the display.

Also make sure nothing from the legacy installer is in config.txt.

That seems to have done it 🎉 🎊

I feel dumb/embarrassed 😞 I'd previously found and reverted the /boot/config.txt changes, and looked through the installer script for other config files that might have been changed, but didn't find the service to disable.

Thanks so much for the help!

Howdy so I just installed this on a fresh OS install (April 4th 2022 64 bit on a Pi 4) and I get a blank white display. Using the square display.

Nevermind! My issue was that I had removed dtoverlay=vc4-kms-v3d which caused the display to not work correctly.

Nevermind! My issue was that I had removed dtoverlay=vc4-kms-v3d which caused the display to not work correctly.

No worries. Useful to know exactly how this fails for future reference!

Should this work with the 2020-and-earlier version of the hyperpixel4sq on a Pi3b+? I tried both the 64bit and 32bit builds of Bullseye, released 2022-04-04. I get what appears to be vertical stripes in both cases. It doesn't seem to matter if hdmi is connected or not. If hdmi is connected, then I get a very low resolution desktop on hdmi. Both installs are fresh, plain installs, and the only change I made was to add "dtoverlay=vc4-kms-dpi-hyperpixel4sq" to the end of /boot/config.txt

Should this work with the 2020-and-earlier version of the hyperpixel4sq on a Pi3b+? I tried both the 64bit and 32bit builds of Bullseye, released 2022-04-04. I get what appears to be vertical stripes in both cases. It doesn't seem to matter if hdmi is connected or not. If hdmi is connected, then I get a very low resolution desktop on hdmi. Both installs are fresh, plain installs, and the only change I made was to add "dtoverlay=vc4-kms-dpi-hyperpixel4sq" to the end of /boot/config.txt

Youch- that's a good question, to which the answer is: no. They require - iirc - very different configurations and bringup. That's something I'm going to have to look into. I had forgotten there were two flavours of Square 😬

Thanks! If you would like me to test anything, let me know.

This new version does not work on my Pi Zero 2 W, the screen is just blank - my dtoverlay is:

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-hyperpixel4sq

confirmed that the screen works fine on the prior install (with the script config). Is there anything else that I need to configure?

I have done a clean SD card wipe and reinstall on a Pi 400 and I am now getting a blank screen even after adding the new dto in the config.txt.

It was working on my existing installation which had the legacy drivers installed previously. I disabled the legacy service, but I also removed the old hyperpixel.dto. Once I did that and rebooted, the display stopped working. At that point I flashed the new OS to see if that would work.

This is a completely vanilla install with nothing done other than an apt update.

sudo cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
dtoverlay=vc4-kms-dpi-hyperpixel4
#,rotate=270
#,touchscreen-swapped-x-y,touchscreen-inverted-x



# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]

Top Gear Top Tip: i2c and spi both need to be commented out/disabled.

Top Gear Top Tip: i2c and spi both need to be commented out/disabled.

Ooof. I did not spot that. Thanks for reporting it back here!

I tend to fall into the false assumption that - like the old config.txt magic setup method did - the DPI display will trump anything else, but with device-tree it'll throw a pin conflict instead. 😬

Annoyingly, I had rotation working on my Pi4 with the rectangular screen. Filesystem died and I rebuilt and now it doesn't work. The difference being that I'm now running Raspian OS Lite. Do we need X to have the rotation work?

For some reason I can't get chromium in kiosk mode to display properly (landscape), boot and without chromium is fine. I'm using a PI Zero 2 W and a rectangle screen. Any ideas what i'm missing?

Annoyingly, I had rotation working on my Pi4 with the rectangular screen. Filesystem died and I rebuilt and now it doesn't work. The difference being that I'm now running Raspian OS Lite. Do we need X to have the rotation work?

@LazLong Yes. Or your application must support rotation somehow. This is a frustrating consequence of RPi's move to upstream blessed methods of supporting DPI displays. You can fall back to legacy drivers and the config.txt method, but that has its own tradeoffs.

@Jeroennl as above, there's no hardware rotation in the new drivers and no config.txt setting will affect display rotation. If Kiosk mode chromium uses X under the hood you should be looking at xrandr and xorg config. See the script in my original post.

@brotherlogic if you haven't done a fresh install, one is highly recommended. Make sure "hyperpixel4-init" or other services aren't running at startup and breaking things.

There are also, IIRC, two versions of HyperPixel 4 Square (pre and post 2021) which are not compatible with each other. If you have an older display it's very likely these drivers don't work with it. That's something I need to follow up on.

@Jeroennl as above, there's no hardware rotation in the new drivers and no config.txt setting will affect display rotation. If Kiosk mode chromium uses X under the hood you should be looking at xrandr and xorg config. See the script in my original post.

@Gadgetoid Fixed it using xrandr, thnx!

Top Gear Top Tip: i2c and spi both need to be commented out/disabled.

Ooof. I did not spot that. Thanks for reporting it back here!

I tend to fall into the false assumption that - like the old config.txt magic setup method did - the DPI display will trump anything else, but with device-tree it'll throw a pin conflict instead. 😬

Please add this to the top of this PSA post. I just lost 2 hours trying to find out why my display apparently stopped working when I applied a rotate setting. But it was because I had also enabled i2c for the same reboot while doing initial set up from the refresh OS image. This might also be why the display did not appear to work on my original CM4 hardware stack.

@Footleg story of my life! Duly noted and warnings added.

I can now confirm my 2019 era Hyperpixel4 rectangular with touch is working on my CM4 mounted on a Waveshare carrier board. I discovered the i2c bus mapped to 22, rather than 3 as told here https://learn.pimoroni.com/article/getting-started-with-hyperpixel-4#using-the-alternate-i2c-interface-on-hyperpixel-4-0-for-advanced-users so maybe a quick update to that article to mention you can see which bus numbers are active using the command ls /dev/i2c-* (as I learned from this comment: #122 (comment) ).

Note that when rotating the display using the console, the touch does not map to the rotated display. It also does not map to the correct display when a second display is attached to the HDMI output either. I've not looking into options to deal with that yet, but at least I am up and running now.

After doing the instructions exactly as described here and looking thru all the comments on everything that could be wrong, I still cannot get this working. I get a black screen. Nothing else. Any ideas?

Hello, I spend few days tryed everything, and I wasnt able to make it working again, just reinstalled my some old Octoprint with octodash and want to move to mainsail klipper, also tryed all 32bit and 64bit version of great awesome Raspberry Pi OS 64bit 2022-04-04 bullseye and nothing, i can get some picture when i set dtoverlay=vc4-kms-dpi-hyperpixel4sq or some weird desktop picture after display wakeup after sleep ... just rpi console then only ugly lines :(

all what i have:

  • hyperpixel4
  • rpi 3b
  • rpi 4b with 4gb ram
  • 32gb sandisk extreme card
  • original power supply Raspberry Pi USB-C 5,1V3A

I will try all to test what is wrong! Because it working before ... :(

I'm having zero luck with rotation in any direction, I've disable I2C, SPI, edited the config.txt according to the notes above and zero luck. Has anyone worked it out?

I'm having zero luck with rotation in any direction, I've disable I2C, SPI, edited the config.txt according to the notes above and zero luck. Has anyone worked it out?

This worked for me as per the instructions at the top of this page with a fresh Raspberry Pi OS image (Bullseye). You do need the latest (use apt to upgrade everything if on an older Bullseye release). Check you are on Bullseye (it lists the repos being used when you run sudo apt update).

J4CY commented

Edit: I contacted Pimoroni support and was told the screen was indeed defective.

Hi all, I'm new to the HyperPixel 4.0 and RPI. I've got an RPI 4B w/ 2GB with Raspberry Pi OS 64bit bullseye installed.

Installed the screen and applied the following to /boot/config.txt.

dtoverlay=vc4-kms-dpi-hyperpixel4 
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Rotation and touch are all working as expected, but I am noticing screen tearing of some sort on this specific side of the screen. I've tried other rotations and they all seem to have the same effect. Is this expected, a software bug, or potentially a hardware issue? I've attached some videos to demonstrate my issues.

Untitled.1.mp4
Untitled.2.mp4

Edit: Also gave Buster a shot and installed the drivers, screen and touch works, but still has the tearing on the same side of the screen.

I'm having zero luck with rotation in any direction, I've disable I2C, SPI, edited the config.txt according to the notes above and zero luck. Has anyone worked it out?

This worked for me as well booting into terminal. For the rotation to work in X, I had to rotate left.

I am totally editing out my previous post and putting in the notes for my ultimate goal: Making a Pi4 work with a rectangular HyperPixel 4 (bought in 2022) with OctoPrint/OctoDash connected to a Prusa MK3S+, with a clean/new install in January 2023. This means that the USB ports stick out to the right (power out of the bottom) so that the Pi can be mounted into a new display panel on the front of the Prusa.
https://forum.prusa3d.com/wp-content/uploads/2021/07/01-600x500.jpg

I got some good help from here (hint: use "Alternate Step 2"). Rotation was good, but touch screen parameters were wonky.
https://github.com/TxBillbr/octodash-hyperpixel-fix

With some testing of various x-y parameters, everything is working now. Here's the process I think folks can follow to arrive at my same config:

- This will get the display semi-functional:
sudo apt install git
git clone https://github.com/pimoroni/hyperpixel4 -b pi4
cd hyperpixel4
sudo ./install.sh
sudo reboot now

- Edit your /boot/config.txt file to look like below The "modded" comment areas below are the ones I believe I changed, but this is a direct copy/paste from my working config. Everything else that appeared earlier in the config.txt file was unchanged.
[pi4]
#Enable DRM VC4 V3D driver on top of the dispmanx display stack
#modded to comment out the line below
#dtoverlay=vc4-fkms-v3d

max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
#enable raspicam
start_x=1
gpu_mem=128

#modded - original just had "dtoverlay=hyperpixel4"
dtoverlay=hyperpixel4:rotate,touchscreen-swapped-x-y,touchscreen-inverted-x

enable_dpi_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x7f216
dpi_timings=480 0 10 16 59 800 0 15 113 15 0 0 0 60 0 32000000 6
#modded - added the line below
display_lcd_rotate=3

I followed this and had good luck...though the touch screen is still a bit finicky at times
https://www.instructables.com/Rotate-Raspberry-Pi-Display-and-Touchscreen/

Hi!, I'm running the latest version of MainsailOS, is there a way to manually install the drivers and stuff whitout having to install RaspbianOS image instead of the MainsailOS image??

Seems like it dosen't work with KlipperScreen :-(
When Fluidd start up it show all the start lines in Landscape Mode, but when it start KlipperScreen it is in Portrait Mode.... In Config.txt I have set:
dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

With Raspberry Pi OS Lite + MainSail + KlipperScreen:
I can rotate with "DISPLAY=:0 xrandr --output DPI-1 --rotate right" but it wont keep it on each boot... And resolution is changed from 480x800 to 800x480 with that command, can't seem to find a solution for it...

@Gadgetoid Can you help?

Nevermind! My issue was that I had removed dtoverlay=vc4-kms-v3d which caused the display to not work correctly.

No worries. Useful to know exactly how this fails for future reference!

I had blank display, backlight only issues using a fresh Bullseye image - 32 bit - in a Pi 4. By default /boot/config.txt shows the following:
[all] #dtoverlay=vc4-kms-v3d
[pi4] dtoverlay=vc4-fkms-v3d

I toggled lines comments:
[all] dtoverlay=vc4-kms-v3d

[pi4] #dtoverlay=vc4-fkms-v3d

My rectangular hyperpixel display works nicely now.

nitz commented

So here's some interesting bits.

Starting with a fresh image of 64-bit (2022-04-04) (Linux pi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux)

via ssh:

$ sudo nano /boot/config.txt

Add to end:

[all]
dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y
$ sudo reboot

After rebooting, re-attach via ssh; but the screen is displaying correctly, in the correct orientation, with touch working properly.

Then, enable VNC:

$ sudo raspi-config nonint do_vnc 0 # alternatively 3, I3 through the GUI.

Notice that the VNC server starts and everything still looks correct... until:

$ sudo reboot

Now the display comes up in portrait (but the touch dtparams still seem to be correct.)

Comparing the output of xrandr before and after rebooting with VNC enabled, the difference is it seems to believe that HDMI-1 is primary rather than DPI-1. As well, the resolution reported for DPI-1 looks to be incorrectly swapped back to 480x800 as well. # Edited to add: looks like DPI-1 dropped the right designation, too!

$ xrandr # before rebooting w/vnc enabled
Screen 0: minimum 320 x 200, current 800 x 480, maximum 7680 x 7680
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DPI-1 connected primary 800x480+0+0 right (normal left inverted right x axis y axis) 0mm x 0mm
   480x800       60.06*+

$ xrandr --listmonitors
Monitors: 1
 0: +*DPI-1 800/212x480/127+0+0  DPI-1

# rebooting here...

$ xrandr # after rebooting w/vnc enabled
Screen 0: minimum 320 x 200, current 480 x 800, maximum 7680 x 7680
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DPI-1 connected 480x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   480x800       60.06*+

$ xrandr --listmonitors
Monitors: 1
 0: +DPI-1 480/127x800/212+0+0  DPI-1

So I assume somewhere a script is futzing with things, but I've not found where yet.

# nothing in /usr/share/X11/xorg.conf.d/ has been modified...
$ sudo ls -la /usr/share/X11/xorg.conf.d/
total 32
drwxr-xr-x 2 root root 4096 Apr  4 10:35 .
drwxr-xr-x 5 root root 4096 Apr  4 10:31 ..
-rw-r--r-- 1 root root   69 Jan  4 05:24 00-glamor.conf
-rw-r--r-- 1 root root   92 Sep 17  2020 10-amdgpu.conf
-rw-r--r-- 1 root root 1350 Jan  4 05:24 10-quirks.conf
-rw-r--r-- 1 root root   92 Sep 18  2020 10-radeon.conf
-rw-r--r-- 1 root root 1429 Aug 17  2020 40-libinput.conf
-rw-r--r-- 1 root root  607 Jul  8  2021 99-fbturbo.~

# dispsetup.sh is still boring...
$ sudo cat /usr/share/dispsetup.sh
#!/bin/sh
exit 0

# I'm assuming the answer lies somewhere within a VNC specific script, but as of yet, I can't figure out how it's futzing with it!
$ sudo cat /etc/vnc/config
# Default X Server command-line parameters for VNC Server.
#
# This file is automatically generated. DO NOT EDIT.
# To override settings in this file, create or edit /etc/vnc/config.custom.

# Continue even if standard ports fail
-pn
$ sudo cat /etc/vnc/config.d/*
# Default settings for all VNC programs.
#
# This file is automatically generated. DO NOT EDIT.
# To override settings in this file, create or edit
# /etc/vnc/config.d/common.custom

Any guesses as to a good spot to look?

@nitz Seems like we have same problem, mine is just with KlipperScreen

When I add this to Config.txt:

[all] dtoverlay=vc4-kms-dpi-hyperpixel4 dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

it is looking correct in landscape on the Prompt, but when it start KlipperScreen it is in is start in Portrait mode but Touch in Landscape... Seems like it is not possible to tell other program to Rotate to Landscape other that Prompt :-(

osfa commented

will these bundled drivers work for 2020 and earlier boards? trying to install fresh from mentioned bullseye dist with a 2020 square board and setting dtoverlay=vc4-kms-dpi-hyperpixel4sq but only seeing white flickering and glitching. if I instead start fresh and then clone the repo and install via the square-pi4 branch I at least see the boot screen but then after that just black with a white halosque light in the middle. what is the recommended image and install process for a 2020 board on a rpi4? will bullseye work?

osfa commented

will these bundled drivers work for 2020 and earlier boards? trying to install fresh from mentioned bullseye dist with a 2020 square board and setting dtoverlay=vc4-kms-dpi-hyperpixel4sq but only seeing white flickering and glitching. if I instead start fresh and then clone the repo and install via the square-pi4 branch I at least see the boot screen but then after that just black with a white halosque light in the middle. what is the recommended image and install process for a 2020 board on a rpi4? will bullseye work?

to answer my own question: for a 2020 or earlier board one seems to need to install the drivers via the square-pi4 branch and then disable dtoverlay=vc4-kms-v3d (and omit dtoverlay=vc4-kms-dpi-hyperpixel4sq)

On a Pi 4 running the latest and greatest nightly OctoPi build and using the simplified /boot/config.txt settings from above, I'm getting a consistent screen flicker (see video). I've tried going back to the legacy drivers with the same effect. Any suggestions?

Relevant lines from /boot/config.txt

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y
hyperpixel-flicker.mp4

Pi Zero 2 running a freshly installed/updated Bullseye 64bit - The new instructions aren't working for me fully for a new rectangular screen. It installs and displays, and the touchscreen works no problem in portrait and 180 rotated portrait - but 90 and 270 landscape rotations don't work. The boot screen(s) are correct, but the OS GUI remains in portrait. @Gadgetoid FYI as I thought I saw somewhere that you wanted some feedback on a Zero 2.

I ran the legacy installer for a Pi 4 rectangular and the landscape display worked after some tweaks (well technically I ran it for a Pi 3 first, then when that didn't work I ran for a Pi 4). I had to change in /boot/config.txt:

  • Comment out existing line dtoverlay=vc4-kms-v3d (I believe this disables hardware acceleration or something?)
  • Add display_lcd_rotate=1 to rotate the display
  • Add dtparam=touchscreen-swapped-x-y,touchscreen-inverted-y to rotate the touch input to match the display

This gives you landscape with header at the bottom, will need other combinations for other orientations. I needed both new settings - adding rotate=270, to the beginning of the dtparam didn't work by itself.

Hopefully this helps a few people struggling with this

EDIT: when I booted the pi again the next day the screen was blank - journalctl -u hyperpixel4-init.service showed an error of ImportError: No module named RPi.GPIO, editing sudo nano /usr/bin/hyperpixel4-init to have #!/usr/bin/env python3 instead of #!/usr/bin/env python fixed it. Just saying in case it helps someone

When I add this to Config.txt:

[all] dtoverlay=vc4-kms-dpi-hyperpixel4 dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

it is looking correct in landscape on the Prompt, but when it start KlipperScreen it is in is start in Portrait mode but Touch in Landscape... Seems like it is not possible to tell other program to Rotate to Landscape other that Prompt :-(

@ETE-Design still need help figuring out rotation w/ KlipperScreen? I have it working.

In my /boot/config.txt,

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Then create a new file,

sudo nano /usr/share/X11/xorg.conf.d/90-monitor.conf

with the following contents,

Section "Monitor"
    Identifier "DPI-1"
    Option "Rotate" "right"
EndSection

and restart KlipperScreen.
IMG_4305

On a Pi 4 running the latest and greatest nightly OctoPi build and using the simplified /boot/config.txt settings from above, I'm getting a consistent screen flicker (see video). I've tried going back to the legacy drivers with the same effect. Any suggestions?

I'm seeing these as well. I'm running 2022-04-04 with all of the updates installed. I have two HyperPixel 4 Square displays with two separate RPi Zero 2Ws and am seeing this on both. Here's my /boot/config.txt:

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Add HyperPixel support
dtoverlay=vc4-kms-dpi-hyperpixel4sq

# Disable compensation for displays with overscan
disable_overscan=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]

It's worth noting that these issues were on the 32-bit version of the Bullseye release of Rasperry Pi OS ^. I had tried the 64-bit release, but oddly enough, memory consumption and general performance were so problematic as to make it unusable for my project (which involves Chromium on an RPi Zero 2W).

As a workaround, I've installed the legacy Buster-based version of Rasperry Pi OS alongside the legacy drivers. In this scenario, everything works perfectly; no flickering at all.

How do you make the original Hyperpixel display work on Bullseye?

Should this work with the 2020-and-earlier version of the hyperpixel4sq on a Pi3b+? I tried both the 64bit and 32bit builds of Bullseye, released 2022-04-04. I get what appears to be vertical stripes in both cases. It doesn't seem to matter if hdmi is connected or not. If hdmi is connected, then I get a very low resolution desktop on hdmi. Both installs are fresh, plain installs, and the only change I made was to add "dtoverlay=vc4-kms-dpi-hyperpixel4sq" to the end of /boot/config.txt

Youch- that's a good question, to which the answer is: no. They require - iirc - very different configurations and bringup. That's something I'm going to have to look into. I had forgotten there were two flavours of Square 😬

I ran into same situation with the hyperpixel 4 square 2020, any guideline to make it work on bullseye ?

I have a Hyperpixel 4 rectangle bought in 2018. I'm attempting to get this working on a Raspberry Pi 3 B using Bullseye 64-bit 2022-04-04 build. Should this combination work?

The display does actually show the desktop, but the problem is I can't rotate the screen to landscape when trying each of the following lines:

dtoverlay=vc4-kms-dpi-hyperpixel4
# with one of the following below
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y
dtparam=rotate=180
dtparam=rotate=270,touchscreen-swapped-x-y,touchscreen-inverted-x

In my /boot/config.txt,

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Then create a new file,

sudo nano /usr/share/X11/xorg.conf.d/90-monitor.conf

with the following contents,

Section "Monitor"
    Identifier "DPI-1"
    Option "Rotate" "right"
EndSection

Finally! Thank you so much! Works now also on pi zero w with a few years old Hyperpixel 4.0 and fresh install of 32-bit Bullseye.

If anyone's confused like me, I just added dtoverlay=vc4-kms-dpi-hyperpixel4sq to /boot/config.txt and then ran the script with the desired orientation.

I am using a pi zero and the square display.

Using dtparam=rotate=180 would rotate the desktop, but not the mouse cursor.

In my /boot/config.txt,

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Then create a new file,

sudo nano /usr/share/X11/xorg.conf.d/90-monitor.conf

with the following contents,

Section "Monitor"
    Identifier "DPI-1"
    Option "Rotate" "right"
EndSection

Do you know why you needed rotate settings both in xorg.conf.d and in /boot/config.txt? Is one for touch and the other for the framebuffer itself?

I am not using X so the screen rotation solutions provided here have not worked for me. However, I have been able to get touchscreen rotation on the Pi 4 with a 2021 Hyperpixel 4.0 Square to work as follows.

In /boot/config.txt

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-hyperpixel4sq,rotate=180,touchscreen-swapped-x-y

In /etc/udev/rules.d/98-touchscreen.rules

ATTRS{name}=="generic ft5x06 (00)", ENV{LIBINPUT_CALIBRATION_MATRIX}="-1 0 1 0 -1 1"
ATTRS{name}=="EP0110M09", ENV{LIBINPUT_CALIBRATION_MATRIX}="-1 0 1 0 -1 1"

This is a bit of a black box to me, as I am not a udev or libinput expert, but as I understand it if the matrix is "a b 1 c d 1" then the touchscreen co-ordinates are multiplied by the matrix

(a b)
(c d)

to transform the co-ordinates. Hope this helps someone.

Of course it would be much neater if the rotation parameters worked in /boot/config.txt so hopefully that will get fixed soon.

Pi Zero 2 running a freshly installed/updated Bullseye 64bit - The new instructions aren't working for me fully for a new rectangular screen. It installs and displays, and the touchscreen works no problem in portrait and 180 rotated portrait - but 90 and 270 landscape rotations don't work. The boot screen(s) are correct, but the OS GUI remains in portrait. @Gadgetoid FYI as I thought I saw somewhere that you wanted some feedback on a Zero 2.

I ran the legacy installer for a Pi 4 rectangular and the landscape display worked after some tweaks (well technically I ran it for a Pi 3 first, then when that didn't work I ran for a Pi 4). I had to change in /boot/config.txt:

  • Comment out existing line dtoverlay=vc4-kms-v3d (I believe this disables hardware acceleration or something?)
  • Add display_lcd_rotate=1 to rotate the display
  • Add dtparam=touchscreen-swapped-x-y,touchscreen-inverted-y to rotate the touch input to match the display

This gives you landscape with header at the bottom, will need other combinations for other orientations. I needed both new settings - adding rotate=270, to the beginning of the dtparam didn't work by itself.

Hopefully this helps a few people struggling with this

EDIT: when I booted the pi again the next day the screen was blank - journalctl -u hyperpixel4-init.service showed an error of ImportError: No module named RPi.GPIO, editing sudo nano /usr/bin/hyperpixel4-init to have #!/usr/bin/env python3 instead of #!/usr/bin/env python fixed it. Just saying in case it helps someone

@ChrisZ32 Thank you for this. This worked perfectly for me also. New HyperPixel4, Zero 2W. Landscape mode works perfectly in either rotation. There is obviously an issue with the vc4-kms-v3d drivers and rotation. Reverting back to the old drivers and with your settings worked perfectly.

@jeffcolabs1 / @ChrisZ32 - adding my vote on this answer; brand new Pi Zero 2 WH with latest Raspberry OS (full - 32 bit - 2023-02-04)

i had the same symptoms as you, with the "new" default instructions, the screen works (and its gorgeous!) the startup and shutdown screens (white square with a raspberry pi logo) are in the right orientation, however the OS (desktop etc) are in portrait mode and no amount of messing about will fix it. I tried everything in this thread and the following (from your excellent work!) is what fixed it.

Hardware: Raspberry Pi Zero 2 WH, purchased a week ago
OS: Raspberry OS 32-Bit Full from 2023-02-04 (latest as of writing) imaged with Raspberry Pi Imager
HyperPixel 4 Rectangular, puchased around 6 months ago

My Setup has the GPIO Header along the top-edge; SD card on the left edge; USB ports on the bottom edge, Camera connector on the right edge

curl -sSL get.pimoroni.com/hyperpixel4-legacy | bash
: Select "0" (Raspberry Pi 4; Rectangular)

before rebooting, edit /boot/config.txt
: comment out the line that says dtoverlay=vc4-kms-v3d
: add the following to the bottom of /boot/config.txt
display_lcd_rotate=3 dtparam=touchscreen-inverted-x dtparam=touchscreen-swapped-x-y

reboot... happy days!

UPDATE: this appears to break VNC - VNC was working before, however after the above procedure, VNC logs show
X connection to :0 broken (explicit kill or server shutdown).
when trying to connect remotely - has anyone else seen this?

I have had my Pi 4 4GB and my 2023 Rectangle working with no issues until I had an issue with PINN and wiped the whole card and started again. Now no matter what I do the touchscreen will not rotate to match the screen orientation.
I'm sorry I can't seem to find the OP who posted this so I can't credit it, but the below method had a 100% success rate for me until today and I don't know why it won't work anymore on my installs.

cd /boot

sudo nano config.txt

Comment the line below:
#dtoverlay=vc4-fkms-v3d
add the line below
display_lcd_rotate=3

Save and Exit the Config file.

Save and reboot and the screen will now be orientated with the USB C port at the bottom.

The TOUCH function will still be incorrect, but to correct this:
cd /usr/share/X11/xorg.conf.d

sudo nano 40-libinput.conf

Edit the section for the touchscreen - it is normally the second last section - by adding this line:

Section "InputClass"
        Identifier "libinput touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
>>>>>  Option "TransformationMatrix" "0 -1 1 1 0 0 0 0 1"  <<<<<<<
EndSection

This was working with no issues and now on my Pi OS 64bit it just rotates the display only, not the touchscreen.
Any advice would be appreciated.
Ruhel™

Doesn't seem to work on Arch Linux ARM (armv7, pi zero 2 w) with the new overlay. It was working fine with the old hyperpixel 4 overlay until my last system update, which led me to this page. Touchscreen is working but I have no picture, I am able to interact with klipperscreen but I don't see what I'm clicking on :/

Here's my full config.txt:

# See /boot/overlays/README for all available options

dtoverlay=vc4-kms-dpi-hyperpixel4
#dtoverlay=hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y
initramfs initramfs-linux.img followkernel

# Automatically load overlays for detected DSI displays
#display_auto_detect=1

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Automatically load overlays for detected cameras
#camera_auto_detect=1

# Uncomment to enable bluetooth
#dtparam=krnbt=on

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[pi4]
# Run as fast as firmware / board allows
arm_boost=1

gpu_mem=96
start_file=start_x.elf
fixup_file=fixup_x.dat
disable_camera_led=1

#overscan_left=0
#overscan_right=0
#overscan_top=0
#overscan_bottom=0
#enable_dpi_lcd=1
#display_default_lcd=1
#display_lcd_rotate=1
#dpi_group=2
#dpi_mode=87
#dpi_output_format=0x7f216
#dpi_timings=480 0 10 16 59 800 0 15 113 15 0 0 0 60 0 32000000 6

Running the hyperpixel4-init service doesn't help either, although I understand it's no longer needed.

djammy commented

Hi all!

Newbie here. Apologies if my question is not meant for this thread.

I just got my raspberry pi 4 connected with the Hyperpixel 4.0 Square and I followed the instructions as above and the display is working fine. However, I would like to control the individual pixels on the Hyperpixel 4.0 display: for instance I would like to display the entire screen being green only or red, or white etc... Is there a way to do this using Python? If so, which library should I use?

Thanks.

Can I ask what it's for? Are you testing the pixels on the screen? If so just install the desktop OS and use a full screen image of wash colour.

Depends quite what you're trying to do.

  • PyGame is one option for direct control of the screen.
  • If you want a full window manager, PyQt. with EGLFS.
  • I think kivy also supports Linux framebuffer if you're after something more modern/high level
  • You can also write to the raw framebuffer device, but that would require a particular kind of masochism.
  • Needless to say, none of these are compatible with using X, and writing a full screen X11 application in PyQt is also an option.
djammy commented

So I would like to be able to control the entire screen pixels to display just one colour (255,0,0)/(0,255,0)/(0,0,255) and any combination in between. It is for a photonics experiment. Not for testing the pixels.

I was thinking if I should just use Pillow and display a coloured image.

I would use pygame or pyqt for that. Probably pygame as the learning curve is a little less steep. With a little research you could probably go a little more lightweight and just write the relevant number of raw pixels direct to /dev/fb0, but it's not a very expandable approach if you want to do more later.

djammy commented

Brilliant! Thank you @sesquipedality

with a fresh install of raspiOS 64bit after much trying using the instructions I finally got the hyperpixel4 to work on a Pi3B and rotated with.
add dtoverlay=vc4-kms-dpi-hyperpixel4 to /boot/config.txt, leave dtoverlay=vc4-kms-v3d there
then on the Pi 3B >> Preferences >> Screen Configuration >> DPI >> rotate option to suit, reboot

Should this work with the 2020-and-earlier version of the hyperpixel4sq on a Pi3b+? I tried both the 64bit and 32bit builds of Bullseye, released 2022-04-04. I get what appears to be vertical stripes in both cases. It doesn't seem to matter if hdmi is connected or not. If hdmi is connected, then I get a very low resolution desktop on hdmi. Both installs are fresh, plain installs, and the only change I made was to add "dtoverlay=vc4-kms-dpi-hyperpixel4sq" to the end of /boot/config.txt

Youch- that's a good question, to which the answer is: no. They require - iirc - very different configurations and bringup. That's something I'm going to have to look into. I had forgotten there were two flavours of Square 😬

Any update on this?

npimig commented

So oddly some how I arrived at a somewhat working display that could not rotate to landscape orientation (header on bottom). I used the latest of Bullseye 5/4/2023 image, at first no luck with the dtoverlay=vc4-kms-dpi-hyperpixel4 then I launched raspi-config and enabled GL drivers after reboot a screen turned on. Then trial error I then found to get the touch oriented correctly i had to insert the dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y stuff between the two dtoverlays (2nd one created after raspi-config dtoverlay=vc4-kms-v3d) in the /boot/config.txt as well as relying on the command DISPLAY=:0 xrandr --output DPI-1 --rotate right once desktop was finally loaded manually at first to orient the display and touchscreen in landscape mode.

To polish I asked ChatGPT (shame), who said to put that command in ~/.xsessionsrc that needed to be created but loads after the primary boot process/around the initial display rendering time and (viola it works). Takes a while to boot and appears to lock out touch inputs until the "ole-gd-its-broke" period of it and then all is good, presto.

I'm running on the Pi Zero 2 W with OpenGL 2 drivers enabled with the Hyperpixel 4" (Rectangular Display) with the Raspbian - Bullseye (Release 2023-05-03).

Prior i was running Buster from 2021 with issues in the legacy driver for this display not allowing me to enable OpenGL features.

Just thought I'd share...

Hi, is there a timeline as to when the Hyperpixel will be able to work with other interfaces enabled? I have a project which uses a camera through the CSI interface, and a lidar on i2c but even just the camera and the Hyperpixel do not work together. I am moving over to new libcamera, so I don't want to go back to older OS.

I have been using my HyperPixel Square without issue with the legacy drivers, old Raspbian OS on a Pi Zero W.

Then after upgrading to the latest Raspberry Pi OS (Bullseye) I was initially happy to find that I didnt have to install any drivers, and just needed to add the following line to my /boot/config.txt file:

dtoverlay=vc4-kms-dpi-hyperpixel4sq

After rebooting the screen would just show a bunch of lines running across the display and these would jump around when I touch it.

20230812_173320~2

I2C and SPI are disabled.

I have read all the comments here but I have not been able to resolve the issue.

Any help would be much appreciated.

Hi, is there a timeline as to when the Hyperpixel will be able to work with other interfaces enabled? I have a project which uses a camera through the CSI interface, and a lidar on i2c but even just the camera and the Hyperpixel do not work together. I am moving over to new libcamera, so I don't want to go back to older OS.

My understanding is it's not going to happen; the hyperpixel4 actually takes over the spi/i2c hardware and corresponding GPIO pins, which is the reason they must be disabled.

@rudiprinsloo there are two versions of HyperPixel Square. One which luckily requires no initialization and which Just Works with the new blessed way of doing things, and the other which needs init and will never work with the new way of doing things. It looks like you must have the latter, which IIRC is the earlier pre 2021 version. They also use different display timings, which is why you're seeing a garbled mess.

@brucediesel as @omarandlorraine suggests- never. The DPI display requires all the pins. That said, the Camera interface should work, but that's presumably an OS issue and not something we can fix or change.

Bodges

I know nobody wants to hear this- least of all me- but some older hardware can be fixed with bodges. I managed to hook a regular Pico up to my HyperPixel 4 Square (post 2021) in order to shut down the LCD when there are no vsync/hsync signals, solving the display corruption issue. To do this in the field would need some fine soldering skills, a micro of some sort (with at least 3 IO pins) and bodge wires for power, ground, vsync, hsync and LCD shutdown. I'm thinking of putting together a guide for anyone who wants to try this. Normally you'd just tie shutdown to a pin on the Pi but, uh, DPI makes sure there aren't any left.

Similarly, while pre 2021 HyperPixel 4 Square is currently not supported by Raspberry Pi OS, it might be possible to at least get a driver running for the DPI signals and then figure out the rest from there, possibly with a similar bodge to fire over the display init before the OS can boot and start touch comms.

I've long been a proponent for putting a micro on our display boards to handle some of this stuff, but revising our designs doesn't really help anyone with an old board. The long and short of it here, though, is that the software has moved on and made changes beyond what we could have expected, so supporting older (yes I know 2021 isn't that long ago) boards is getting more and more difficult.

Bookworm

As of Bookworm OS on a Pi 4/Pi 400 - which supports post 2021 HyperPixel 4 Square and HyperPixel 4 Rectangular -a device tree conflict between interfaces will result in the graphics stack crashing and booting to a black screen- even on HDMI. Some good news, however, is that the display config utility in Raspberry Pi OS will finally support associating a touchscreen with a display so that rotation - at least if you're running a full RPi OS - is less of a chore.

Diudid commented

Hello i did a litlte update to the rotate script to allow it to rotate the screen clockwise, no need of keyboard

#!/bin/bash

UTILITY="hyperpixel4-rotate (Rectangular)"
XORG_TOUCH_CONF_FILE="/usr/share/X11/xorg.conf.d/88-hyperpixel4-touch.conf"
XORG_CONF_FILE="/usr/share/X11/xorg.conf.d/88-dsi-1-rotate.conf"

OVERLAY_S="vc4-kms-dpi-hyperpixel4sq"
OVERLAY_R="vc4-kms-dpi-hyperpixel4"

function success() {
    echo -e "$(tput setaf 2)$1$(tput sgr0)"
}

function inform() {
    echo -e "$(tput setaf 6)$1$(tput sgr0)"
}

function warning() {
    echo -e "$(tput setaf 1)$1$(tput sgr0)"
}

function set_xorg_conf {
    if [ "$DISPLAY" == "" ]; then
        inform "No DISPLAY variable set, trying :0.0"
        export DISPLAY=:0.0
    fi

    inform "Rotating display $1";
    xrandr --output DPI-1 --rotate $1

    MATRIX="$2 $3 $4 $5 $6 $7 $8 $9 ${10}"

    inform "Setting libinput Calibration Matrix: 1 0 0 0 1 0";
    xinput set-prop "pointer:$DEVICE" "libinput Calibration Matrix" 1 0 0 0 1 0 0 0 1

    inform "Setting Coordinate Transformation Matrix: $MATRIX";
    xinput set-prop "pointer:$DEVICE" "Coordinate Transformation Matrix" $MATRIX

    inform "Saving xorg touch config to $XORG_TOUCH_CONF_FILE";
    sudo tee $XORG_TOUCH_CONF_FILE > /dev/null <<EOF
# Auto generated by $UTILITY, edit with care!

Section "InputClass"
    Identifier "HyperPixel4 $DEVICE"
    MatchProduct "$DEVICE"
    Option "CalibrationMatrix" "1 0 0 0 1 0 0 0 1"
    Option "TransformationMatrix" "$MATRIX"
EndSection
EOF

    inform "Saving xorg rotate config to $XORG_CONF_FILE";
    sudo tee $XORG_CONF_FILE > /dev/null <<EOF
# Auto generated by $UTILITY, edit with care!

Section "Monitor"
    Identifier "DPI-1"
    Option "Rotate" "$1"
EndSection
EOF
}

printf "HyperPixel 4: Display & Touch Rotation\n"
printf "This utility requires the Raspberry Pi OS desktop or an *Xorg-based* alternative.\n\n"

FILE=/tmp/HPStep
if [[ -f "$FILE" ]]; then
    STEP=$(cat $FILE)
	(( STEP+=1 ))
	if [[ $STEP == 5 ]]; then
		STEP=1
	fi
else
	STEP=1
fi

grep -e "^dtoverlay=$OVERLAY_S.*" /boot/config.txt > /dev/null
if [ $? -ne 0 ]; then
    grep -e "^dtoverlay=$OVERLAY_R.*" /boot/config.txt > /dev/null
    if [ $? -ne 0 ]; then
        warning "Rotation requires hardware support on the Pi 4 or Pi 400"
        warning "Ensure your HyperPixel4 is enabled in /boot/config.txt"
	printf "\nSquare:      dtoverlay=$OVERLAY_S\n"
	printf "Rectangular: dtoverlay=$OVERLAY_R\n\n"
        exit 1
    else
        inform "Detected HyperPixel 4 Rectangular (found \"$OVERLAY_R\" in config.txt)"
        DEVICE="Goodix Capacitive TouchScreen"
    fi
else
    inform "Detected HyperPixel 4 Square (found \"$OVERLAY_S\" in config.txt)"
    DEVICE="EP0110M09"
fi

case $STEP in
    "1")
        set_xorg_conf "right" 0 1 0 -1 0 1 0 0 1
        ;;
	"2")
        set_xorg_conf "inverted" -1 0 1 0 -1 1 0 0 1
        ;;
    "3")
        set_xorg_conf "left" 0 -1 1 1 0 0 0 0 1
        ;;
    "4")
        set_xorg_conf "normal" 1 0 0 0 1 0 0 0 1
        ;;
    *)
        printf "Unsupported orientation: $ORIENTATION\n\n";
        printf "Usage:\n"
        printf "    $0 <orientation>\n\n"
        printf "Where orientation is one of: left, right, normal, inverted.\n"
        exit 1
esac
echo $STEP > $FILE

So is there any way to get a pre-2021 Square touch screen to work with a PI 4? I've tried it with Buster, and get a black screen, but I'm not sure I'm installing the correct drivers (I did the legacy install with "weirdly square," but I'm not sure what that means).

@Gadgetoid

addohm commented

Hi, is there a timeline as to when the Hyperpixel will be able to work with other interfaces enabled? I have a project which uses a camera through the CSI interface, and a lidar on i2c but even just the camera and the Hyperpixel do not work together. I am moving over to new libcamera, so I don't want to go back to older OS.

Never. https://pinout.xyz/pinout/hyperpixel4#

benlk commented

@Gadgetoid Can you tell us more about the Bookworm issues?

As of Bookworm OS on a Pi 4/Pi 400 - which supports post 2021 HyperPixel 4 Square and HyperPixel 4 Rectangular -a device tree conflict between interfaces will result in the graphics stack crashing and booting to a black screen- even on HDMI. Some good news, however, is that the display config utility in Raspberry Pi OS will finally support associating a touchscreen with a display so that rotation - at least if you're running a full RPi OS - is less of a chore.

I've experienced this issue myself, with a CM4 and a Hyperpixel 4 Square Touch and an HDMI monitor.

Do you have a link or any additional information about this device tree conflict? Even a link to the upstream bug tracker would be helpful, so that I can check for the fix and then update my images.

I just had a hell of a time getting my Hyperpixel rectangle working rotated on a Pi3b+ running latest 32bit Raspberry Pi OS. The splash screen would show the correct orientation but the actual desktop would be wrong. To fix this you must go into preferences > screen configuration. Then RIGHT CLICK on the box labelled DPI-1 and change the orientation.

IMG_2393

FYI left is "headers on top", right is "headers on bottom"

@Gadgetoid you may want to consider adding this to the top post, because I didn't even know this was possible until scrolling through many many comments on this post where it was casually mentioned as a side-note on another issue :D

My turn to comment!! Not sure if this will help, but this is what got it working for me, using Raspberry Pi 2 Zero with Hyperpixel 4 (Rectanuglar) and the raspbain installer that included mainsail (as my application was for Klipperscreen interface for a 3d printer). Initially, the screen would flash the console would booting, then blkank screen. The below rectified the issue and made the touch function work.

  1. I added the following lines to the /boot/config.txt:
    dtoverlay=vc4-kms-dpi-hyperpixel4
    dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

  2. The screen would show, albeit would remain in portrait mode, and the touch would not be aligned with the display. Scrolling all the way to the bottom of the /boot/config.txt file, in the [alI] section, I changed:
    display_rotate=3 (which was originally 0).

Rebooting the system, the screen works, is in landscape and touch controls function perfectly.

Posting here in the event I wind up back here looking for information in the future!

@rudiprinsloo there are two versions of HyperPixel Square. One which luckily requires no initialisation and which Just Works with the new blessed way of doing things, and the other which needs init and will never work with the new way of doing things. It looks like you must have the latter, which IIRC is the earlier pre 2021 version. They also use different display timings, which is why you're seeing a garbled mess.

Could this information be put into the original post, and maybe the guide on the main site? Having dug out my pre-2021 square hyperpixel from a drawer and doing a fresh install I really thought my display was dead and was about to bin it!!

@rudiprinsloo there are two versions of HyperPixel Square. One which luckily requires no initialisation and which Just Works with the new blessed way of doing things, and the other which needs init and will never work with the new way of doing things. It looks like you must have the latter, which IIRC is the earlier pre 2021 version. They also use different display timings, which is why you're seeing a garbled mess.

Could this information be put into the original post, and maybe the guide on the main site? Having dug out my pre-2021 square hyperpixel from a drawer and doing a fresh install I really thought my display was dead and was about to bin it!!

Further to the above, it seems the current version of the legacy script doesn't install the init script, despite it apparently being required. The code to install it has been commented out. Since I had tried the new approach before I realised this wasn't going to work, I had accidentally left the new overlay (vc4-kms-dpi-hyperpixel4sq) in the config and it seems this combination along with the old overlay (hyperpixel4) is required to get things working without the init script ... sometimes. After another fresh install I couldn't get this combo working reliably so maybe that was just a fluke. Altogether the current instructions on getting the original* Hyperpixel 4 Square working under bullseye are incomplete if not entirely missing.

Mine was ordered the week the original square launched, so I guess the very first batch, I hope us early adopters aren't going to get completely abandoned. :)

I went with a variant of @npimig (thanks!), after having gone through various permutations of other suggestions. With Hyperpixel 4.0 on Raspbian Bookworm. I put this at the top of /boot/config.txt to make the touch-screen landscape mode:

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

The rotate=90 doesn't seem to do anything (though rotate=180 works), but perhaps that will be fixed at some point, and it doesn't hurt, so I'm leaving it in there. (I also left the existing dtoverlay=... lower in the file unchanged, I think that was essential.)

Then to actually rotate the display I put this in (possibly initially empty) ~./xsessionrc:

DISPLAY=:0 xrandr --output DPI-1 --rotate right

Reboot et voila.

Thanks everyone for sharing what worked for you, particularly @npimig @mwestera. For reasons I initially did not understand, these instructions only had some effect for me (the boot screen was rotated, touchscreen coordinates have changed), but after the desktop session had loaded, the orientation would still be unchanged (portrait), no matter what I put in any of these files: ~/.xsessionrc, /usr/share/X11/...

Furthermore, any attempt to use xrandr command would error out with output DPI-1 not found or would produce no output but have no effect either.

Finally, I found myself unable to use the “Preferences” → “Screen configuration” GUI because I didn't have a physical mouse nor keyboard plugged in. (I was editing files via an SSH session.) Using the touchscreen I was able to access the GUI, but after rotating the display, the GUI would ask me to confirm the new display setting. Tapping on the confirmation button did not work because even though the display was visually rotated, the touchscreen coordinates did not rotate accordingly. Ultimately, I also wanted to avoid having to use any GUI in favor of editing configuration files so that I can easily recreate a fresh system from scratch using scripts.


Here is how I solved it:

My environment is a fresh Debian 12 (Bookworm), the default operating system when flashing an SD card using Raspberry Pi Imager. The only changes to the system I've done were apt-get update and apt-get dist-upgrade. My board is a Raspberry Pi 4. My display is HyperPixel 4 rectangular.

Apparently, in October 2023 the Raspberry Pi Debian image was updated to Bookworm and switched from X Window System (X11) to Wayland display server protocol, with Wayfire 0.7.5 being its concrete implementation at the time of writing. This was the reason why ~/.xsessionrc, /usr/share/X11/..., and xrandr did not have any effect anymore: X11 wasn't running at all!

The default configuration file can be discovered using echo $WAYFIRE_CONFIG_FILE from a terminal running as part of the desktop session. The default location for this is ~/.config/wayfire.ini. To rotate the HyperPixel display, I found that appending this to the config file fixed the desktop rotation:

## ~/.config/wayfire.ini
[output:DPI-1]
mode = 480x800@60061
position = 0,0
transform = 270

To rotate the boot screen and touchscreen coordinates, suggestions from earlier in this thread for editing /boot/firmware/config.txt (the new location of /boot/config.txt) are still valid. These lines should be prepended to the file, with the rest of the original file (particularly the original dtoverlay=vc4-kms-v3d line) remaining intact:

## /boot/firmware/config.txt 
dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Hope this helps!

Thanks, @mislav! I can confirm it works on a Raspberry Pi 5 (Bookworm 64-bit).
Now I am running ROS2 RViz on it! https://twitter.com/knaveen/status/1731264586652029414

Hi
Working in console but not in X

I have a Raspberry Pi 400 with a new stock image and am using an AdaFruit Cyberdeck HAT to attach a HyperPixel 4", Rectangular, no touch

I boot to a console which rotates properly but when I enter X using startx the rotate setting seems to be ignored

I've added these to my config.txt

dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=rotate=270

the script below looks like it may be the solution, but also mentions removing the rotate dtparam which would break my console.

How can I have both the console and X desktop rotated?

Thanks very much

Installer Script for latest versions of Raspberry Pi OS

Using tips and tricks from others in this thread, I created a simple installer script. You can run it from the terminal using:

curl -L "https://raw.githubusercontent.com/DevOats/raspi-tools/main/install-hyperpixel40rect.sh" | bash

Notes:

  • Tested using SSH to a 'headless' Raspberry Pi 5 with the Pimoroni Rectangle screen.
  • For testing, I used a fresh image (with desktop) and only updated/upgraded packages using apt-get
  • Orientation is GPIO-header at the bottom.
  • This might also work on other Raspberry Pi versions running the latest Raspberry Pi OS (not tested)
  • Note that the script is not idempotent! (i.e. do not run the script twice!)
  • Disclaimer: I'm not an experienced shell scripter. Please validate that what I did will not break your device ;) I love to learn, so feedback is very welcome :)

Many thanks to others who contributed by posting information to this thread!

I've been struggling to get my new Hyperpixel 4.0 (rectangular) working with my Pi 3B. I've got the latest Raspian bistro (Bullseye 32 bit) loaded and have added "dtoverlay=vc4-kms-dpi-hyperpixel4" to the config.txt file in the boot directory on the sd card as per the instructions above. Pi boots up fine but all I get on the Hyperpixel display is a backlight...no text or desktop or anything. I'm beginning to suspect that the display is defective...

Any ideas out there? I've tried a bunch of things, even loading the legacy drivers but nothing....just a backlight. Suggestions welcome.

I also purchased a HyperPixel 4.0 (rectangular) for my new Pi 4 model B 4Gb, running a fresh install of the Raspberry pi os: revision c03115, 6.1.0-rpi7-rpi-v8, onto a new micro SD card. I too am only getting backlight on the display. I have verified that i2c and SPI are disabled. I have not resorted to using the legacy drivers, and really do not want to follow that path. It should work as advertised. I would appreciate any help or direction.

I also purchased a HyperPixel 4.0 (rectangular) for my new Pi 4 model B 4Gb, running a fresh install of the Raspberry pi os: revision c03115, 6.1.0-rpi7-rpi-v8, onto a new micro SD card. I too am only getting backlight on the display. I have verified that i2c and SPI are disabled. I have not resorted to using the legacy drivers, and really do not want to follow that path. It should work as advertised. I would appreciate any help or direction.

I worked with the vendor that sold me the Hyperpixel 4.0. We went through a bunch of different tests with the Pi, and the vendor finally contacted Pimoroni. They suggested some further tests; when those failed, the vendor issued an RMA and i returned the display. They tested it, found it to be defective, and sent me a new one (which worked out of the box). So I suggest contacting your vendor to see if they will replace a defective display.

To add to my comment above, the Hyperpixel 4.0 works fine on the Buster version of PiOS using the legacy drivers and install, but i still get a blank display if I use the Bullseye version of PiOS with the new install instructions from Pimoroni. So I'm still sorta stuck in that i can't get it to run on a Pi 3B with the latest version of the OS.

Any ideas?

After reading various suggestions above, the following instructions worked for me on a Raspberry Pi Zero 2W with a rectangular HyperPixel 4.0 (with touch) display and a fresh install of Raspbian Bullseye. Note: my display orientation is landscape with the mini HDMI and microUSB ports facing down.

  1. Installed Raspbian Bullseye via rpi-imager (64-bit version released on 2023-12-05 with security updates and desktop environment) on a separate machine.
  2. Added the following lines to the top of /boot/config.txt.
    • dtoverlay=vc4-kms-dpi-hyperpixel4
    • dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-x
  3. Booted into the Pi with the Hyperpixel 4.0 display working (albeit in portrait mode with inverted touchscreen controls).
  4. Ran sudo apt update && sudo apt upgrade (Not sure if this was necessary given the display worked in step 3 but probably a good thing to do.)
  5. Rebooted the Pi.
  6. Ran the Pi Screen Configuration application in the drop down menu and changed the screen orientation.
    • Right clicked on the display and set orientation to left (in my case).

After step 6, the display was correctly oriented in landscape mode with no touchscreen issues.
1000003550

I received a replacement HyperPixel, followed the instructions written above by @jchitpin, and it works as advertised.
The only change I made to the instructions was to set the rotation in /boot/config.txt by using a slightly different entry:
dtparam=rotate=270,touchscreen-swapped-x-y,touchscreen-inverted-x
This allowed me to completely skip step 6.
I am going to let it run for a day or two, just to be sure...

Yo guys i just started to get into Hyperpixel and with the guide from @jchitpin it worked to get it running but the layout is not correcet i have like half a CM of Blackscreen beneath the "desktop" its working fine beside that

Edit without a extern Hdmi Display i dont get apicture at all
Eidt 2 I dont have the Hyperpxel with Touch I have the one without Touchscreen

Not mentioned here, but adding video=DSI-1:480x800 fbcon=rotate:1 to cmdline.txt rotates the console in Bookworm and Buster (probably others).

I can rotate the screen so it is in landscape, but the touch screen always rotates to a portrait view.

I have a brand new install of OctoPi 1.0.0 (not running 64bit) and Octoprint 1.9.3 (no other drivers)

When I install OctoDash, it rotates

This is what I have in the config file:
dtoverlay=vc4-kms-dpi-hyperpixel4,rotate=90
dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Any suggestions would be appretiated.

I managed to get it to work. Happy man :)

Used this tutorial Youtube

Used option 3, but since the Octopi with Octoprint is newer and with higher kernel, I just did the regular install, including Octodash, and then I ran the commands needed in the video.

SOLVED

Not mentioned here, but adding video=DSI-1:480x800 fbcon=rotate:1 to cmdline.txt rotates the console in Bookworm and Buster (probably others).

Exactly what I was searching for half a day now...thx @beejay41 for this important (for me, at least) bit of information.

I had to adjust it to video=DSI-1:480x800 fbcon=rotate:3, because my "HyperPixel 4.0 (rectangle, touch)" sits on the "Adafruit CYBERDECK HAT for Raspberry Pi 400" connected to my Pi400. So the GPIO connector is at the top edge in my setup.

I noticed a small issue with the display. If you look really close you can see something like flickering. Its definitely a software bug as I tested 2 brand new displays and they have the same problem. Any idea on what could be wrong?

I noticed a small issue with the display. If you look really close you can see something like flickering. Its definitely a software bug as I tested 2 brand new displays and they have the same problem. Any idea on what could be wrong?

Yes, I have the same issue with the Hyperpixel 4.0 rectangle installed on a Raspberry Pi Zero 2w (bookworm), have no idea how to solve it yet.

I thought it was a screen problem and got a replacement but this is bad because no one else reported it. I guess it has to do with the backlight?

Yes, it may be a backlight issue. Did the problem still exist after you got the replacement?

I noticed a small issue with the display. If you look really close you can see something like flickering. Its definitely a software bug as I tested 2 brand new displays and they have the same problem. Any idea on what could be wrong?

I hve this same isue and its gotten worse over time with all 3 of my hyperpixels.

the absolute hell it took to get a straight answer from pimoroni the first time I dealt with the though.. not even gonna bother complaining directly. just hoping something better comes along.

Yeah agreed. It's also bad for resellers who don't know about it and will think the screen is broken. I will try sending a custom pwm signal to the pin 19 (controlling the backlight) and see if it fixes the issue.

I can rotate the screen so it is in landscape, but the touch screen always rotates to a portrait view.

I have a brand new install of OctoPi 1.0.0 (not running 64bit) and Octoprint 1.9.3 (no other drivers)

When I install OctoDash, it rotates

This is what I have in the config file: dtoverlay=vc4-kms-dpi-hyperpixel4,rotate=90 dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y

Any suggestions would be appretiated.

I managed to get it to work. Happy man :)

Used this tutorial

Used option 3, but since the Octopi with Octoprint is newer and with higher kernel, I just did the regular install, including Octodash, and then I ran the commands needed in the video.

SOLVED

The link you tried to share didn't post so we can see the tutorial you're talking about. Can you reply or edit with the link?

I can rotate the screen so it is in landscape, but the touch screen always rotates to a portrait view.
I have a brand new install of OctoPi 1.0.0 (not running 64bit) and Octoprint 1.9.3 (no other drivers)
When I install OctoDash, it rotates
This is what I have in the config file: dtoverlay=vc4-kms-dpi-hyperpixel4,rotate=90 dtparam=rotate=90,touchscreen-swapped-x-y,touchscreen-inverted-y
Any suggestions would be appretiated.
I managed to get it to work. Happy man :)
Used this tutorial
Used option 3, but since the Octopi with Octoprint is newer and with higher kernel, I just did the regular install, including Octodash, and then I ran the commands needed in the video.
SOLVED

The link you tried to share didn't post so we can see the tutorial you're talking about. Can you reply or edit with the link?

Have updated the original post with the link

Can't get it to work. No matter what dtoverlay settings I try, nothing changes. I know how to rotate the console and I know that I can rotate a desktop in X11. But I want to run own programs (e.g. python with cv2) or let's say even chocolate-doom. They are in protrait mode instead of landscape because the damn framebuffer of the screen is 480x800 instead of 800x480 and I cant find a way to change that.