Bug 456697 - [Wayland] Please provide a means to specify a custom modeline
Summary: [Wayland] Please provide a means to specify a custom modeline
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2022-07-14 01:33 UTC by Russell Haley
Modified: 2024-06-11 07:03 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Russell Haley 2022-07-14 01:33:56 UTC
In Xorg, it is possible to overclock a 60 Hz monitor to 70 Hz like so:

    xrandr --newmode  "1920x1080_70.00" 156.240  1920 1928 1960 2000  1080 1102 1110 1116  +HSync -VSync
    xrandr --addmode HDMI-1 "1920x1080_70.00"
    xrandr --output HDMI-1 --mode "1920x1080_70.00"

The timing parameters are generated by edid-decode, using the reduced blanking v2 formula to fit within the pixel clock limit of single-link DVI:

    edid-decode -X --cvt w=1920,h=1080,fps=70,rb=2

There is also an updated version of the conventional `cvt` program that can calculate RBv2 modes, at https://github.com/kevinlekiller/cvt_modeline_calculator_12/, but it isn't packaged in my distribution.  

Other applications include:

1. 48 Hz (or 72 if your monitor goes that high) for playing 24 Hz video without 3-2 pulldown.
2. Running games at lower vsync'ed frame rates on monitors that don't support VRR, like the Steam Deck's 40 Hz mode.
3. Exactly matching the refresh rates of screens from different vendors, although I've never needed it for this reason.
4. Conceivably, a user might even calculate non-standard 60 Hz modes with max pixel clock (165 MHz) and an extended front porch, similar to VRR, in order to reduce the probability of tearing in non-vsync'ed rendering.

There's supposedly a workaround by passing a fake EDID to the kernel, https://askubuntu.com/questions/973499/wayland-how-to-set-a-custom-resolution/973582#973582, but I couldn't get it (or any of the forks on github) to work. The tool in the kernel sources generated EDID blocks without correct headers or checksums. At that point the only way forward would've been writing a program to pull the connected monitor's EDID out of /sys/class/drm and patch it. And even if that worked, changing the EDID at runtime requires re-plugging the monitor and a kernel with debugfs enabled, which would be very annoying if you're experimenting with the limits of your monitor.
Comment 1 postix 2022-07-14 18:47:56 UTC

*** This bug has been marked as a duplicate of bug 356818 ***
Comment 2 Russell Haley 2022-07-14 22:30:40 UTC
(In reply to postix from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 356818 ***

The other bug is about exposing a UI for a thing that the Xorg server can do.  This one is about making it possible to do at all under Wayland.
Comment 3 postix 2022-07-15 09:13:37 UTC
(In reply to Russell Haley from comment #2)
> The other bug is about exposing a UI for a thing that the Xorg server can
> do.  This one is about making it possible to do at all under Wayland.

Alright!
Comment 4 Shmerl 2023-02-27 22:50:57 UTC
Any news on this? It would be very useful to work around bugs like this: https://gitlab.freedesktop.org/drm/amd/-/issues/1403

Right now it's impossible in the Wayland session.
Comment 5 tux 2023-11-14 21:06:55 UTC
(In reply to Shmerl from comment #4)
> Any news on this? It would be very useful to work around bugs like this:
> https://gitlab.freedesktop.org/drm/amd/-/issues/1403
> 
> Right now it's impossible in the Wayland session.

If you can get the full binary EDID from your monitor, you can edit it with something like Custom Resolution Utility (CRU) via wine. When importing the original EDID file in CRU, enable/check "Import complete EDID". After adding the desired refresh rates/modes, you can export the EDID to a new file (e.g. "/usr/lib/firmware/edid/your_edid.bin"). Then add the new EDID to your kernel boot line by adding "drm.edid_firmware=edid/your_edid.bin", which will get applied after a reboot. You can also try loading it directly and simulating a hotplug on your monitor. See here for more information: https://wiki.archlinux.org/title/Kernel_mode_setting#Forcing_modes_and_EDID

Custom Resolution Utility (CRU) via wine seems to work fine for me, but it may not work for you, so your mileage may vary.
Comment 6 kocelfc 2024-06-11 07:03:22 UTC
(In reply to tux from comment #5)
> (In reply to Shmerl from comment #4)
> > Any news on this? It would be very useful to work around bugs like this:
> > https://gitlab.freedesktop.org/drm/amd/-/issues/1403
> > 
> > Right now it's impossible in the Wayland session.
> 
> If you can get the full binary EDID from your monitor, you can edit it with
> something like Custom Resolution Utility (CRU) via wine. When importing the
> original EDID file in CRU, enable/check "Import complete EDID". After adding
> the desired refresh rates/modes, you can export the EDID to a new file (e.g.
> "/usr/lib/firmware/edid/your_edid.bin"). Then add the new EDID to your
> kernel boot line by adding "drm.edid_firmware=edid/your_edid.bin", which
> will get applied after a reboot. You can also try loading it directly and
> simulating a hotplug on your monitor. See here for more information:
> https://wiki.archlinux.org/title/Kernel_mode_setting#Forcing_modes_and_EDID
> 
> Custom Resolution Utility (CRU) via wine seems to work fine for me, but it
> may not work for you, so your mileage may vary.

Thanks for the suggestion, it also works for me.