Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Gadgetoid opened this issue Apr 11, 2022 · 111 comments
Open
Labels
notice Important notice or information

Comments

@Gadgetoid
Copy link
Member

Gadgetoid commented Apr 11, 2022

ℹ️ 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
@e28eta
Copy link

e28eta commented Apr 13, 2022

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 😞

@Gadgetoid
Copy link
Member Author

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

@Gadgetoid
Copy link
Member Author

Gadgetoid commented Apr 13, 2022

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.

@e28eta
Copy link

e28eta commented Apr 15, 2022

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.

@Gadgetoid
Copy link
Member Author

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.

@e28eta
Copy link

e28eta commented Apr 15, 2022

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!

@cubismod
Copy link

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.

@cubismod
Copy link

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

@Gadgetoid
Copy link
Member Author

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!

@sunsmoke
Copy link

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

@Gadgetoid
Copy link
Member Author

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 😬

@sunsmoke
Copy link

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

@brotherlogic
Copy link

brotherlogic commented Apr 24, 2022

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?

@tl8roy
Copy link

tl8roy commented Apr 28, 2022

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]

@tl8roy
Copy link

tl8roy commented Apr 29, 2022

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

@Gadgetoid
Copy link
Member Author

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. 😬

@LazLong
Copy link

LazLong commented May 3, 2022

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?

@Jeroennl
Copy link

Jeroennl commented May 10, 2022

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?

@Gadgetoid
Copy link
Member Author

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.

@Tor-Einar
Copy link

Tor-Einar commented Apr 10, 2024

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

@bchschaefer
Copy link

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.

@steveiliop56
Copy link

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?

@coollx
Copy link

coollx commented Apr 15, 2024

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.

@steveiliop56
Copy link

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?

@coollx
Copy link

coollx commented Apr 15, 2024

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

@d3k4-k3rb3r0s
Copy link

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.

@steveiliop56
Copy link

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.

@travmilne
Copy 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?

@Tor-Einar
Copy 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

@MarvInt64
Copy link

MarvInt64 commented May 24, 2024

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.

@steveiliop56
Copy link

steveiliop56 commented May 26, 2024

@d3k4-k3rb3r0s does your issue look anything like this? The video is not very clear but it was the only way I could capture it in camera.

video-d0933750b7dc259ae3a9e232c5db7c10-V.mp4

@steveiliop56
Copy link

I am trying to figure out what could be the problem. The colors look so it's not the color pins, the backlight is also working fine so no problem with the backlight pins neither, touch works perfectly so no probleb there so I suspect it could be the DPI V-sync causing these lines? I may be completely wrong but looking at the pinout that seems to be responsible.

@steveiliop56
Copy link

Ok so the issue is vertical banding apparently which means probably interference or bad cable connection according to google. How could that be fixed...

@steveiliop56
Copy link

Ok so the issue is vertical banding apparently which means probably interference or bad cable connection according to google. How could that be fixed...

Nah wouldn't make sense. It's similar but you have these moving lines too.

@steveiliop56
Copy link

@Gadgetoid seems you are a maintainer/developer of the hyperpixel so that's why I am pinging you. So I installed the latest version of raspberry pi os buster armhf on my raspberry pi 4 and used your old legacy drivers to test if the issue I am having (and other users too I guess) and I got the same issue on both the buster os and the bookworm one. Seems like it is a hardware problem? But I have 2 screens one directly from you (the newest version) and another latest one from my local retailer and same issue. Can you please try to replicate using a pi4/pi5 with bookworm in dark mode with the overlay and see if you can replicate? The issue is only noticeable on dark grey colors.

@SamSkjord
Copy link

to anyone finding this when trying to get i2c working, you now want to remap the i2c interface using:

sudo ln -s /dev/i2c-22 /dev/i2c-1

@Simplycissmus
Copy link

Has anyone successfully gotten a Raspberry Pi Zero 2 W running with the latest Bookworm OS (2024-07-04)?

I've tried everything, including both versions of the HyperPixel 4 display (Square and Rectangular). I've also experimented with the 32-bit version of the OS and the legacy drivers, but still no luck. The Raspberry Pi 5, on the other hand, was up and running perfectly in less than a minute.

Has anyone had similar issues or found a solution for getting the Zero 2 W to work with Bookworm and the HyperPixel 4?

@beejay41
Copy link

Linux HyperPixel4 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux, apt upgrade from 2024/03/07 Lite version (no desktop)

/boot/firmware/cmdline.txt:
console=serial0,115200 console=tty3 root=PARTUUID=ba362178-02 rootfstype=ext4 fsck.repair=yes rootwait quiet loglevel=1 vt.global_cursor_default=0 video=DSI-1:480x800 fbcon=rotate:1 cfg80211.ieee80211_regdom=GB

Most relevant entries in /boot/firmware/config.txt:

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

...

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

I've only used the drives included with the OS. My app uses a framebuffer browser with simple http server, but I'm sure a desktop would run, but a bit limited by memory.

Hope that helps.

@1251cc
Copy link

1251cc commented Oct 4, 2024

Under “On the fly rotation”

Change all instances of (boot/config.txt) to (boot/firmware/config.txt).

boot/config.txt is moved in the new OS.

@steveiliop56
Copy link

If anybody is having trouble setting up the screen with the touchscreen and rotation working with the latest Raspberry Pi OS, check my blog post here

@phantomthrill
Copy link

phantomthrill commented Dec 11, 2024

I used my pi 400 keyboard with 64-bit raspberry pi o/s installed. I just installed the new operating system last night 12/09/2024. I used the legacy script that is in the beginning of this thread. I used a Adafruit CYBERDECK HAT for Raspberry Pi 400. I scored the trace so that the cyberdeck would function properly. All I added was "dtoverlay=vc4-kms-dpi-hyperpixel4sq" to my config.txt file. I rebooted my pi and my rectangular hyperpixel4 worked. I used the screen orientation in the desktop to fix its rotation and the touchscreen worked without needing further adjustments. Hopefully this helps someone so that they aren't stuck for hours typing in different commands that do not yield results. The screen acts as a second display when another is attached so you have to reboot without a monitor or T.V. attached to make the hyperpixel4 act as the only display. All in all, for the headache I had to go through, it is working fine now and that is all that matters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
notice Important notice or information
Projects
None yet
Development

No branches or pull requests