Bug 456697 - [Wayland] Please provide a means to specify a custom modeline
Summary: [Wayland] Please provide a means to specify a custom modeline
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: platform-drm (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland-only
: 472321 491183 505496 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-07-14 01:33 UTC by Russell Haley
Modified: 2025-09-07 07:03 UTC (History)
30 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 kostadinshishmanov 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.
Comment 7 Zamundaaa 2024-08-02 19:02:56 UTC
*** Bug 491183 has been marked as a duplicate of this bug. ***
Comment 8 Syboxez 2024-12-31 21:53:35 UTC
Similar issue being tracked here, hopefully to open discussion on some sort of potential universal solution for Wayland modeline setting/switching

https://github.com/antonioginer/switchres/issues/102
Comment 9 Zamundaaa 2025-01-10 16:30:38 UTC
*** Bug 472321 has been marked as a duplicate of this bug. ***
Comment 10 Zamundaaa 2025-02-17 17:20:27 UTC
*** Bug 498573 has been marked as a duplicate of this bug. ***
Comment 11 Zamundaaa 2025-02-17 18:01:57 UTC
*** Bug 498573 has been marked as a duplicate of this bug. ***
Comment 12 Roke Julian Lockhart Beedell 2025-05-07 23:23:06 UTC
(In reply to Russell Haley from comment #0)

Although the original FR's description focusses upon a custom refresh rate / frequency, would this also encompass applying a custom resolution? It appears to, based upon the example commands provided, but an explicit confirmation would be useful. (Otherwise, a pointer to the relevant FR would be even more so. 🤍)
Comment 13 Russell Haley 2025-05-08 16:25:34 UTC
(In reply to Roke Julian Lockhart Beedell from comment #12)
> (In reply to Russell Haley from comment #0)
> 
> Although the original FR's description focusses upon a custom refresh rate /
> frequency, would this also encompass applying a custom resolution? It
> appears to, based upon the example commands provided, but an explicit
> confirmation would be useful. (Otherwise, a pointer to the relevant FR would
> be even more so. 🤍)

Yes, see that Bug 472321 "[WISHLIST] Add custom resolution support." was marked duplicate of this one.
Comment 14 Zamundaaa 2025-06-27 21:06:47 UTC
*** Bug 505496 has been marked as a duplicate of this bug. ***
Comment 15 rlk 2025-08-05 22:03:43 UTC
Use case: my work laptop is 1920x1080, but I use VNC to display it on a 4K monitor (this avoids having to deal with a KVM switch or an auxiliary output, and lets me use the second monitor for personal use when I'm not working).  I force the laptop screen to 4K with this script.  Of course, the laptop screen is essentially unreadable with this, but it's OK for this purpose.  Panning would not work correctly; VNC would simply display the 1920x1080 viewport.

This (along with ensuring that krfb works with wayland) is probably my key blocker to being able to switch off X.

```
modename=2160p
# Force the display 
if [[ -n "${DISPLAY:-}" && $DISPLAY = ':0' ]] ; then
    __xrandr_data="$(xrandr -q)"
    __xrandr_port="$(awk '/connected primary/ { print $1; exit}' <<< "$__xrandr_data")"
    if ! grep -q 3840x2160 <<< "$__xrandr_data" ; then
        if [[ -n "$__xrandr_port" ]] ; then
            # shellcheck disable=2046
            xrandr --newmode $(echo "$modename"; cvt 3840 2160 60 | perl -ane 'if (/^Modeline/) { shift @F; shift @F; print "@F\n";}')
            xrandr --addmode "$__xrandr_port" "$modename"
        fi
    fi
    xrandr --output eDP-1 --auto --scale 2
    xrandr --output "$__xrandr_port" --scale 2 --mode "$modename" --fb "3840x2160" --panning "3840x2160"
    unset __xrandr_port
    unset __xrandr_data
fi
```
Comment 16 mrturret 2025-09-01 17:25:40 UTC
My usecase is for using a CRT monitor though a displayport to VGA adapter. Adapters like this don't actually take any kind of EDID information from the display, and use a generic set of display modes instead. This is a problem, as I would like to run it at 70hz, but am unable to. I've tried to force a custom EDID with no luck.
Comment 17 YAFU 2025-09-07 07:02:37 UTC
My use case is because I have a monitor with a common problem with IPS monitors with a certain defect, where barely visible (but annoying) vertical bands/lines appear in certain pure colors like orange or blue using native refresh rates:
https://www.reddit.com/r/Windows10/comments/bvxxr3/vertical_lines_in_solid_colorsicons

https://www.dell.com/community/en/conversations/monitors/u2421e-light-vertical-lines/647f8d8ff4ccf8a8dee22058

The only way to solve the problem is to configure very low refresh rates that are not specified in the EDID. With X11 and proprietary NVIDIA I can configure new modes for these non-standard refresh rates by configuring some options in xorg.conf and then setting the newmode on the fly with xrandr. With Wayland I haven't found a way to configure my own custom refresh rates, so I would appreciate this feature where the user can configure their own resolutions and refresh rates on KDE/Kwin.