https://bugs.kde.org/show_bug.cgi?id=477016
--- Comment #26 from Zamundaaa <xaver.h...@gmail.com> --- (In reply to AdamKafei from comment #24) > I'm experiencing a similar phenomenon when I have VRR set to "Always" and it > defaults to 48hz instead of the set desktop refresh rate of 120hz and when > short animations play (such as steam animated avatars), the refresh rate > cycles through the range repeatedly rather than just setting to 120hz Yes, that's what adaptive sync does, it matches the refresh rate of content on the screen. If there's no movement on the screen, it goes to the minimum refresh rate. > It would be very nice if the "Always" VRR refresh rate would set to the > desktop refresh rate and only 'unlock' when "Automatic" VRR would enable. I would like to do that, but it's a bit more challenging than it seems. We don't actually set any refresh rate with VRR, we just push frames to the kernel, and it makes the screen follow the rate of those frames. If we start constantly pushing frames to keep the screen at full refresh rate, the kernel will also keep the GPU fully enabled, wasting lots of power. Maybe we could start doing it on external displays only, because it shouldn't be much of a problem on desktop PCs... but we really need actual driver APIs for doing this stuff properly. (In reply to Tim from comment #25) > When Adaptive sync is set to always, refresh drops to 48hz and stays there > until the mouse cursor is moved. When the mouse cursor is moved, it ramps up > to 240hz. This will sometimes black screen my OLED monitor after a bit. When > it is set to automatic, watching full screen video like Youtube, causes the > refresh to change erratically from 48-240hz and sometimes this will black > screen my OLED monitor. This makes VRR unusable in the state that it is in. That's unrelated to this, and a driver bug, which you can report at https://forums.developer.nvidia.com/c/gpu-graphics/linux -- You are receiving this mail because: You are watching all bug changes.
