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
Best resolution for monitor is not respected at boot (native is 1366x768, effective is 1920x1080) #6142
Comments
As can be seen, the "First detailed timing is the preferred timing" and the DTD1 is 1366x768. |
I'll need to check the logic the kernel chooses, but:
does show the monitor reports 1920x1080 is native resolution. |
Complete boot from firmware to kernel:
|
Yeah, that does not seem correct and in fact justifies this being an allowed resolution, but historically the prefered one has been used until very recently (latest images from Noble) it started to do this. It might be something on Ubuntu's kernel, or it might be the latest firmware that I upgraded recently on Rpi4. |
As documented at https://www.raspberrypi.com/documentation/computers/config_txt.html#hdmi-pipeline-for-raspberry-pi-4-and-5, your 1366x768 isn't supported on Pi4 due to
Are you booting to a Window Manager (ie X11, Wayfire, or similar), or just to the console? Most of the window managers ignore native and preferred modes and go for the highest resolution. The kernel DRM framebuffer emulation I seem to recall does go for the preferred mode (if available), but otherwise the largest. You can override it with a |
Wow, that is very specific:
Indeed this seems to be the reason for the mode to be excluded. Indeed I was using that monitor in a rpi3 where it worked great at native resolution and after moving it to pi4 it started to behave like this (but I also upgraded the firmware and ubuntu versions at the same time so it was not clear where the issue was). One thing that I would expect then is that, according to the documentation quoted above, it would discard DTD1 and fall back to DTD2 (which is indeed 1280x720), but instead it went for a different one. Thank you very much for pointing this out. I will test overriding the resolution in kernel cmdline and confirm here. |
Answering your previous question, I'm only using the console. No graphical environment on this device. On the video mode override, it mostly worked. Kernel still gets the screen at 1920x1080p when boot starts but later, almost at the end of the boot (but before init/systemd) it switches to 1280x720p. I used "video=HDMI-A-1:1280x720@60" at the end of cmdline.txt. Just as a curiosity I tried forcing the "1366x768@60" mode and the screen flashes but comes back still in 1080p. |
Describe the bug
Booting linux on a Raspberry Pi 4 B 2GB with a monitor that has native resolution of 1366x768 plugged in the HDMI0 port, it does get image but image is very low quality and letters seem very small, a consequence of actual chosen resolution for boot being 1920x1080 instead.
The EDID does list the correct mode and does mention that that is the prerefed one, but it seem not to be respected.
Steps to reproduce the behaviour
Boot current image of ubuntu in a raspberry pi 4 b and watch chosen resolution at boot time (from firmware to kernel).
More details below.
Device (s)
Raspberry Pi 4 Mod. B
System
I don't think the distribution matters here because it seems to happen before that, but in any case I'm testing with the just released Ubuntu noble preinstalled image for arm64+raspi, server edition (not sure if desktop edition would make any difference).
Logs
The firmware boots:
As you can see, the EDID is correctly received, and it does indicate that best resolution is 1280x720, which does not seem correct but at least would not be too far from it.
As soon as the kernel starts and the four raspberries appear at the top of the screen, the resolution is already wrong at 1920x1080. It does finish booting and when I get a chance to run commands, I can see that:
This happens both with config.txt overlay for "vc4-kms-v3d", for "vc4-fkms-v3d" or without any of them.
I'll add the decoded EDID next.
Additional context
No response
The text was updated successfully, but these errors were encountered: