raspberrypi
display_hdmi_rotate=1 doesn't work for 1080p (hdmi_mode=16) on raspberry pi cm3+
Describe the bug I use display_hdmi_rotate=1 on CM3+ with 720p without any issues If I want this rotation on 1080p, the screen gets garbled
To reproduce set display_hdmi_rotate=1 and HDMI mode 16, to set 1080p
Expected behaviour The screen should rotate fine as it does with 720p resolution.
Actual behaviour The picture is unreadable, fills the whole screen, but is damaged.
System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
- Which model of Raspberry: CM3+
- This is before the system boots up. Even u-boot shows its output unreadable
- Which firmware version: 7d9a298cda813f747b51fe17e1e417e7bf5ca94d (clean) (release) (start)
- Which kernel version, 5.4.83
Logs No error logs show after the examination via ssh after the system boots up
"display_hdmi_rotate" does not work on my RPi Zero 2W either. I tried several HDMI LCDs and display_hdmi_rotate only damage the image but performs no rotation during the boot. When KMS driver is loaded then "video=" parameter from cmdline is correctly respected but rotation BEFORE driver is loaded does NOT work.
Kernel version: 6.12.25+rpt-rpi-v8
config.txt settings affecting display do not work with the kms driver (because they are firmware settings and display is driven by kernel). You need to use linux side setting (video= on cmdline for console, and display configuration settings from desktop).
I'm talking about the boot time before KMS driver is loaded, immediately when Pi is powered on. All settings are correctly accepted except display_hdmi_rotate that corrupts display but does not rotate anything. "video=" is accepted correctly after KMS driver is loaded.
- power Pi on
- rainbow splash is shown
- kernel starts booting (raspberry logo + kernel log is displayed) - all settings from config.txt are accepted except of display_hdmi_rotate
- KMS driver is loaded
- display is correctly switched to mode set by video=
Correct. If the firmware sees that the vc4 overlay has been configured, then it blocks enabling the firmware side rotation.
Easiest option if your system locks onto the HDMI fast enough for there to be a visible issue is to set max_framebuffers=0 so that there is no framebuffer until vc4 has started.
I'm assuming you're also the person posting on https://forums.raspberrypi.com/viewtopic.php?t=388528
What is the reason that only rotation is blocked but other config.txt hdmi settings are correctly applied?
What is the reason that the rotation is blocked but adding the rotation settings corrupts the display?
Why enabling KMS driver should influence what happens before this KMS driver is loaded?
Rotation is done via a memory to memory operation triggered at the display frame rate, with the resulting buffer being the one that is actually rendered (I'd already said as much in https://forums.raspberrypi.com/viewtopic.php?p=2319152#p2319152). If permitted then it would be yet another thing that has to be stopped and torn down within the firmware at the point that vc4 takes over. Seeing as we're talking about a screen that is displayed for a matter of seconds, there is such limited gain that it has been viewed as not being worth supporting.
Enabling vc4-kms-v3d also switches from using bcm2708_fb to simple_framebuffer as the latter is lighter weight and designed for shutting down when a DRM driver wants to take over. The former supports extra features such as being able to change the framebuffer geometry and format, which are redundant for that boot screen.