Refresh rate change requests to 40Hz are "adjusted" back to 60Hz

This change was made by a bot.

Please test latest mainline kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4-rc5/

I'll switch to Eoan Ermine in the beginning of November and report back. Hopefully it will be enough !

I made the switch to 19.10 and the problem is the same in the logs. There is a slight difference however, the screen doesn't flicker any more upon the change request. I suppose it now detects the adjusted modeline is the same as the current one, hence nothing to do.

Here's some output extracted from dmesg (ISO date format) :

2019-11-04T16:39:13,088276+01:00 [drm:intel_dump_pipe_config [i915]] requested mode:
2019-11-04T16:39:13,088290+01:00 [drm:drm_mode_debug_printmodeline [drm]] Modeline "": 0 92450 1920 1968 2000 2080 1080 1083 1088 1111 0x0 0x9
2019-11-04T16:39:13,088323+01:00 [drm:intel_dump_pipe_config [i915]] adjusted mode:
2019-11-04T16:39:13,088336+01:00 [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 60 140490 1920 1972 2007 2094 1080 1083 1089 1118 0x48 0x9

So it's the current 19.10 kernel (5.3.0-19-generic). I'm considering trying v5.4-rc5. I will report back once (and if) it's done.

I switched to Focal in May and the bug is still there. The EDID workaround still works.

I must be the only one switching to 40Hz sometimes, or it only affects my GPU, which I doubt (Intel HD Graphics 4600, CPU Core i7-4710MQ).

Got a new laptop w/144Hz and 60Hz display frequencies available, installed Hirsute.

Same problem, this time when trying to switch to 60Hz :
[ +0,000082] i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[ +0,000080] [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 60 342060 1920 1968 2000 2080 1080 1090 1095 2740 0x40 0xa
[ +0,000030] i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[ +0,000081] [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 144 342060 1920 1968 2000 2080 1080 1090 1095 1142 0x48 0xa

As a side note, on Wayland sessions, it seems it tries to behave like it did switch to 60Hz, with glxgears vsyncing at around 70Hz. Strange...

I suppose I should go upstream for this bug, since it doesn't seem it will be addressed any time soon here. I didn't mod my EDID yet, but the workaround likely still works. I will come back if it doesn't.

Unsure if this is related, but I'm seeing the same issue with both the 21.04 vendor kernel and 5.13.8. I have a 165 Hz screen, and the Intel iGPU will only run it at 60 Hz. If I switch to the discrete Nvidia GPU in the BIOS, I get 165 Hz and I'm able to switch to 60 Hz.

First I switch from "165 Hz" to 60:
Aug 5 10:59:12 ukyo kernel: [ 247.263181] [drm:drm_mode_debug_printmodeline [drm]] Modeline "": 60 282670 2560 2608 2640 2720 1600 1603 1609 1732 0x0 0x9
Aug 5 10:59:12 ukyo kernel: [ 247.263307] [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": 60 282670 2560 2608 2640 2720 1600 1603 1609 1732 0x48 0x9
Aug 5 10:59:12 ukyo kernel: [ 247.263521] [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": 60 282670 2560 2608 2640 2720 1600 1603 1609 1732 0x40 0x9

Then I attempt to switch from 60 Hz to 165 Hz:
Aug 5 10:59:22 ukyo kernel: [ 257.078950] [drm:drm_mode_debug_printmodeline [drm]] Modeline "": 165 777340 2560 2608 2640 2720 1600 1603 1609 1732 0x0 0xa
Aug 5 10:59:22 ukyo kernel: [ 257.079075] [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": 60 282670 2560 2608 2640 2720 1600 1603 1609 1732 0x48 0x9
Aug 5 10:59:22 ukyo kernel: [ 257.079266] [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": 60 282670 2560 2608 2640 2720 1600 1603 1609 1732 0x40 0x9

I've tried adding a custom modeline to Xorg to work around this. It sees the modeline, but it doesn't do anything.

I'll try the EDID hack. If the Nvidia driver is able to do it, probably something wrong with the EDID parsing if the EDID hack works?

My previous laptop (which I replaced just 2 days ago) didn't have this problem. However, it was a i7 10875h with a 144 Hz screen. The new laptop is a Tigerlake 11980HK. Maybe it's the difference in refresh rate or my case of a bug with the newer iGPU?

I'll research to see if any of my monitor outputs go through the Intel GPU and I can test against one of my 144 Hz external monitors.

Oliver,

If you file the bug upstream or already have, can you please share the link?

Thanks!

Hi Cameron,

I didn't go upstream yet. I suppose upstream bugs should be filed to the Intel Open Source Technology Center (https://01.org/), but I'm not sure. Or maybe to the Linux kernel since it's an in-tree module after all...

From what I understand, the Intel module fails to switch to anything else than the refreshing rate that's on the preferred (i.e. first mentioned on EDID) DTD.

However, it seems to me the first DTD usually has the highest refresh rate, which makes your problem strange. Could that mean the 60 Hz DTD is the preferred one on your laptop's panel, despite it being able to go up to 135 Hz ?

Also, are you sure you're using true Xorg, not Xorg on Wayland ? Bcos any readings on the latter would be mostly irrelevant as they don't necessary reflect the reality (Xorg on Wayland being only a compatibility layer). From what I've seen, when asking for a reduced refresh rate, even if it fails, Wayland seems to try nearing the target refresh rate by syncing frames to a factor of the effective refresh rate. That's why on a previous post, when trying to get 60Hz on my 144Hz-capable monitor, I was getting 72 fps with glxgears... But in your case of trying to get 135 from an effective 60, Wayland surely can't do this trick.

Anyway, you can get the EDID from sysfs easily. On my current config, mine is in /sys/class/drm/card0-eDP-1/edid. You should have something similar. To quicky decode the EDID, you can use edid-decode (from the edid-decode package), most basically like this :

edid-decode /sys/class/drm/card0-eDP-1/edid

Then you can create a modified, hex-edited EDID file, with the two DTDs swapped, put it somewhere under the /lib/firmware directory and add the following in a file inside /etc/modprobe.d :
options drm edid_firmware=eDP-1:mydir/myedid.bin

eDP-1 is your connector name, for me it's eDP-1 but for you it can be something else. You can also omit "eDP-1:", in which case the EDID will apply to all connectors. While I didn't check myself, I suppose it will be a problem if you plug your laptop on an external monitor.

Additionally, if the module is loaded while the system is still on the initramfs, it won't work since your modified EDID won't be there, hence you will have to add it with an initramfs hook in /etc/initramfs-tools/hooks. The file should look like this :
--- File starts after this line -----
#!/bin/sh

PREREQ=""

prereqs () {
 echo "$PREREQ"
}

case "$1" in
 prereqs)
  prereqs
  exit 0
  ;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_file edid /lib/firmware/mydir/myedid.bin
----- File ends before this line -----

Make the file belong to root:root and mode 555 (readable/executable by all). You should then update your initramfs with update-initramfs -u (to update the initramfs for the current running kernel) or update-initramfs -u -k all (to update for all installed kernels, or you can specify a kernel). And reboot...

Hope this helps !

My EDID doesn't seem to parse correctly... Which is probably at least part of the problem. The fact that it works on the Nvidia driver suggests that EDID parsing could be the problem (I'm sure Nvidia does their own EDID parsing).

Anyway, I did attempt to play around with the EDID... I'm able to get the EDID into the initramfs and everything else, but I didn't see anything in dmesg to show it's using my EDID.

I tried to hack my EDID, but I could only find one mode... The 60 Hz mode, but this is likely related to the parsing issues I mentioned above.

If I grab the EDID when running with the dGPU, it doesn't give me errors and has a 165 Hz mode. That's the EDID I tried to load.

I did file a kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=214011