[i915] HDMI monitor's native resolution (EDID detailed mode) not available, defaults to 1080p instead

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1901470/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

  apport-collect 1901470

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Yep, the detailed mode 2560x1440 is in the EDID returned by the monitor:

Standard Timings: none
Detailed mode: Clock 241.500 MHz, 598 mm x 336 mm
               2560 2608 2640 2720 ( 48 32 80)
               1440 1443 1448 1481 ( 3 5 33)
               +hsync -vsync
               VertFreq: 59.951 Hz, HorFreq: 88.787 kHz
Display Product Serial Number: GBLMQS047683
Display Range Limits
  Monitor ranges (Bare Limits): 24-60 Hz V, 30-140 kHz H, max dotclock 300 MHz
Display Product Name: ROG PG278QR

I would like to check to see if the problem is occurring in the kernel and not just in Xorg. Please run:

  grep . /sys/class/drm/*/modes > modes.txt

and then attach the resulting text file here.

output from: grep . /sys/class/drm/*/modes > modes.txt

Thanks. Looks like this is also a kernel bug...

This change was made by a bot.

Status changed to 'Confirmed' because the bug affects multiple users.

Follow post of a work around that automatically enables the resolution I want.

I added a file named: 45custom_xrandr_settings
in folder: /etc/X11/Xsession.d

containing:
xrandr --newmode "Mode 0" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync
xrandr --addmode HDMI-1-1 "Mode 0"

This will cause X11 to use the 2560x1440 resolution after reboot.

Please test latest drm-tip kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/

And file a bug agains Intel graphics if the issue persists:
https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs

Comment #29 shows this problem is originating in the i915 kernel driver. So there's no need to include 'xorg-server' here, Xorg is only following the (incomplete) list of modes exposed by the kernel.

It looks like this issue keeps happening with HDMI for i915 users. Maybe Intel is being conservative (or just accurate) with bandwidth limitations... Anyone affected, please follow the instructions in comment #34.

Also note that 3K/4K-wide at 60Hz requires an HDMI 2.0 port and cable, or for you to limit your refresh rate to 30Hz (not recommended for desktop usage) for HDMI v1.4:

https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_standard_video

Ideally use DisplayPort if you can, because it has supported higher resolutions and higher bandwidth than HDMI for a long time already.

Anyone affected by this bug, please tell us if it exists in a live session of Ubuntu 21.04:

  https://ubuntu.com/download/desktop

and if it does then please also follow the instructions in comment #34.

