agherzan / meta-raspberrypi

Yocto/OE BSP layer for the Raspberry Pi boards
https://www.yoctoproject.org/
MIT License
532 stars 410 forks source link

x11 always starts with 1024x768 resolution #656

Closed horihel closed 2 years ago

horihel commented 4 years ago

Description

Although bootloader and virtual terminal will detect the correct screen size and switch to the correct resolution, once you start x11 it will switch to a 1024x768 framebuffer, regardless of monitor size.

it is possible to switch to a correct resolution with xrandr, but proper behaviour would be x11 choosing the best resolution automatically (like it does in raspbian with the same configuration).

I compared configuration files with raspbian (which works correctly) and could not find any difference in config files.

I tested on yocto-3.1/meta-raspberry:dunfell on a RPi4 - i only have a 4 model here, so i cannot crosstest with an earlier chipset.

tested on different monitors with different sizes/aspect ratios... always 1024x768

X11 detects all possible resolutions according to Xorg.0.log.

Steps to reproduce the issue:

  1. bitbake core-image-x11
  2. boot system on rpi4
  3. watch boot

Describe the results you received:

system boots, console comes up with correct resolution once the system starts x11, resolution gets switched to 1024x768

Describe the results you expected:

x11 comes up with correct resolution

Additional information you deem important (e.g. issue happens only occasionally):

Build Configuration: BB_VERSION = "1.46.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "raspberrypi4" DISTRO = "poky" DISTRO_VERSION = "3.1" TUNE_FEATURES = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "my-yocto-3.1:5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478" meta-raspberrypi = "dunfell:ac717473e89b835da2eb418b0507644d71aa61c2"

no changes to local.conf except MACHINE.

Additional details (revisions used, host distro, etc.): Xorg.0.log

dmesg.log

rcla commented 4 years ago

The same thing happened to me, I solved it by changing the HDMI port of the rpi4, from HDMI-port1 to HDMI-port0 (closest to the USB-C power connector).

horihel commented 4 years ago

Just tested - no didn't help - still 1024x768.

To be fair - there is a workaround - you can add

xrandr --output HDMI-1 --preferred

to your xinit script and the resolution will switch to the correct one.

I'd still prefer x11 to actually behave the same as on Raspbian and come up in the correct resolution, but I'm unable to find out why it doesn't.

rcla commented 4 years ago

Do you use a micro-HDMI to HDMI adapter? or do you use a micro-HDMI to HDMI cable?

In my case, when I use the adapter, the resolution remains at 1024 x 768, both in yocto and in Raspi-OS.

I had to buy the cable for it to work properly.

You can try indicating the resolution you want in the config.txt file. https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

For example, to obtain a resolution of 1080p (1920x1080) 60 Hz, add the following lines:

# Hdmi 0 hdmi_group:0=1 hdmi_mode:0=16

# Hdmi 1 hdmi_group:1=1 hdmi_mode:1=16

horihel commented 4 years ago

i'm using the official micro-HDMI to HDMI cable from RaspBi (with the logo on it).

I don't want to hardcode the resolution, because in the end I don't know what the device is going to be connected to.

and I know the resolution is available and detected, because xrandr --output HDMI-1 --preferred will switch to the correct one.

Just for some reason, x11 chooses to not use the preferred resolution right from the start.

agherzan commented 2 years ago

@horihel any progress on this?

horihel commented 2 years ago

unfortunately no - I ended up putting the xrandr workaround into the startup script - that solved the problem for me.

Eventually the project I was working on got discontinued - so I can't tell if later updates fixed this.

Sorry.

agherzan commented 2 years ago

That's alright. I'll close this for now and we can pick it later if needed. Thanks for the update, @horihel.