SUMMARY When using a monitor with adaptive sync / variable refresh rate, extra fake refresh rates get automatically added to the "Refresh rate" list in "Display Configuration". For example, my monitor has refresh rates of 240, 165, 144, 120, and 60 Hz at its native resolution. Only these refresh rates can be found in its EDID and are also the only ones listed in Windows 10. But in KDE/Plasma the following refresh rates are listed: 240, 165, 144, 120, 96, 72, 60, 50, and 48 Hz. So fake refresh rates of 96, 72, 50, and 48 Hz are added. When I select 96 or 72 Hz, the monitors refresh rate does change to 96 or 72 Hz, but VRR stops working even though "Adaptive sync" is still set to "Automatic". When I select 50 or 48 Hz, the image becomes completely distorted. Even worse, the real refresh rate of 120 Hz gets overwritten by a fake 120 Hz so adaptive sync doesn't even work when I select 120 Hz. I have to run `kscreen-doctor -o`, look for the other 120 Hz, and apply it by running `kscreen-doctor output.DP-1.mode.5`. Both the real and the fake 120 Hz options look identical in the output of kscreen-doctor, so I have to try both to see which one is fake and which is real. Another indication that some of the listed refresh rates are fake is that after applying 120 Hz, I can apply 96 or 72 Hz without the monitor go black for a few seconds. The new fake refresh rate gets "applied" immediately with no delay/blanking whatsoever. Changing from a real refresh rate to a different real refresh rate always causes the monitor to black for a few seconds (just like in Windows 10). STEPS TO REPRODUCE 1. Connect high refresh-rate monitor with adaptive sync / VRR 2. Notice fake refresh rates added in Display Configuration 3. Try to use a fake refresh rate 4. VRR stops working or the image becomes distorted OBSERVED RESULT Extra fake refresh rates and/or real refresh rates that get overwritten by fake refresh rates. EXPECTED RESULT No fake refresh rates listed and no real refresh rates overwritten by fake refresh rates. If fake refresh rates must be added, it should be clear that they're not real and that VRR doesn't work with them, and real refresh rates should never be overwritten by a fake one. It would also be helpful if the output of `kscreen-doctor -o` would distinguish between fake and real refresh rates. SOFTWARE/OS VERSIONS Linux: 6.5.8 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION GPU: AMD RX 6650XT, using amdgpu drivers. This may be related to AMD's FreeSync Video mode, but I think it should be disabled as `/sys/module/amdgpu/parameters/freesync_video` defaults to 0. Here's some more info on that: https://www.phoronix.com/news/AMDGPU-FS-Video-Default-PS.
You can check the modes the kernel advertises with drm_info, but I'm 100% sure that KWin doesn't generate any such modes. There's probably a bug in the kernel that makes it wrongly enable freesync video modes; please report that to https://gitlab.freedesktop.org/drm/amd/-/issues If you give me the output of drm_info on your system though, maybe we can find a way to still mark these generated modes as such
(In reply to Zamundaaa from comment #1) > You can check the modes the kernel advertises with drm_info, but I'm 100% > sure that KWin doesn't generate any such modes. There's probably a bug in > the kernel that makes it wrongly enable freesync video modes; please report > that to https://gitlab.freedesktop.org/drm/amd/-/issues > > If you give me the output of drm_info on your system though, maybe we can > find a way to still mark these generated modes as such This is the output of `drm_info` on my system: https://invent.kde.org/-/snippets/2874
There's no flag that says they're generated, they're all "driver". So I'm afraid we can't even mark them as generated in kscreen-doctor, and the driver just has to make sure the modes it advertises actually work
(In reply to Zamundaaa from comment #3) > There's no flag that says they're generated, they're all "driver". So I'm > afraid we can't even mark them as generated in kscreen-doctor, and the > driver just has to make sure the modes it advertises actually work So this is a kernel/driver bug and not KDE's fault? Where should I report this bug then?
Yes. You can report the modes being generated despite the option being off, and the image being distorted with some of the generated modes at https://gitlab.freedesktop.org/drm/amd/-/issues. VRR not working with any generated modes is already reported at https://gitlab.freedesktop.org/drm/amd/-/issues/2185
(In reply to Zamundaaa from comment #5) > Yes. You can report the modes being generated despite the option being off, > and the image being distorted with some of the generated modes at > https://gitlab.freedesktop.org/drm/amd/-/issues. > VRR not working with any generated modes is already reported at > https://gitlab.freedesktop.org/drm/amd/-/issues/2185 Thanks for your help. There may still be one thing KDE could improve in the meantime: listing all refresh rate modes even the Hz value is equal. That way instead of only the fake 120 Hz appearing in Display Configuration, there are two 120 Hz options (one fake, one real).
(In reply to wokim from comment #6) > (In reply to Zamundaaa from comment #5) > > Yes. You can report the modes being generated despite the option being off, > > and the image being distorted with some of the generated modes at > > https://gitlab.freedesktop.org/drm/amd/-/issues. > > VRR not working with any generated modes is already reported at > > https://gitlab.freedesktop.org/drm/amd/-/issues/2185 > > Thanks for your help. There may still be one thing KDE could improve in the > meantime: listing all refresh rate modes even the Hz value is equal. That > way instead of only the fake 120 Hz appearing in Display Configuration, > there are two 120 Hz options (one fake, one real). I also tried Gnome, and they list every refresh rate (all real and all fake refresh rates). And because they use decimals (e.g. 120.00 Hz and 119.94 Hz) I can distinguish between real and fake refresh rates. So it seems very useful to me if KDE (Display Configuration and kscreen-doctor) would also list all refresh rates (and not try hide duplicates) and also show decimals.
(In reply to wokim from comment #7) > I also tried Gnome, and they list every refresh rate (all real and all fake > refresh rates). And because they use decimals (e.g. 120.00 Hz and 119.94 Hz) > I can distinguish between real and fake refresh rates. So it seems very > useful to me if KDE (Display Configuration and kscreen-doctor) would also > list all refresh rates (and not try hide duplicates) and also show decimals. Another problem is that even if I select the real 120 Hz through kscreen-doctor, it'll default/revert back to the fake 120 Hz after a reboot or after restarting KDE.
(In reply to Zamundaaa from comment #3) > There's no flag that says they're generated, they're all "driver". So I'm > afraid we can't even mark them as generated in kscreen-doctor, and the > driver just has to make sure the modes it advertises actually work (In reply to Zamundaaa from comment #5) > Yes. You can report the modes being generated despite the option being off, > and the image being distorted with some of the generated modes at > https://gitlab.freedesktop.org/drm/amd/-/issues. > VRR not working with any generated modes is already reported at > https://gitlab.freedesktop.org/drm/amd/-/issues/2185 See this bug report for more information on what may be necessary for KDE to recognize these fake refresh rates: https://gitlab.freedesktop.org/drm/amd/-/issues/2985
(In reply to wokim from comment #8) > Another problem is that even if I select the real 120 Hz through > kscreen-doctor, it'll default/revert back to the fake 120 Hz after a reboot > or after restarting KDE. I've found a workaround for this: editing the monitors EDID with Custom Resolution Utility (through wine) and marking the 120 Hz refresh rate mode as "Preferred" in its "Detailed resolutions" data block (in its DisplayID 1.3 extension block). Then exporting the edited EDID and copying it to "/usr/lib/firmware/edid/my_edid.bin" and loading it on boot by adding to my kernel boot line "drm.edid_firmware=edid/my_edid.bin". Now KDE thinks the real 120 Hz is the only one that matters and the fake 120 Hz gets removed as a duplicate (instead of the other way around).
(In reply to Zamundaaa from comment #5) > Yes. You can report the modes being generated despite the option being off, > and the image being distorted with some of the generated modes at > https://gitlab.freedesktop.org/drm/amd/-/issues. > VRR not working with any generated modes is already reported at > https://gitlab.freedesktop.org/drm/amd/-/issues/2185 Marking as resolved-upstream. (In reply to wokim from comment #7) > I also tried Gnome, and they list every refresh rate (all real and all fake > refresh rates). And because they use decimals (e.g. 120.00 Hz and 119.94 Hz) > I can distinguish between real and fake refresh rates. So it seems very > useful to me if KDE (Display Configuration and kscreen-doctor) would also > list all refresh rates (and not try hide duplicates) and also show decimals. I believe this is being tracked in https://bugs.kde.org/show_bug.cgi?id=431057
(In reply to fanzhuyifan from comment #11) > (In reply to Zamundaaa from comment #5) > > Yes. You can report the modes being generated despite the option being off, > > and the image being distorted with some of the generated modes at > > https://gitlab.freedesktop.org/drm/amd/-/issues. > > VRR not working with any generated modes is already reported at > > https://gitlab.freedesktop.org/drm/amd/-/issues/2185 > > Marking as resolved-upstream. There is a more specific issue there on this: https://gitlab.freedesktop.org/drm/amd/-/issues/2985. But the bugs here are also multiple KDE bugs and not just an AMD bug, so it shouldn't be marked as resolved-upstream. > (In reply to wokim from comment #7) > > I also tried Gnome, and they list every refresh rate (all real and all fake > > refresh rates). And because they use decimals (e.g. 120.00 Hz and 119.94 Hz) > > I can distinguish between real and fake refresh rates. So it seems very > > useful to me if KDE (Display Configuration and kscreen-doctor) would also > > list all refresh rates (and not try hide duplicates) and also show decimals. > > I believe this is being tracked in > https://bugs.kde.org/show_bug.cgi?id=431057 The refresh rates being improperly stored (bug 431057) isn't the only bug here. The other bugs here are: (1) Display Configuration hides refresh rates which are visible in kscreen-doctor, and (2) when you apply e.g. the real 120 Hz with kscreen-doctor it gets set back to the fake 120 Hz after a reboot.
(In reply to wokim from comment #12) > But the bugs here are also multiple KDE bugs and not just an AMD bug, so it > shouldn't be marked as resolved-upstream. > > The refresh rates being improperly stored (bug 431057) isn't the only bug > here. The other bugs here are: (1) Display Configuration hides refresh rates > which are visible in kscreen-doctor, and (2) when you apply e.g. the real > 120 Hz with kscreen-doctor it gets set back to the fake 120 Hz after a > reboot. Thanks for the bug report! Unfortunately it reports multiple distinct issues, which will make it not actionable. See https://community.kde.org/Get_Involved/Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket for more explanation. Can I ask you to submit a new bug report for each specific issue? Thanks again! > The refresh rates being improperly stored (bug 431057) isn't the only bug > here. The other bugs here are: (1) Display Configuration hides refresh rates > which are visible in kscreen-doctor, and (2) when you apply e.g. the real > 120 Hz with kscreen-doctor it gets set back to the fake 120 Hz after a > reboot. Could you open a separate bug report for (1)? IMO (2) seems like a duplicate of BUG 431057, (e.g., see https://bugs.kde.org/show_bug.cgi?id=431057#c8) Are there other issues here not covered by the upstream report, and (1) and (2) here?