SUMMARY Hi, I posted this on [https://discuss.kde.org](https://discuss.kde.org) but didn’t get any response, and I’m also not exactly sure which component this falls under so I posted it under “performance", feel free to move it to the most appropriate category. I have the following issue with my Samsung G80SD monitor (4K@240 Hz) on my NixOS installation with KDE Plasma 6.3.5: I was previously using GNOME and the 240 Hz refresh rate worked correctly, as it also did when I switched my DE to KDE Plasma through the NixOS configuration file. However, after some system rebuilds, the 240 Hz refresh started to feel like plain locked 60 Hz across the entire system (even though my monitor reports it’s running at 240 Hz, as well as the Nvidia X Server app and even the KWin FPS tool under Desktop Effects). This happens regardless of the VRR setting (disabled, enabled, or automatic), and I can easily verify it on Blur Busters—those 240 Hz look exactly like 60 Hz. On the other hand, 120 Hz works correctly (apart from some animation inconsistencies here and there), as do 60 Hz and 30 Hz. I initially thought it might be related to \this bug[https://bugs.kde.org/show_bug.cgi?id=485927], but someone mentioned that it’s probably not, and that I should create a new bug report, so here I am. Thanks in advance. STEPS TO REPRODUCE 1. Change the refresh rate to 240 Hz under screen settings OBSERVED RESULT Everything feels and behaves like a fixed 60 Hz refresh rate, easily verifiable on Blur Busters and with anything being rendered on screen (even the mouse pointer), despite everything indicating that the display mode is set to 240 Hz (including my monitor’s own OSD and even the KWin FPS tool). EXPECTED RESULT Everything should feel smooth and run at 240 Hz, which is not the case (choosing 240 Hz and 60 Hz feels identical — I have to set it to 120 Hz to get a high refresh rate, but that doesn’t take full advantage of my monitor’s capabilities). SOFTWARE/OS VERSIONS Distro: NixOS Linux kernel: 6.14.6 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION 1) The problem seems to occur both in Wayland and X11 sessions, although I only use Wayland now. 2) In the beginning (when I switched from GNOME to Plasma using the NixOS config file), it works at 240 Hz with no major problems, but after some package installation/system rebuilds, this locked 60 Hz-like situation appears. 3) 120 Hz, 60 Hz and 30 Hz refresh options works properly. 4) I have a powerful PC rig with a RTX 4090 and the latest 570 drivers, 240 Hz works fine on Windows 11, it's not a low-spec hardware related problem.
Please set KWIN_LOG_PERFORMANCE_DATA=1 for KWin, restart, then use the system for a minute or so at 240Hz, and upload the csv file KWin puts in your home folder here.
Created attachment 181538 [details] 240 Hz performance log Here is the performance log.
Ok, so my analysis tool says 8.5% of frames are dropped, which is not great, but also not bad enough to cause this. The actual render times have a bunch of spikes, one even going up above 100ms - but apart from that, the data looks fine. Those spikes aside, the time between presentation timestamps is 4.16ms, which is exactly right for 240Hz. If you run weston-presentation-shm, does the p2p number match? Should be somewhere around 4166 too.
(In reply to Zamundaaa from comment #3) > Ok, so my analysis tool says 8.5% of frames are dropped, which is not great, > but also not bad enough to cause this. > > The actual render times have a bunch of spikes, one even going up above > 100ms - but apart from that, the data looks fine. Those spikes aside, the > time between presentation timestamps is 4.16ms, which is exactly right for > 240Hz. > > If you run weston-presentation-shm, does the p2p number match? Should be > somewhere around 4166 too. It is around 4166 (for the most part): 359: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4105 us, t2p 7853, [sce_], seq 0 360: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4168 us, t2p 7696, [sce_], seq 0 361: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4166 us, t2p 7916, [sce_], seq 0 362: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4167 us, t2p 7910, [sce_], seq 0 363: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4171 us, t2p 7904, [sce_], seq 0 364: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4170 us, t2p 7910, [sce_], seq 0 365: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4166 us, t2p 7868, [sce_], seq 0 366: f2c 1 ms, c2p 12 ms, f2p 13 ms, p2p 8392 us, t2p 11992, [sce_], seq 0 367: f2c 2 ms, c2p 10 ms, f2p 12 ms, p2p 4133 us, t2p 10559, [sce_], seq 0 368: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4172 us, t2p 7873, [sce_], seq 0 369: f2c 0 ms, c2p 10 ms, f2p 10 ms, p2p 5484 us, t2p 9255, [sce_], seq 0 370: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 2874 us, t2p 7990, [sce_], seq 0 371: f2c 0 ms, c2p 7 ms, f2p 7 ms, p2p 4152 us, t2p 6668, [sce_], seq 0 372: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4158 us, t2p 7884, [sce_], seq 0 373: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4181 us, t2p 7949, [sce_], seq 0 374: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4152 us, t2p 7911, [sce_], seq 0 375: f2c 1 ms, c2p 12 ms, f2p 13 ms, p2p 8357 us, t2p 12020, [sce_], seq 0 376: f2c 1 ms, c2p 16 ms, f2p 17 ms, p2p 8324 us, t2p 16124, [sce_], seq 0 377: f2c 1 ms, c2p 11 ms, f2p 12 ms, p2p 4163 us, t2p 10620, [sce_], seq 0 378: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4162 us, t2p 7942, [sce_], seq 0 379: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4177 us, t2p 7956, [sce_], seq 0 380: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4121 us, t2p 7918, [sce_], seq 0 381: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4166 us, t2p 7842, [sce_], seq 0 382: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4167 us, t2p 7919, [sce_], seq 0 383: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4166 us, t2p 7894, [sce_], seq 0 384: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4176 us, t2p 7929, [sce_], seq 0 385: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4157 us, t2p 7891, [sce_], seq 0 386: f2c 1 ms, c2p 12 ms, f2p 13 ms, p2p 8374 us, t2p 11985, [sce_], seq 0 387: f2c 2 ms, c2p 11 ms, f2p 13 ms, p2p 4160 us, t2p 10712, [sce_], seq 0 388: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4171 us, t2p 7871, [sce_], seq 0 389: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4164 us, t2p 7958, [sce_], seq 0 390: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4167 us, t2p 7977, [sce_], seq 0 391: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4166 us, t2p 7978, [sce_], seq 0 392: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4169 us, t2p 7940, [sce_], seq 0 393: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4172 us, t2p 7979, [sce_], seq 0 394: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4161 us, t2p 7971, [sce_], seq 0 395: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4169 us, t2p 7977, [sce_], seq 0 396: f2c 0 ms, c2p 13 ms, f2p 13 ms, p2p 8353 us, t2p 12168, [sce_], seq 0 397: f2c 1 ms, c2p 16 ms, f2p 17 ms, p2p 8306 us, t2p 16072, [sce_], seq 0 398: f2c 2 ms, c2p 10 ms, f2p 12 ms, p2p 4168 us, t2p 10538, [sce_], seq 0 399: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4169 us, t2p 7884, [sce_], seq 0 400: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 5118 us, t2p 8844, [sce_], seq 0 401: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 3235 us, t2p 8015, [sce_], seq 0 402: f2c 1 ms, c2p 7 ms, f2p 8 ms, p2p 4142 us, t2p 6932, [sce_], seq 0 403: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4182 us, t2p 7899, [sce_], seq 0 404: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4164 us, t2p 7931, [sce_], seq 0 405: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4161 us, t2p 7836, [sce_], seq 0 406: f2c 1 ms, c2p 7 ms, f2p 8 ms, p2p 4168 us, t2p 7856, [sce_], seq 0 407: f2c 1 ms, c2p 12 ms, f2p 13 ms, p2p 8336 us, t2p 12079, [sce_], seq 0 408: f2c 2 ms, c2p 11 ms, f2p 13 ms, p2p 4165 us, t2p 10684, [sce_], seq 0 409: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4172 us, t2p 7979, [sce_], seq 0 410: f2c 0 ms, c2p 8 ms, f2p 8 ms, p2p 4167 us, t2p 8019, [sce_], seq 0 411: f2c 1 ms, c2p 7 ms, f2p 8 ms, p2p 4207 us, t2p 7940, [sce_], seq 0 412: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4159 us, t2p 7902, [sce_], seq 0 413: f2c 1 ms, c2p 8 ms, f2p 9 ms, p2p 4133 us, t2p 7799, [sce_], seq 0
Then the display is definitely getting updated at 240Hz... Are you certain that there's no difference to 60Hz there? If so, then the only way I can imagine that happening is if the driver just skips 3/4 of frames somehow
(In reply to Zamundaaa from comment #5) > Then the display is definitely getting updated at 240Hz... Are you certain > that there's no difference to 60Hz there? If so, then the only way I can > imagine that happening is if the driver just skips 3/4 of frames somehow Thank you very much for your help and guidance in ruling out potential issues. It is indeed a problem related to the HDMI 2.1 protocol on Linux (and Nvidia in this case) when using refresh rates higher than 120 Hz — as has also happened to another person here with the same monitor I have but in a different desktop environment: https://forums.developer.nvidia.com/t/displayport-dsc-4k-240hz-flickering-artifacts/294490/18 Unfortunately, when switching to a DP cable, the 240 Hz issue is resolved and it works correctly, but flickering artifacts are introduced (possibly due to cable quality, DSC implementation, or something else), though this is no longer a KDE Plasma-related issue. Again, I really appreciate your patience!
Okay, thanks for the follow-up. Let's close this as a driver bug then.