Multiple XWayland games in high resolutions (4k) suffer from a stuttering or lagging mouse on Wayland. This issue exists in OpenTTD and in multiple proprietary games, it is not 100% consistent in all test, but I think in OpenTTD it is obvious. I have the feeling it is related to a threading issue, changing the power governor of the CPU somehow seems to reduce the issue (tested with LD_PRELOAD=$LD_PRELOAD:/usr/\$LIB/libgamemodeauto.so openttd). Tested with Kwin-git and kwayland-git on Arch Linux Plasma 5.13.5 KDE Frameworks 5.49 Qt 5.11.1 XWayland 1.20.1 libinput 1.11.3
Could you please check whether KWin has real time priority?
I found the following information. If I understand your blog post about real time priority of kwin correctly, it seems like SCHED_OTHER might not be enough? I played around with other values, but it didn't change anything fundamentaly. What would be the expected values of SCHED and Prio? $ ps -eL | grep kwin 1616 1616 tty2 00:00:01 kwin_wayland 1616 1620 tty2 00:00:00 kwin_wayla:cs0 1616 1621 tty2 00:00:00 kwin_wa:disk$0 1616 1622 tty2 00:00:00 kwin_wayla:sh0 1616 1623 tty2 00:00:00 kwin_wayla:sh1 1616 1624 tty2 00:00:00 kwin_wayla:sh2 1616 1625 tty2 00:00:00 kwin_wayla:sh3 1616 1626 tty2 00:00:00 kwin_wayla:sh4 1616 1627 tty2 00:00:00 kwin_wayla:sh5 1616 1628 tty2 00:00:00 kwin_wayla:sh6 1616 1629 tty2 00:00:00 kwin_wayla:sh7 1616 1630 tty2 00:00:00 kwin_wayla:sh8 1616 1631 tty2 00:00:00 kwin_wayla:sh9 1616 1632 tty2 00:00:00 kwin_wayla:sh10 1616 1633 tty2 00:00:00 kwin_wayla:sh11 1616 1634 tty2 00:00:00 kwin_way:shlo0 1616 1635 tty2 00:00:00 kwin_way:shlo1 1616 1636 tty2 00:00:00 kwin_way:shlo2 1616 1637 tty2 00:00:00 kwin_way:shlo3 1616 1638 tty2 00:00:00 kwin_way:shlo4 1616 1639 tty2 00:00:00 kwin_way:gdrv0 1616 1703 tty2 00:00:00 kwin_wayland 1679 1679 tty2 00:00:00 org_kde_kwin_xc $ chrt -p 1616 Derzeitige Scheduling-Vorschrift für PID 1616: SCHED_OTHER Derzeitige Scheduling-Priorität für PID 1616: 0
Yes, other is wrong. The capability of kwin_wayland might not be set. Could you check this as well? Iirc it's the getcap command
This is the output: $ getcap -v /usr/bin/kwin_wayland /usr/bin/kwin_wayland I assume you would expect to see CAP_SYS_NICE, right? Thanks!
Yes! That means we have a packaging bug.
I've opened a bug report for Arch Linux https://bugs.archlinux.org/task/59988. Therefore I will close this bug here. Thank you for the fast feedback!!!
Well it's not guaranteed that it will fix it. But yes the intention of the realtime change was to prevent such situations.
I face similar issues but only with animations. On X11, animations are smooth (with and without open applications). On Wayland, if I don't have any open apps, animations are smooth. If I open Dolphin, for example, and open Kickoff, then the slide(from sliding popups effect) animation will lag. CAP_SYS_NICE is set.
We also have a bug on our side. setcap running as a regular user fails. but there's nothing in the output to indicate that. We can't change the failure, but we should print a message. I'll sort that out.
Edit. It does. Sorry.
We now have the correct capabilities set on kwin_wayland but this still doesn't work > getcap -v /usr/bin/kwin_wayland /usr/bin/kwin_wayland = cap_sys_nice+ep > chrt -p $(pidof kwin_wayland) pid 601's current scheduling policy: SCHED_OTHER pid 601's current scheduling priority: 0 Not sure if/what else is missing from our side.