| Summary: | Changing the "Adaptive Sync" option to "Always" drastically lowers the monitor frequency | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Manuel <mngonzu> |
| Component: | performance | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aierizerdaniel, drywall.scarabs.0b, fusionz916, kde, nate, pallaswept, sighunter, xaver.hugl |
| Priority: | NOR | ||
| Version: | 6.0.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | OSD comparison | ||
The cursor refresh rate is intentionally dropped to the content, to prevent the content stuttering... but it should only happen while something is updating fast enough for that to matter. Can confirm the issue. Same issue; also when playing with adaptive always on or automatic will black out the screen when switching to desktop even if the game was set to full screen window , if you have any application or game that does this could you test this out This issue seems very widespread. I'm suffering it myself so I notice the multiple posts on reddit per day about it. But I also noticed the issue is misunderstood as a VRR-related one, and that 'auto' VRR resolves it. It does not.
The issue is not only that the cursor drops to minimum FPS with VRR enabled - even with adaptive sync set to "auto", even with it disabled, we can see the cursor being faulty. If you need it, I'll get a photograph, since a screenshot won't catch it, but if you want to see this, just take your mouse, and drag it in a line across your display.
What you should see, courtesy of pixel response times leaving behind ghosts of the previous frames, is a line of cursors, evenly spaced, like so:
x x x x x x x x x x x x x x x x
What you will see instead, is a broken line of cursors, like so:
x x x x x x x x x x x x x x x x
If this isn't hanging around on screen long enough just move the mouse in circles. Instead of seeing a nice evenly spaced 'polygon' of pointers, you'll see them clumped together - or you'll notice the 'breaks' in the circle of cursors. For me, the pattern I can see on screen is 3 pointers, then a gap, like `x x x x x x x x x ` The most number of these 'breaks' we should ever be able to see, if the cursor movement is consistently drawn, is one - after the least recent one (in other words, at the end).
My point is, there is clearly a general problem with the drawing of the cursor, specifically the timing of it, in Plasma right now. VRR exposes it in an extreme and un-missable way because it drops the cursor FPS so low that it becomes difficult to use it as a pointing device. But the issue of timing problems with the cursor, is present, always, VRR or no.
> The cursor refresh rate is intentionally dropped to the content, to prevent the content stuttering...
I guess the problem here is that this design does not account for the cursor being the only 'content', and allow it to be displayed at the set refresh rate of the monitor.... but anyway, I'm not sure that's the root of the cursor problems we can see... at least, not by itself.
Of course, maybe these are two separate issues, one effecting VRR and one effecting everything including VRR, but since the behaviour is inseparable, I couldn't assume that without having seen the code that causes the bug.
(In reply to pallaswept from comment #3) > I couldn't assume that without having seen the code that causes the bug. Well I spent an hour or two and dug up that code and realised... that comment #1 up there is the dev who wrote it, so I guess my input is redundant at this point :D *facepalm* I gather this one is a little bit tricky due to some technical limitations (atomic modesetting forces the app to flip its planes when you update the cursor?), so thanks for the effort, zamundaaa. Has there been any indication from the kernel, when/if they might fix this so we can have VRR on the desktop, at the highest common framerate? I don't think this other issue is directly related though, so I'll file a separate bug for that. *** Bug 493657 has been marked as a duplicate of this bug. *** |
Created attachment 169839 [details] OSD comparison SUMMARY Changing the "Adaptive Sync" option to "Always" drastically lowers the monitor frequency noticeable with cursor stutters STEPS TO REPRODUCE 1. Use a freesync display 2. Set Adaptive Sync to always 3. Mouse stutters and your display frequency is low OBSERVED RESULT Your cursor will stutter, it seems to lower the monitor frequency to 48hz EXPECTED RESULT Smooth cursor like the other options(?) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (6.9.1-arch1-2) (available in About System) Nvidia 555.42.02 KDE Plasma Version: 6.0.9 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Spectacle recordings are corrupted and can't be played, using obs to record makes the issue go away, the only "proof" is that my monitor OSD show that it runs at 48hz when setting adaptive sync to on (attached )