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

4.0" HDMI Display (MPI4008) on CM4 with Raspberry Pi OS Bookworm #352

Open
vitorio opened this issue Nov 18, 2023 · 7 comments
Open

4.0" HDMI Display (MPI4008) on CM4 with Raspberry Pi OS Bookworm #352

vitorio opened this issue Nov 18, 2023 · 7 comments

Comments

@vitorio
Copy link

vitorio commented Nov 18, 2023

I've gotten the 4.0" HDMI Display (MPI4008) working on a CM4 with Raspberry Pi OS Bookworm over HDMI.

Get a copy of the display's EDID. You can use a tool like Monitor Asset Manager under Windows, or download a copy from https://edid.tv/edid/1665/ (both were identical for me). Create the /usr/lib/firmware/edid directory on your Bookworm installation if it doesn't already exist, then copy the EDID into it. Append the kernel commandline to load the EDID and set the video mode appropriately.

After a reboot, the display flickers several times, but eventually displays the end of the startup scroll and the login prompt. (I do not see the four raspberries and the start of the scroll.) No other changes were necessary to get framebuffer output at the console.

$ wget -O MPI4008_1.edid https://edid.tv/edid/1665/download/
$ sudo mkdir /usr/lib/firmware/edid
$ sudo mv MPI4008_1.edid /usr/lib/firmware/edid/
$ sudo nano /boot/firmware/cmdline.txt
  drm.edid_firmware=edid/MPI4008_1.edid video=HDMI-A-1:480x800@62
$ sudo reboot

Depending on your use case, rotation can be done with panel_orientation, e.g. video=HDMI-A-1:480x800@62,panel_orientation=left_side_up; or rotate, e.g. video=HDMI-A-1:480x800@62,rotate=90 (see https://www.kernel.org/doc/html/latest/fb/modedb.html for options).

@Boaztheostrich
Copy link

Does this solve touchscreen issue?

@vitorio
Copy link
Author

vitorio commented Dec 13, 2023

I'm not using the touchscreen or a graphical desktop in my CM4 application, but I plugged it into a Raspberry Pi 400 running Bookworm with Wayland (not X11) to see.

By default, the display came up over HDMI, with the Wayland desktop, without me needing to set up the EDID as described above. It defaulted to portrait mode (HDMI port on the left as you look at the screen), and the "Screen Configuration" app did rotate the screen properly.

When I enabled SPI and added the touchscreen dtoverlay from MPI4008-show to /boot/config.txt, the touchscreen also worked as expected in the default portrait orientation. In other orientations, it behaved incorrectly; the X and Y axes appeared swapped and/or one of the axes was inverted.

$ sudo nano /boot/config.txt
  dtparam=spi=on
  dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900

While the dtoverlay allows for swapping the axes, it doesn't allow for inverting them, so if you're not running the screen in its default portrait orientation and need the touchscreen, perhaps it's better to leave the dtoverlay as-is and do everything with calibration.

For a rotated screen with correct touchscreen, create a new udev rule file for the touchscreen, set the libinput calibration matrix to correct the issues, and reboot (the Raspberry Pi Wayfire compositor doesn't appear to apply the changes live even when udevadm is reloaded and triggered).

$ sudo nano /etc/udev/rules.d/99-mpi4008-ads7846.rules
  SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{name}=="ADS7846 Touchscreen", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 1 0 -1 0 1"

For a "right" rotation according to Screen Configuration (HDMI port on the bottom as you look at the screen), this matrix worked: 0 1 0 -1 0 1 (this is the example above)

For a "left" rotation (HDMI port on the top): 0 -1 1 1 0 0

For an "inverted" rotation (HDMI port on the right): -1 0 1 0 -1 1

@Boaztheostrich
Copy link

This is incredibly interesting, thank you for taking the time to do this research. I am working on a few projects currently but I am very interested in trying your solution in the future.

@pb00001
Copy link

pb00001 commented Dec 16, 2023

This worked perfectly!

@pl804
Copy link

pl804 commented Sep 23, 2024

@vitorio Thanks for sharing this. This looks amazing.

I just tried this with an RPI 4 and MPI4008 on Bookworm Desktop.

For some reason, when I add the dtoverlay line to /boot/firmware/config.txt below the dtparam=spi-on line (at the top of the file), it disables SPI. (Despite enabling in UI and rasp-config, when I ls /dev/spi*, nothing shows up; and when I remove the line, /dev/spidev0.0 reappears.)

Does the dtoverlay line need to go in a specific section in config.txt, or do I need to comment out any of the other dtoverlay lines in the file? (There are a few others, as I'm running PiKVM with an HDMI CSI bridge on the same RPI 4.)

@vitorio
Copy link
Author

vitorio commented Sep 23, 2024

@pl804 If you copy-and-pasted from your config.txt to here, you've a typo: it's dtparam=spi=on, two equals signs, but you wrote dtparam=spi-on, an equals sign and a minus sign, which I wouldn't expect to be parsed correctly, and so it wouldn't enable SPI.

If SPI is always on by default, you could also leave that line out entirely.

If your PiKVM hardware also uses SPI, the order of enabling SPI devices might also matter. You might try putting the dtoverlay=ads7846 line before the PiKVM-related lines, or after, and see if that makes a difference.

@pl804
Copy link

pl804 commented Sep 23, 2024

@pl804 If you copy-and-pasted from your config.txt to here, you've a typo: it's dtparam=spi=on, two equals signs, but you wrote dtparam=spi-on, an equals sign and a minus sign, which I wouldn't expect to be parsed correctly, and so it wouldn't enable SPI.

That was indeed a typo on my part. I have two equal signs in my config.txt.

If SPI is always on by default, you could also leave that line out entirely.

If your PiKVM hardware also uses SPI, the order of enabling SPI devices might also matter. You might try putting the dtoverlay=ads7846 line before the PiKVM-related lines, or after, and see if that makes a difference.

Ok, I'll move it around and see what I can find.

Thanks!

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

No branches or pull requests

4 participants