Comme=
nt # 15
on bug 10891=
7
from tempel.j=
ulian@gmail.com
To clarify: There is no connection to any compositor. You can =
also reproduce
the issue with any desktop environment where you can disable the compositor.
Instead of using a compositor then, simply enable TearFree and run "re=
dshift -t
4500:4500 -l 1:1".
-> It still makes everything stutter. And not just with cursor input, it
affects the whole screen content without further doing. Just look at your
browser window content of www.vsnctester.com, scroll on any webpage or play=
a
video: The stutter should always be noticeable.
The commit "drm/amd/display: Allow cursor async updates for framebuffe=
r swaps"
has not changed the situation.
I can't explain why this issue was less distinct with some 5.1 kernel versi=
ons.
Anyway: It's back to "really stuttery" since 5.2.
---
Is this perhaps because userspace uses legacy gamma adjustment instead of n=
ew
atomic infrastructure? In that case, it would seem unrealistic to expect it=
to
adopt to the new infrastructure if not even Gnome Nightlight on Wayland uses
it. So a performance fix for legacy gamma adjustments would be highly welco=
me
(if my assumptions apply ;) ).
I also wonder why there has to be stutter at all. Only the initial setting =
of
new gamma adjustments cause the stutter. When you run redshift in "one=
shot"
mode via "redshift -O 4500", there is no more stutter once the in=
itial
adjustment is done and the gamma stays adjusted.
Perhaps it would help to make the kernel delay the adjustments until they c=
an
happen without causing performance issues with vsync + pageflipping?