| Summary: | [Wayland] Please provide a means to specify a custom modeline | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Russell Haley <yumpusamongus+kde> |
| Component: | platform-drm | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | 4wy78uwh, accounts+kde, ar, backslashvortex, cfeck, chermnykh2001, chrismaltba, dion, forestbeasts, kostadinshishmanov, libre, miranda, mrturret, nate, nathan, o.freyermuth, pallaswept, postix, rlk, sandboxgamergr, shtetldik, slonkazoid, syboxez, tagwerk19, tux, victor.loucao, wiagn233, wielkiegie, xaver.hugl, yafulinux |
| Priority: | NOR | Keywords: | wayland-only |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=356818 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
*** This bug has been marked as a duplicate of bug 356818 *** (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. (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! 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. (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. (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. *** Bug 491183 has been marked as a duplicate of this bug. *** 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 *** Bug 472321 has been marked as a duplicate of this bug. *** *** Bug 498573 has been marked as a duplicate of this bug. *** *** Bug 498573 has been marked as a duplicate of this bug. *** (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. 🤍) (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. *** Bug 505496 has been marked as a duplicate of this bug. *** 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
```
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. 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. |
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.