https://bugs.kde.org/show_bug.cgi?id=456697

            Bug ID: 456697
           Summary: [Wayland] Please provide a means to specify a custom
                    modeline
           Product: kwin
           Version: unspecified
          Platform: unspecified
                OS: Linux
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: wayland-generic
          Assignee: kwin-bugs-n...@kde.org
          Reporter: yumpusamongus+...@gmail.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to