https://bugs.kde.org/show_bug.cgi?id=509669
--- Comment #15 from fililip <[email protected]> --- This issue manifests itself in the same manner regardless of whether or not the hardware cursor is in use (I tried KWIN_FORCE_SW_CURSOR=1 as per my comment above). As such it can't be caused by DRM or amdgpu, especially when session content presentation is otherwise stable (when the cursor position stutters there are no desktop-wide freezes/mini-lockups), hardware cursor image changes work fine prior to the regression commit on the same kernel version, and the problem happens across multiple AMD Display Core Next ASIC versions. Ideally I'd test this on an Intel machine as well, but I am unfortunately no longer in possession of any. (NVIDIA has a hardware cursor position change + presentation consistency issue so that is not a feasible option here) It's not tied to overlay planes either, since I have both two active screens and KWIN_USE_OVERLAYS set to 0 (and it's exactly the same even with overlays enabled anyway). My question is: is it possible to temporarily force KWin to perform these cursor updates asynchronously again? How should I go about trying to fix it myself (ie if it makes sense to somehow bring back connect() for Cursor::positionChanged in compositor.cpp)? I realize this issue is a bit nitpicky (in contrast to https://bugs.kde.org/show_bug.cgi?id=504321 for example), and that there are more pressing matters to attend to (and I do apologize for the noise), but there's a chance that if this ends up in the release version, people will notice it on their 1kHz/8kHz mice and highres + high refresh rate setups. I caught this in around an hour after grabbing 6.4.90 packages. -- You are receiving this mail because: You are watching all bug changes.