If started a live session with Ubuntu 21.04 and the problem exists also (as described in "my" bug 1929456).
I run
 grep . /sys/class/drm/*/modes > modes.txt
and will attach the output file (renamed).

The workaround (as described in "my" bug 1929456) helped there also.

I wasn't able to follow the instructions in comment #34, because I didn't understand what to do there. Maybe a link to an explanation how to do this could help, so I could do (or at least try) it.

For comment #34, click on the link and then click the 'amd64' directory. Then download all the files that don't have "lowlatency" in their name. You don't need "lowlatency". Now you can install your kernel files in a single command:

  sudo dpkg -i *.deb

and reboot.

I'm guessing a common cause of this bug is low quality HDMI cables. If you're stuck at 1080p then that suggests the cable is only HDMI 1.2. To achieve 1440p at 60Hz you will need an HDMI 1.4 cable. And to achieve 2160p (4K) at 60Hz you will need an HDMI 2.0 cable AND a modern GPU to plug it into. 3K and 5K requirements are somewhere in the middle depending on the vertical resolution of the monitor.

https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_standard_video

If you're shopping for a new monitor then it's best to find one with DisplayPort (or USB-C) which doesn't have quite as severe limitations as HDMI does.

Hi Daniel,

Thanks for the help and the quick response.

I don't see any marking on the HDMI cable I'm using so I'm guessing it
isn't one a high quality one.

So, I played around with the refresh rates and got it to work at a lower
refresh rate:

xrandr --addmode HDMI-2 2560x1440_24.00
xrandr --output HDMI-2 --mode 2560x1440_24.00
xrandr --newmode "2560x1440_24.00" 113.75 2560 2648 2904 3248 1440 1443
1448 1463 -hsync +vsync

This ties in with the poor quality cable idea.

Thanks again for the assistance,
Jerry.

On Wed, Dec 15, 2021 at 3:00 AM Daniel van Vugt <email address hidden>
wrote:

> I'm guessing a common cause of this bug is low quality HDMI cables. If
> you're stuck at 1080p then that suggests the cable is only HDMI 1.2. To
> achieve 1440p at 60Hz you will need an HDMI 1.4 cable. And to achieve
> 2160p (4K) at 60Hz you will need an HDMI 2.0 cable AND a modern GPU to
> plug it into. 3K and 5K requirements are somewhere in the middle
> depending on the vertical resolution of the monitor.
>
>
> https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_standard_video
>
> If you're shopping for a new monitor then it's best to find one with
> DisplayPort (or USB-C) which doesn't have quite as severe limitations as
> HDMI does.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1954840).
> https://bugs.launchpad.net/bugs/1901470
>
> Title:
> [i915] HDMI monitor's native resolution (EDID detailed mode) not
> available, defaults to 1080p instead
>
> Status in linux package in Ubuntu:
> Confirmed
> Status in linux-hwe-5.11 package in Ubuntu:
> Confirmed
>
> Bug description:
> The PG278QR monitor supports 2560x1440. After installing Ubuntu 20.4,
> the max resolution presented in the Settings app is 1920x1080, and
> this resolution is the one that it uses. Switching between the Nvidia
> driver or the Intel driver (laptop has low-power intel gpu too)
> doesn't correct the problem.
>
> Digging in deeper, based on
>
> https://wiki.ubuntu.com/X/Troubleshooting/Resolution#Problem:__Wrong_resolutions.2C_refresh_rates.2C_or_monitor_specs
>
> Under Wrong resolutions/refresh rates/or monitor specs, step 3 is to
> use get-edid | parse-edid.
>
> After applying the mode that I wanted manually via xrandr --newmode
> and xrandr --addmode, I was able to select the max resolution of the
> monitor and works correctly, until reboot. I will add it to my
> xorg.conf next.
>
> Here is information I collected:
>
> output from xrandr after fresh boot:
>
> ~$ xrandr
> Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
> eDP-1-1 connected primary 1920x1080+0+0 (normal left inverted right x
> axis y axis) 344mm x 193mm
> 1920x1080 60.01*+ 60.01 59.97 59.96 59.93
> 1680x1050 59.95 59.88
> 1600x1024 60.17
> 1400x1050 59.98
> 1600x900 59.99 59.94 59.95 59.82
> 1280x1024 60.02
> 1440x900 59.89
> 1400x900 59.96 59.88
> 1280x960 60.00
> 1440x810 60.00 59.97
> 1368x768 59.88 59.85
> 1360x768 59.80 59.96
>...

I'm having a similar issue in Jammy again with an HDMI connected 2k monitor. The issue here being that the monitor works on boot up, but experiences this problem after a few hot plugs. Has someone found a follow-on ticket similar to this?

Dave,

The first thing to check is whether new cables fix the problem.

The second thing to check is whether the latest development kernel already has a fix that works for you:
https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/

Third is to report your own bug upstream:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

It's best that everyone reports their own issue upstream because the root causes of these bugs are so hidden that the solutions are likely to be different for different people.

I am not convinced this is a bug. I've had the same issue with an LG ultrawide (2560x1080) ever since kernel +4.5.7. Linux Mint 18 (4.4 kernel) the monitor worked at its native resolution out of the box. LM19 (think it was a 4.15 kernel) max is 1920x1080 unless you manually set the resolution with xrandr. Did some testing and the last kernel to 'work' was 4.5.7.

I think the problem lies in the EDID implementation by LG. read-edid | parse-edid will list all the modes. 2560x1080 is mode 0, 1920x1020 is mode 11. The "PreferredMode" output by read-edid is mode 11. That I think is the problem. I have no idea how the "PreferredMode" is determined from the EDID.