Description of problem: The native resolution 2560x1080 of ultrawide monitor (21:9) is not available in a gnome/wayland session. Version-Release number of selected component (if applicable): OS: Fedora 32 5.8.11-200.fc32.x86_64 (also confirmed on Fedora 33 and Ubuntu 20.04) Gnome: 3.36.6 GPU: Iris Plus Graphics G1 (Ice Lake) Driver: i915 Monitor: LG 29WK500 (both monitor and GPU have support for the desired resolution) Full logs: https://linux-hardware.org/?probe=1acb88832c Steps to Reproduce: 1. Plug in the external ultrawide monitor LG 29WK500 (and possible others) 2. Login in a gnome/wayland session Actual results: Native / maximum monitor resolution is not automatically selected. Gnome display settings does not show the 2560x1080 option (maximum available: 1920x1080) Expected results: Monitor was detected with the native maximum resolution. Gnome display settings contained the 2650x1080 resolution for selection. Additional info: - When logged in gnome/X11, it's possible to manually set the desired resolution using: ``` gtf 2560 1080 60 xrandr --newmode "2560x1080_60.00" 230.76 2560 2728 3000 3440 1080 1081 1084 1118 -HSync +Vsync xrandr --addmode HDMI-1 2560x1080_60.00 xrandr --output HDMI-1 --mode "2560x1080_60.00" -v ``` - Don't seem a hardware issue, since it works in a gnome/X11 session or windows. (same hardware) - Strangely, same OS/gnome/Wayland/Monitor/driver (all up to date) works in another laptop with 'Intel Skylake GT2 [HD Graphics 520]' under gnome/wayland. The only (?) relevant change is the GPU (Iris Plus Graphics G1 (Ice Lake). If it is a driver/hardware issue, why it only happens in wayland and not X11? - Passing kernel boot does not work: (tried individually) ``` video=XWAYLAND1:2560x1080@60 video=HDMI-1:2560x1080@60 i915.enable_guc=-1 i915.enable_guc=2 ``` - Trying to build a custom edid.bin didn't work due compilation error: `edid.S:175: Error: invalid operands (*UND* and *ABS* sections) for `<<'` https://github.com/akatrevorjay/edid-generator/issues/19 - EDID does report the available resolution/timmings: ``` cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode Detailed Timing Descriptors: DTD 1: 2560x1080 59.978 Hz 64:27 66.636 kHz 181.250 MHz (798 mm x 334 mm) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront 3 Vsync 10 Vback 18 Vpol N ``` Possible related issues: #1314923 - Ultra-Widescreen monitor Resolution option not provided for LG25UM57 (2560x1080) #1292883 - nouveau custom edid https://ask.fedoraproject.org/t/maximum-possible-resolution-is-not-detected-in-gnome-wayland-with-i915-gpu/9366 I appreciate any help with this issue. Best regards, Mario
PS: I noticed that hw-probe says 'DE: GNOME (X11) - GDM', but it is running Wayland (as confirmed by the attached screenshot). Not sure if this is a hw-probe reporting bug. https://www.dropbox.com/s/3ws9pol4p3uag9n/Screenshot%20from%202020-09-28%2018-05-04.png?dl=0
Some extra logs: LENOVO S145: NOT WORKING https://linux-hardware.org/?probe=5fc4581001 LSHW: https://www.dropbox.com/s/cfvboextk7f1ysn/lenovoS145-LG29WK500-lshw.txt?dl=0 XRANDR: https://www.dropbox.com/s/p1isu3k5iiyhb4l/lenovoS145-LG29WK500-xrandr.txt?dl=0 EDID-DECODED: https://www.dropbox.com/s/w9aqrn5iatcncjb/lenovoS145-LG29WK500-edid-decoded.txt?dl=0 DMESG: https://www.dropbox.com/s/247rv2ehx39z02g/lenovoS145-LG29WK500-dmesg.txt?dl=0 ACER ASPIRE E15: WORKING https://linux-hardware.org/?probe=4a7be797aa LSHW: https://www.dropbox.com/s/d7la4gu8ljeqzn1/acerE15-LG29WK500-lshw.txt?dl=0 XRANDR: https://www.dropbox.com/s/x5k96eyzhzqxzwk/acerE15-LG29WK500-xrandr.txt?dl=0 EDID-DECODED: https://www.dropbox.com/s/2powhbn0zzy86q1/acerE15-LG29WK500-edid-decoded.txt?dl=0 DMESG: https://www.dropbox.com/s/vjuqlaipovjhq7r/acerE15-LG29WK500-dmesg.txt?dl=0 Monitor LG29WK500 and HDMI 2.1 48Gbps in both. Software/driver/cable/monitor are the same in both. Apparently the only relevant change is the Intel GPU. Since the decoded EDID, SO, driver, cable, monitor are exactly the same, what could be the issue? Thanks
Using the laptop in 'pure' UEFI mode solves the issue. Apparently it is related to the BIOS/legacy mode only. Laptop has three boot modes: A- UEFI B- UEFI, with Legacy/BIOS support enabled C- Legacy/BIOS mode Strangely, even if the legacy support is only enable but Fedora installed and running in UEFI mode the issue occurs. I assumed that in mode B the PC would detect and enable the boot from a HDD with a BIOS installed OS, but after booting from an UEFI device and on it would behave the same.
Wayland is a set of protocols, the bug described here is not with Wayland but with the implementation - Moving to mutter where this is implemented.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still an issue in fedora 34
I am having the same issue with the same screen and a Intel HD620 graphics card, unfortunately changing the laptop to a pure UEFI mode did not fix the issue for me. Things I tried: - adding the kernel parameters: - video=XWAYLAND1:2560x1080@60 - video=XWAYLAND2:2560x1080@60 - video=HDMI-1:2560x1080@60 - video=HDMI-A-1:2560x1080@60 - video=2560x1080@60 (when I did this the logs seen when starting the laptop by pressing F3 where in the correct resolution but when booted I was back at the wrong resolution) - compiling the edid but I got the same issue as Mario. I think this is because the VESA specifications don't have the a CTV for ultrawide (https://glenwing.github.io/docs/VESA-EEDID-A2.pdf page 47) @mario.baldini did you do something else that fixed the issue for you next to disabling legacy boot support?
Hello Tim, As I recall the end fix was really related with the BIOS support. (since it has been some time, I'm only 90% of this :) But I will try to reproduce the error with a current Fedora version. Also, I don't know exactly which component is really the responsible for this. Does anyone have any specific log/test that I could perform to get further info?
Hi All This bug has been reported upstream, and is related to the i915.ko driver and display modes associated with clock rates beyond 165000 kHz https://bugs.freedesktop.org/show_bug.cgi?id=111553 https://gitlab.freedesktop.org/drm/intel/-/issues/393 Comment #3 (Ville Syrjala) summarizes: "So yeah, basically that means that you're trying to drive it out of spec, or the manufacturer messed up and used a dual-mode chip that misreports its maximum TMDS clock. We have to err on the side of caution and filter out modes that look out of spec, doing otherwise would lead to some poor chap getting a black screen. However if you want you can still keep driving it out of spec with the custom modeline. I guess the question is how would you add one under whatever wayland compositor you use." With Xorg at least, a custom modeline can be used to override the condition, but this is not possible with Wayland composotiors. Here's a workaround created by user Michael Hanselmann (hansmi)... https://github.com/hansmi/fake-dp-dual-mode Ideally, though a kernel parameter could be introduced to perhaps inhibit this (pixel clock limit) behavior in the driver code where needed.
Hi All This bug has been reported upstream, and is related to the i915.ko driver and display modes associated with clock rates beyond 165000 kHz https://bugs.freedesktop.org/show_bug.cgi?id=111553 https://gitlab.freedesktop.org/drm/intel/-/issues/393 In comment #3 of the bug report (Ville Syrjala) summarizes: "So yeah, basically that means that you're trying to drive it out of spec, or the manufacturer messed up and used a dual-mode chip that misreports its maximum TMDS clock. We have to err on the side of caution and filter out modes that look out of spec, doing otherwise would lead to some poor chap getting a black screen. However if you want you can still keep driving it out of spec with the custom modeline. I guess the question is how would you add one under whatever wayland compositor you use." With Xorg at least, a custom modeline can be used to override the condition, but this is not possible with Wayland composotiors. Here's a workaround created by user Michael Hanselmann (hansmi)... https://github.com/hansmi/fake-dp-dual-mode Ideally, though a kernel parameter could be introduced to perhaps inhibit this (pixel clock limit) behavior in the driver code where needed.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.