Bug 489952

Can you share more information of your system? System settings -> About this system -> click on "copy details" and paste it here. Thanks!

Unfortunately I am unable to reproduce this, or I just don't notice it. 

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.80
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600

(In reply to Akseli Lahtinen from comment #1)
> Can you share more information of your system? System settings -> About this
> system -> click on "copy details" and paste it here. Thanks!
> 
> Unfortunately I am unable to reproduce this, or I just don't notice it. 

Hi Akseli, thanks for looking at this! 

It's not the sort of thing everyone would notice. Very subjective, and it's quite hard to see, too, I mostly felt it. A good monitor with a fast response time or strobing or the like, might visually (but not tangibly, if one is sensitive to latency variation) hide it entirely. It was only when moving across my black desktop at 120Hz that I realised what I was feeling. Over an app's UI/content, it's hard to see.

Perhaps this is why I hadn't noticed, but I am seeing this in other apps. As mentioned, I didn't see it over a firefox window, but when I tested other apps just now, I could see it there, too. I guess that means this bug may need to be reassigned? My apologies. 

For an example of this, the "About this System" app, if I have it open above an otherwise empty desktop, it will do it, but if I maximize firefox behind it, then maximize it above firefox, then it doesn't do it - so it seems not even app-specific, but more than that. Seems like maybe kwin?

Here's that info:

Operating System: openSUSE Tumbleweed 20240711
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-1-default (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2
Manufacturer: ASUS

(In reply to pallaswept from comment #2)
> It's not the sort of thing everyone would notice. Very subjective

I just noticed this very poorly worded description. My apologies for any confusion I may have caused. To clarify what I meant: The ability to notice it, is subjective - As in, some people can, some people can't, maybe some monitors will show it more or less, etc... But the behaviour itself, is objectively, measurably broken. In layman's terms, it's 'dropping frames'.

Thanks for correctly re-assigning this for me Nate!

What NVidia driver version are you on? Do you still see this if you set the kernel boot argument
> nvidia.NVreg_EnableGpuFirmware=0
?

(In reply to Zamundaaa from comment #4)
> What NVidia driver version are you on? 

550.100

> Do you still see this if you set the kernel boot argument
> nvidia.NVreg_EnableGpuFirmware=0

I do.

Thanks again for checking this one out.

Hi Zamundaaa,

I hope you might be so kind as to lend me some advice. I hope this is not too far off-topic, although I would use this to troubleshoot this issue.

I haven't done anything like this on linux yet. On Windows, I might look into this with a tool called GPUView. It is maintained by MS now but this page from the author explains it better than I can: https://graphics.stanford.edu/~mdfisher/GPUView.html

Is there a tool (or suite of tools) like that for KDE or linux in general? Or what I really want to ask is, is there one that you personally recommend?

gpuvis: https://github.com/mikesart/gpuvis

we have some docs at: https://invent.kde.org/plasma/kwin/-/wikis/Using-FTrace-Markers
but it's still quite overwhelming .

(In reply to David Edmundson from comment #7)
> gpuvis: https://github.com/mikesart/gpuvis

Cheers! I had seen this one, but wasn't sure it applied to either KDE or the nvidia card. 

Do you know any magic for tracing nvidia events? I gather it's not possible, but thought I should ask.

> but it's still quite overwhelming .

You're not wrong about that :) I'll try to get something useful soon. 

At a first glance - keeping in mind I'm a noob at this on linux - I think I may see a problem. 

I can clearly see by the plot, which monitor my mouse was on, by the drm_vblank_event_deliveredN events on the corresponding monitor's row.

I can only assume by the name, these events should be spaced according to the monitor's refresh rate; 16.67ms@60Hz/8.3ms@120Hz, for my two monitors. But what I'm seeing is that every one of these events is spaced shorter than the maximum refresh rate of the monitor - it's at 14.5ms and 6.4ms. Is it just me or is that weird?

In addition to the observation above, I just captured a trace which had the mouse moving in circles over the desktop, and then over firefox (about:blank).

When the mouse was over firefox, I see the drm_vblank_event_delivered1 events in the row for nvidia-modeset. Those are all correctly timed, at 8.3ms apart.

Then, I minimise that app, and while the mouse is over the desktop, the blank events appear in the DP-1 row. These are all incorrectly timed, at ~6.4ms.

Weird?

Yeah, that's very weird.
We have an environment variable to debug performance issues in general, though I'm not sure if it'll help here, it's worth a shot: https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_log_performance_data

Just set it for KWin, and it should put some csv files with performance logging in your home directory, which we can analyze

Created attachment 172318 [details]
kwin log 60Hz display

(In reply to Zamundaaa from comment #10)
> Just set it for KWin, and it should put some csv files with performance
> logging in your home directory, which we can analyze

Attached. I collected just a few minutes usage, first with the mouse over the desktop or apps which don't 'fix' this, and at the end, I spent a good chunk of time on the 120Hz monitor with the mouse over firefox as a comparison. Let me know if I could run more specific tests. I thought maybe I could collect traces simultaneously to illustrate the difference.

I honestly can't tell one from the other, in these logs. Kwin runs like a clock (literally never drops so much as a nanosecond, wow, nice work).

Created attachment 172319 [details]
kwin log 120Hz display

Okay, there's 58 frames dropped because of late atomic commits in the log of the 60Hz monitor (vs. only 10 on the 120Hz one), which would also affect the cursor. I think the fix for bug 490358 should help here too.

(In reply to Zamundaaa from comment #13)
> Okay, there's 58 frames dropped because of late atomic commits in the log of
> the 60Hz monitor (vs. only 10 on the 120Hz one), which would also affect the
> cursor. I think the fix for bug 490358 should help here too.

Hmm, I'm not so sure that's the same issue I'm seeing - In this timeframe on the 120Hz monitor I would have had in the region of hundreds of frames where it should have drawn the cursor but didn't. If I draw a circle on my desktop I see several, maybe 10 breaks in that single circle of cursors, and in these logs I draw many dozens of circles. 

That bug is also reported as being worse under CPU load, whereas mine is not. There's no effect by any CPU load I've been able to generate with stress-ng or everyday apps, and I have no gradient of good-to-bad effect with mine, there's no better/worse, it's either doing it, or it isn't. The only thing that seems to have any effect is what the cursor is being drawn above.
I also wonder about this, on my 5900X+3090 system, this rig is getting old but it's still pretty fast. I haven't read into your patch, but f you had to slow down kwin for this system, I'd say there might be something else wrong.

I attempted to better capture the two behaviours in my logs. Attached are four files - one for each monitor, and one for each of two scenarios. The first scenario, I reboot, open the launcher, draw 20 circles on the desktop on the 60Hz hdmi monitor, then 20 circles on the 120Hz DP monitor. The second scenario is the same, but I open firefox before drawing the circles, and maximise it to the display I'm drawing on, so I'm drawing circles over firefox rather than over the desktop.

The immediately most interesting thing about this is that yes, that's a 0 byte file, for the desktop (no firefox) scenario, on the 120Hz monitor (my secondary). I'm not sure if that's a sign that this logging can't capture this fault, or if it's a hint as to why this fault is seen?

Hope this is helpful.

Created attachment 172329 [details]
desktop 60hz

Created attachment 172330 [details]
desktop 120Hz

Created attachment 172331 [details]
firefox 60Hz

Created attachment 172332 [details]
firefox 120Hz

(In reply to pallaswept from comment #14)
> only thing that seems to have any effect is what the cursor is being drawn above.

Sorry, I forgot about the 'shake cursor' effect. If I draw these test circles too fast, that kicks in, and that also makes the frame timing smooth.

I did do that briefly by accident in the first test (desktop 60Hz) and thought that I should mention it.

(In reply to pallaswept from comment #14)
> The immediately most interesting thing about this is that yes, that's a 0
> byte file, for the desktop (no firefox) scenario, on the 120Hz monitor (my
> secondary). 

I tried to record this with spectacle today. It recorded no frames until I accidentally got too close to the screen edge, recorded a few frames where the edge highlight animated, and no others afterward. The resulting mp4 file is effectively broken as a result, you can't seek, etc. Let me know if you'd like me to attach it, perhaps a closer analysis might pull something useful from it, but visually, it's just a black rectangle with a mostly-stationary cursor on it.

These results seem related, so I thought I should mention it.

(In reply to pallaswept from comment #14)
> Hmm, I'm not so sure that's the same issue I'm seeing - In this timeframe on
> the 120Hz monitor I would have had in the region of hundreds of frames where
> it should have drawn the cursor but didn't. If I draw a circle on my desktop
> I see several, maybe 10 breaks in that single circle of cursors, and in
> these logs I draw many dozens of circles. 
It's expected that the tool won't capture all dropped cursor updates - it only records data for frames where something except the cursor has changed. So if you move the cursor in a circle and the window below it didn't update, it won't log anything in that duration.
That should get fixed with some near-ish future changes in KWin, but for now you could get a more accurate reading by leaving glxgears running on the screens while doing the testing.

> Sorry, I forgot about the 'shake cursor' effect. If I draw these test circles too fast, that kicks in, and that also makes the frame timing smooth.
That's an important piece of information... the effect forces a software cursor. If you set the environment variable KWIN_FORCE_SW_CURSOR=1 for KWin, does the issue go away permanently?

(In reply to Zamundaaa from comment #21)
> for now you could get a more accurate reading by leaving glxgears running on the screens while doing the testing.

That appears to stop this glitch, too. For testing consistency I also tried this with firefox, just resized it to smallest, and left it in the corner. Like this, the whole desktop around it, is fine.

> If you set the environment variable KWIN_FORCE_SW_CURSOR=1 for KWin, does the issue go away permanently?

Yes. 
Ooh, smoooooth :)

(In reply to pallaswept from comment #22)
> That appears to stop this glitch, too. For testing consistency I also tried
> this with firefox, just resized it to smallest, and left it in the corner.
> Like this, the whole desktop around it, is fine.

This conflicted with my original report, and it bothered me, so I tested more.

Background: part of my firefox theme is a CSS transition with a 12 second duration. It sits there doing nothing for 10s, then animates for 2s. This 'timer' begins when my mouse leaves the ff window.

When I position the ff window on the desktop, resize it to smallest and put it in the corner, move my mouse back-and-forth over the desktop around it... The mouse animation is smooth - as per my reply from today.

But only for those 12 seconds. After the CSS animation (10s no visual change at all, but it is "animating"+2s visually changes) is complete, the mouse begins to stutter again - as per my original report.

So, that's the reason for the conflicting reports. It depends not only on the app being on the same display, but also it actually drawing stuff (even if that 'stuff' is nothing, apparently).

Hopefully this distinction is useful.

Can you still reproduce this issue in Plasma 6.3? There have been some potentially related fixes since 6.1

(In reply to Zamundaaa from comment #24)
> Can you still reproduce this issue in Plasma 6.3?

I'm afraid so. Thanks for checking. I saw a few of your timing changes, some I even got excited enough to cherry pick and package them for myself... No luck, yet.

I also see this issue on my machine running KDE 6.4.2 on Wayland on CachyOS. Observed it both on 6800XT and 9070. Below are the details of my machine.

Operating System: CachyOS Linux 
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.4-4-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 64 GiB of RAM (62.7 GiB usable)
Graphics Processor: AMD Radeon RX 9070
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X570 AORUS PRO WIFI
System Version: -CF

Maybe setting `KWIN_DRM_OVERRIDE_SAFETY_MARGIN` environment variable to a lower value might help especially on a high refresh rate monitor. It's set to 1500 by default.

(In reply to thesword from comment #27)
> Maybe setting `KWIN_DRM_OVERRIDE_SAFETY_MARGIN` environment variable to a
> lower value might help especially on a high refresh rate monitor. It's set
> to 1500 by default.

I'm seeing an increasing number of people noticing this bug lately (lots of mentions on reddit/forums/discord/etc), resulting in a lot of random guesses from random people, some of them with damaging consequences. I saw a guy's root partition need rebuilding after trying the NO_AMS variable on an nvidia card crashed his machine.

Playing with a setting called 'override safety margin' is obviously inherently unsafe, so I would like to know more about this before I change it, since I'm definitely gonna be all alone trying to fix it if something goes wrong and I can't get online. 

What is this safety margin? What is the effect of decreasing it?

The source says:
    // the 1.5ms on top of that was chosen experimentally, for the time it takes to commit + scheduling inaccuracies 

Which implies that, in order to commit earlier and not run late, this number should *larger*, but you said to set it smaller?

Also, the documentation for this variable says:
    The issue usually manifests in only getting half the refresh rate of what you set the screen to.

But that doesn't quite match our symptoms so doesn't fill me with confidence that I'm even trying the right thing.

You're the kwin dev not me, so obviously I'm missing something here, but I'd just like to know what I'm doing before I do it, would you mind filling in some of the blanks for me?

Just adding my own observations as I am also experiencing this bug. The bug seems to be related to the use of hardware cursor. The NVIDIA proprietary drivers use hardware cursor, but Nouveau does not, as far as I can tell. How do I know? I don't, but the cursor under Nouveau—though it never drops frames—feels a bit more latent at low refresh rates compared to the proprietary NVIDIA driver. I know "feel" isn't a reliable metric, but I swear by it in this case. Hardware cursor is preferred vs. software as it is lower latency and more immediately correspondent to the movement of the mouse.

Under kwin, I have also been able to determine that no cursor frames are dropped when dragging a window, though this is a bit harder to see with the naked eye vs. moving the cursor over a stationary background.

My system:
* OS: Fedora Linux Plasma Desktop Edition 42 (Plasma Desktop 6.4.4, KDE Frameworks 6.17.0, Qt 6.9.1)
* Linux Kernel: 6.15.9-201.fc42.x86_64 (64-bit)
* Video: EVGA NVIDIA GeForce RTX 2080 SUPER w/ 8GB RAM
* NVIDIA video driver: 575.64.05

I should also mention that these tests are most reliably performed using a high polling rate wired mouse, as many cheaper and especially bluetooth mice will exhibit frame issues of their own.

(In reply to S. Christian Collins from comment #30)
> I should also mention that these tests are most reliably performed using a
> high polling rate wired mouse, as many cheaper and especially bluetooth mice
> will exhibit frame issues of their own.

Testing this bug was the thing that made me realise that an 8K mouse doesn't seem to make any difference on KDE ;) 

You may like to check out the conversation above if you want to get into the weeds on testing this: https://bugs.kde.org/show_bug.cgi?id=489952#c9

TL;DR yes the hardware cursor plane is involved, but also, there seems to be an underlying frame timing problem.

This is definitely impacted by the nvidia driver. Newer versions of the driver have changed the behaviour on a few occasions, and a recent example is the new NVreg_RegistryDwords=RmEnableAggressiveVblank=1 parameter in the 580 drivers. It's even worse with that on.

(In reply to pallaswept from comment #28)
> I'm seeing an increasing number of people noticing this bug lately (lots of
> mentions on reddit/forums/discord/etc), resulting in a lot of random guesses
> from random people, some of them with damaging consequences. I saw a guy's
> root partition need rebuilding after trying the NO_AMS variable on an nvidia
> card crashed his machine.
Nothing needed rebuilding... Afaik NVidia doesn't support legacy modesetting properly, so they would've needed to unset this variable from a tty.
If you don't know how to do that, then indeed please do not mess with anything.

> What is this safety margin? What is the effect of decreasing it?
> 
> The source says:
>     // the 1.5ms on top of that was chosen experimentally, for the time it
> takes to commit + scheduling inaccuracies 
> 
> Which implies that, in order to commit earlier and not run late, this number
> should *larger*, but you said to set it smaller?
It changes how long before a given refresh cycle KWin needs to commit the next frame. And you should indeed increase it, reducing it won't help. Try values up to like 5000µs, more than that may cause additional stutter rather than prevent it.

It seems that everyone affected is on NVidia. Do I assume correctly that all of you are using the proprietary driver (rather than the open kernel modules or Nouveau)?
If so, the proprietary NVidia driver doesn't provide pageflip timestamps, so regular frame drops are to be expected. Increasing the safety margin *might* help work around the issue, but ultimately it's impossible to do things right without reliable timing information.
If your hardware is supported, try the open kernel modules, they should be providing proper timestamps.

(In reply to Zamundaaa from comment #32)
> Nothing needed rebuilding...

The machine froze and the forced shutdown caused disk corruption :( We got it back no problem :)
Totally pilot error, not a KDE problem, but I was just trying to demonstrate that tinkering with settings might not be a good idea if we don't understand what they're doing. so:
 
> > What is this safety margin? What is the effect of decreasing it?
> It changes how long before a given refresh cycle KWin needs to commit the
> next frame. And you should indeed increase it, reducing it won't help. Try
> values up to like 5000µs, more than that may cause additional stutter rather
> than prevent it.

Thanks for clarifying! :)
No luck with that one I'm afraid, it was worth a shot!

> It seems that everyone affected is on NVidia. Do I assume correctly that all
> of you are using the proprietary driver (rather than the open kernel modules
> or Nouveau)?

I tried the closed module, and also tried it with the firmware disabled, but it didn't have any bearing on this. I'm on the open module aside from that testing but I can switch if you want some testing done.

I expect to get a little free time over the weekend and I'm very curious to see how those timing plots look with this new vblank parameter because it's visibly very different. Maybe it'll give us a hint.

(In reply to Zamundaaa from comment #32)

> It seems that everyone affected is on NVidia. Do I assume correctly that all
> of you are using the proprietary driver (rather than the open kernel modules
> or Nouveau)?

I am using Fedora, which installs the NVIDIA open kernel module as default from RPM Fusion. When I switch to Nouveau, this cursor bug does not happen. However, I'm not sure if Nouveau is using hardware cursor, as it feels slightly latent compared to the NVIDIA driver.

As others have found, I also see that cursor movement is perfectly smooth over the Firefox web browser and when dragging a window (neither the cursor nor the dragged window appear to be dropping any frames).

Interestingly, the cursor movement in GIMP (Flatpak) is perfectly smooth if the cursor is *not* the default pointer. So, if you have a tool selected (rectangle select, etc.), the corresponding custom cursor when moved over the editing area is perfectly smooth with no dropped frames. When you leave the editing area and the cursor returns to the default pointer, it drops frames again. This isn't true for every app with custom cursors, however. In REAPER, all of the custom cursors still drop frames when moved.

Created attachment 184082 [details]
image illustrating uneven cursor trail

I have experimented with setting the KWIN_DRM_OVERRIDE_SAFETY_MARGIN environment variable between 2000 and 5000, and here is what I've found on my 144 Hz display:
* 2000: maybe slightly better
* 3000: improved timing, but not yet perfect
* 4000: still not perfect
* 5000: almost perfect, but still some frames out of place

With KWIN_DRM_OVERRIDE_SAFETY_MARGIN=5000, I was able to get a better glimpse at what is actually happening. It's not that cursor frames are being dropped, but rather the mouse movement is occasionally being "snapshotted" too early or too late. The attached image illustrates what I am seeing when moving the cursor horizontally for 8 frames. In this example, all 8 frames are present, but not all of them are spaced equidistantly as they should be.

Lastly, I have discovered another scenario where the cursor moves perfectly smoothly:
1. Right click on a program in the task manager (I am using the Icons-and-Text Task Manager, if that matters).
2. Move the cursor within the region of the menu that pops up.

Result: the cursor movement is perfectly smooth.

Following up on my previous comment, it appears at the default safety margin of 1500 that cursor frames are being dropped, but at 5000 that some frames are out of place. Perhaps it's just two different symptoms of the same problem, and I have to admit I don't really understand the mechanisms at play here.

Anyway, on my secondary monitor (75 Hz refresh), setting the safety margin to 5000 doesn't really make things seem or feel better, just different. At 1500 safety margin, it seems to be a combination of equidistantly-spaced frames with gaps, whereas at 5000 safety margin, the frame spacing seems to be all over the place, which almost feels worse.

Either way, increasing the safety margin up to 5000 doesn't solve the problem, but might improve it depending on your monitor's refresh rate.

Tracing this was really interesting this time. I found a perfect demo. 

Moving the mouse over the desktop 'drops frames' (quotes because I have no idea what to really call this)
Moving the mouse over konsole is the same
Moving the mouse over firefox the mouse looks normal

As discussed above, my firefox profile animates the browser for a few seconds, which keeps the cursor happy. So I made konsole transparent, so I could do the traces with firefox in the background still rendered through the konsole window. 

I started the trace, alt-tabbed to firefox to kick off the animation timers, alt-tabbed back to konsole so firefox would time out, do it's animation, and then stop. Meanwhile I just moved the mouse in figure-8s over konsole. After the timers end, the animation runs, they end and the cursor goes bad, I let it run a couple seconds and stop the trace.

This way there's a clean 'cut' between 'working, because firefox is doing stuff' to 'busted because firefox stopped doing stuff', but nothing else has changed, there was no switching active app or anything like that, just me, movin the mouse in 8's over the same window.

Attached is an image of that moment in GPUview. I have filtered for the vblank events. This is a 60Hz HDMI TV, so they should be 16.667ms apart. 
While firefox is animating, this is the case. 

The moment that firefox stops animating and goes idle, the cursor goes bad, and the vblank events are now 14.4ms apart and growing. Occasionally, the vblank events are handled differently (by nvidia-modeset, as it was when firefox was animating, rather than this thread named after the device (what is that?))  and those arrive on time (even rounding for the error of the previous frame) . I see about 6 per second here, which seems about right? for how many 'dropped frames' we see in the cursor.

Once one of those events is correctly spaced at ~16.66ms, nvidia-modeset stops handling the vblanks again and it switches back to the monitor-thread-thing, drifts a while, until nvidia-modeset tries again.

zamundaaa, does this mean anything to you? It seems to me as though there are two processes which can handle those vblank events and one of them has this timing problem and occasionally the modeset driver kicks in to try and correct it? I've see late vblank events a bunch but this is... different :D

Created attachment 184179 [details]
GPUVis trace at the moment the issue occurs