Honestly, it might be complicated. In the last month or so Debian testing transitioned to Gnome 40. Prior to that I was running the 5.12 kernel using Gnome 3.38 with Wayland and PSR enabled and I had no issues.
I upgraded to Gnome 40 and on the same kernel the stuttering started to occur. Fortunately they subsequently moved to the 5.14 kernel and the problem went away again.
So there must be something going on in Mutter that triggers the issue.
Based on my experience and data I found, it is most likely an issue with Intel Xe support in the 5.13 kernel:
I have Ubuntu 21.10 installed on a separate machine that is all AMD and it is working perfectly fine.
I found a bug that points to this being an issue specific to the 5.13 kernel and Intel Xe. The filer appears to be using the newer kernel on an older version of Ubuntu that defaults to X11 and the user is running KDE.
But it could be a combination of things as Brett suggested. What is certain is that disabling PSR seems to be the workaround.
Echoing as others, using @Rob_H 's instructions above it does seem like disabling PSR has addressed the issue.
I’m guessing that the difference between Wayland and X11 some of us are seeing is less due to a difference in the drivers, but more in how Wayland and X11 “allow” the driver to let the display self refresh. X11 might be far more strict/demanding, and force the display to refresh more than Wayland does, so the issue is more prominent in Wayland.
At least a few minutes in for me and I’m not seeing any issues like I did at first. Thanks Rob! Now just to see if I have any more fun stuff to deal with
I did find in my own setup that picom seems to refresh regions of the screen that are updated even if the updated window is covered by other opaque windows. I had a widget that was refreshing at a ridiculous rate, so even when it was covered I wasn’t getting into PSR (i.e. I was never getting to pc9 or pc10 in powertop) unless I killed picom. Then I found picom’s --monitor-repaint option and was able to see that widget constantly repainting.
I have no idea about Gnome, but maybe in X11 its compositor is doing something similar, preventing PSR from activating.
Can you confirm that the PSR fix addresses this issue. Everything seems to be running well except the fingerprint reader.
Sorry, just checking if this is a typo or something. Did you mean “Can confirm that the PSR fix addresses the issue.” Or “Can you confirm that the PSR fix addresses this issue?” It reads like the former, but not certain.
If the latter, I’ve now been using 21.10 since Friday afternoon with the PSR disabled fix and it’s been good for me.
Upgrading to Kernel 5.14 corrected the issue without the need to disable PSR which lead to power management issues in 5.13. Haven’t completely vetted the Kernel yet since I just YOLO’d it and went straight to 5.14.13, I may have opened the door to other issues but more to follow.
Best to run some tests with Bluetooth after a warm reboot. There’s a number of threads about Bluetooth issues with the AX210 on anything other than the 21.04 5.10 kernel or the 5.12 series (neither of which contain the PSR fix).
@Nixingit Yes but I installed the Mainline GUI and just installed the latest stable Kernel which was 5.14.13 So far so good, haven’t run into any major issues, but I’ve been mainly focused on tweaking power efficiency.
By definition, disabling PSR should negatively impact battery life as the purpose of PSR is to increase battery life. I haven’t run any analysis myself or anything, even anecdotal, but I feel like battery life was close enough to what I had with 21.04 it wasn’t worth mentioning.