Mouse stuttering after upgrade to sway 1.5

[jakobkukla]

Description:
After I upgraded to sway 1.5 and wlroots 0.11 today I experienced mouse stuttering. My mouse will freeze every 10 seconds or so for half a second or more. Downgrading to 1.4 and 0.10 solved the issue for me.

I tried to record the problem with wf-recorder but interestingly the issue won't appear while recording.

Version:
sway 1.5
wlroots 0.11

Debug and Config:
https://gist.github.com/jakobkukla/6a5c9ddc092c241424ede9af09e9ee2c

[b10rn]

I also have a problem with mouse stuttering, but it happens only occasionally and I am not sure if it is the same issue that you are experiencing. When it happens to me it is always triggered by focusing on a text input field in Firefox and starting to type, but as I said, it only happens occasionally. I can see that my CPU load goes up dramatically while the FPS drops to an unusable level, supposedly causing the mouse stutter. The solution for me is to reload the Sway configuration. At that point, everything goes back to normal, except that Firefox sometimes crashes. I cannot reliable reproduce it, but it generally happens several times a day.

[jakobkukla]

I believe that's a different issue. For me the problem is immediate and does not require to open firefox or any window.

[emersion]

Your bug report is missing debug logs. Please add a link to the full debug log file.

[junglerobba]

@jakobkukla You don't happen to be using a swayidle script that runs something like swaymsg "output * dpms on" or similar on resume with a short timeout? I ran into that same issue and removed that part from my config for the time being.
Something changed in sway 1.5 that makes the display (not just the cursor) hang for a short amount of time when running that command, even if the output is already on.

[emersion]

@junglerobba The hang might be related to #5606

[b10rn]

I recently found that my problem with stuttering occurs whenever I change the input xkb_layout setting at runtime. I have the xkb_layout command bound to a key sequence in order to switch between input layouts.

[NilsIrl]

I just upgraded to sway 1.5 and am having the same (or similar) issue.

When my cursor changes between monitor, it stutters and increases CPU usage. If I continuously move between monitors, CPU usage is consistently above 400% for the sway process. Another thing that triggers this problem is running the following command then and moving the cursor around:

swaymsg -t get_tree | jq -r '.. | select(.pid? and .visible?) | .rect | "\(.x),\(.y) \(.width)x\(.height)"' | slurp

[NilsIrl]

And watching a YouTube video (via Firefox) causes the sway process to use 300+% CPU usage. I don't know if it's related.

[danielrode]

I have also been experiencing input lag since upgrading to Sway 1.5.

Output of swaymsg -t get_version: sway version v1.5
wlroots version: 0.11.0

After idling (not moving my mouse or pressing keys on the keyboard) for about 30 seconds, when I move my mouse or press a key on my keyboard, there is a lag (about half of a second). The mouse-pointer on screen will stutter after the initial lag and then proceed to move around smoothly.

Steps to reproduce:

Note: For sake of simplicity, I bypassed my config file for the following reproduction. I told Sway to use the default config file. The issue manifests itself just the same.

1. Run: sway --config /etc/sway/config --debug 2> ~/working/sway.log
2. Start swayidle:

swayidle -w \
    timeout 290 'notify-send -t 5000 \
    "Screen locking in 10 seconds if inactivity continues..."' \
    timeout 300 'swaymsg exec \$swaylock_cmd' \
    timeout 310 'swaymsg "output * dpms off"' \
    timeout 10 'if pgrep swaylock; then swaymsg "output * dpms off"; fi'\
    resume 'swaymsg "output * dpms on"' \
    before-sleep 'swaymsg exec \$swaylock_cmd' \
    > /dev/null 2>&1 &

3. Wait about 30 seconds.
4. Move the mouse or press a key on the keyboard.
5. There will be an approximately half-second long lag.

I repeated the steps 3 and 4 several times just to give some variety in the debug log: tested with my mouse, my touchpad, and my keyboard.

The issue does not occur when swayidle is not running. It also does not occur when I remove this line from the swayidle command:
timeout 10 'if pgrep swaylock; then swaymsg "output * dpms off"; fi'\
which makes it:

swayidle -w \
    timeout 290 'notify-send -t 5000 \
    "Screen locking in 10 seconds if inactivity continues..."' \
    timeout 300 'swaymsg exec \$swaylock_cmd' \
    timeout 310 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"' \
    before-sleep 'swaymsg exec \$swaylock_cmd' \
    > /dev/null 2>&1 &

This supports what @junglerobba said about the issue likely being related to dpms. Please note, swaylock was not running at all for the duration of the test, which means that the timeout 10 part of the line is specifically what seems to be the issue. Maybe after any sort of timeout, even one that does nothing, swayidle sets a trigger for the resume command to be run in response to user input.

Debug log

[jakobkukla]

@emersion

first of all sry for letting you wait so long.

here are my config and debug files

[jakobkukla]

@emersion My issue is related to gammastep. I removed it from my config and sway 1.5 works fine now. This might be related to swaywm/wlroots#2349.

[danielrode]

I assume you are referring to the redshift program? I do not have that in my config file and the issue was still present. Either gammastep and dpms are both triggering the same stuttering issue or they are both separate. I find it more likely that they are related, especially since they both emerged with the release of Sway 1.5.

[emersion]

Re-opening since the bug isn't fixed.

[jakobkukla]

I assume you are referring to the redshift program? I do not have that in my config file and the issue was still present. Either gammastep and dpms are both triggering the same stuttering issue or they are both separate. I find it more likely that they are related, especially since they both emerged with the release of Sway 1.5.

Yeah, it's a redshift replacement for wayland. Seems to me that something has changed in 1.5 that triggered that behavior for all of us experiencing these stuttering issues. Sry for closing prematurely.

[AndreasBackx]

This seems to be resolved for the master branches of wlroots and sway. For me it seems to have been caused by this warning being spammed in my sway logs: https://github.com/swaywm/wlroots/blob/238d1c078fb03338e9f271d98f7bf6b1fc399285/backend/drm/legacy.c#L157

[josefbachmann]

This seems to be resolved for the master branches of wlroots and sway. For me it seems to have been caused by this warning being spammed in my sway logs: https://github.com/swaywm/wlroots/blob/238d1c078fb03338e9f271d98f7bf6b1fc399285/backend/drm/legacy.c#L157

I had exactly the same problem. I was on Arch LTS with kernel 5.6.x which updated recently to 5.10. redshift wasn't working anymore since the 5.10 update and the mouse freezes began. I disabled redshift and everything works. With kernel 5.6 sway & redshift worked; with 5.10 i just don't use redshift anymore... sadly
I don't understand the connection though, since wlroots and swaywm version haven't changed since the kernel update for me last week or am I wrong here?

sway: 1.5.1

Edit: disabling swayidle changed nothing for me.

[tomekw]

I have the same problem on new install of Debian Bullseye (sway 1.5, kernel 5.10)

https://gist.github.com/tomekw/3a73a3f826ae88166b85ed6e8e6e1f6c

[dmvianna]

Ditto on NixOS unstable (sway 1.5.1).

I disabled swayidle, then gammastep, and the problem persisted. However I noticed waybar dies not long after in one of my machines, and when it does, the stuttering ceases. I'm using a bluetooth mouse (Apple Magic Mouse first gen). The problem doesn't manifest itself when using a wired mouse.

[oliversturm]

I can't be completely sure that my situation belongs here, but I have issues with lag of mouse and keyboard. The problem comes randomly - or that's what it seems like - sometimes after days of uptime, sometimes sooner. The trigger never seems to be the same, but I do believe I have on occasion felt that entry in a text field in the browser may have caused the issues.

When things start to go bad, I have trouble moving my mouse - it lags and stops in places, making it hard to point at anything in particular or to move the cursor across a screen (never mind my three screens!). At the same time I have trouble with keyboard entry: there are delays, but what's worse is that keys "stick" horribly, so when I try to type one command in a console window, I may end up with something like sudoooooooooooooooo rrrrrrreeboot.

Today, for the first time, the problem did not go away at all. I ended up logging out of Sway and changing to sway-git (AUR) - will see if/when the problem comes up again. Previously the issue always went away after a while, perhaps after switching workspaces a few times, clicking in different windows, etc.

Finally, I thought for a while that there was some trouble with USB devices on my machine - the behavior reminded me of interrupt issues (if you were using Linux a couple decades or so back, you know what I mean). However, I can switch to a character console and my keyboard behaves normally there while it's unusable in Sway.

At this time I'm reporting my experience for completeness. Please let me know if you're interested in details of my setup.

Edit: I was meaning to mention that I don't use any of the suspect software mentioned in this issue, i.e. swayidle, gammastep, waybar (I use swaybar, but I tried to kill it when the issue occurred today and it didn't make a difference). I don't do anything with DPMS either.

[marcin-sucharski]

In my case the behavior is directly connected to the swayidle. Following lines cause the issue:

timeout 5 'if pgrep swaylock; then swaymsg "output * dpms off"; fi' \
   resume 'swaymsg "output * dpms on"' \

After five seconds of inactivity, if I move my mouse, there will be visible lag even if swaylock is not running.

Regarding other issues mentioned here, especially those related to kernel update: I had similar issues with applications dying, weird keyboard behavior etc. when cpu governor was set to powersave. I changed it to performance (recommended for modern Intel hardware anyway) and these issues were gone, so it may be worth a try. Mouse lag caused by swayidle is still there though.

[jessesung]

With Sway 1.7 this issue can be reproduced by simply running swaymsg "output * dpms off" ; sleep 10; swaymsg "output * dpms on".

Also it seems mouse stuttering only happens with terminal windows like tilix or alacritty. In other windows like firefox, mouse just works without an issue...

EDIT: Like one of the comments above, the issue on my system goes away after switching from waybar back to sway-bar.

[supermarin]

I'm having the same issue, but completely different repro: if the laptop is connected to a HDMI 2k monitor (via usb-c dongle), this doesn't happen. Connecting the laptop to a LG Ultrafine via thunderbolt (1 cable connection only) produces this problem. The mouse freezes almost immediately after you stop moving it. Same for the BT keyboard.
Sway 1.7 on nixos.

[samhh]

Some issues I've observed:

• Wireless mouse has minor jitter.
• Wired/wireless trackpad has major stuttering.
• Possibly unrelated: Slack becomes very laggy if you have a huddle stacked atop the main window.

Notably, the first two issues do not present at all when the cursor is over a Firefox window, suggesting it's a software/WM issue. They've been consistent since I switched to Sway ~a year ago.

The issue doesn't go away after killing Waybar, Swayidle, and Gammastep.

Interestingly if you can find a piece of UI like a list in which each item highlights as you hover - such as the Obsidian sidebar - that will render smoothly even as the cursor lags behind.

Edit: Changes a bit if I disable adaptive sync. Seems better but similar issues persist. Really hard to nail down.

[francocalvo]

Hey! I'm having the same issue. NixOS+Swaywm and Waybar. When I open videos, or after a while it starts to stutter. So far the only solution I've found was rebooting, which is obviously not practical. I don't have either Swayidle or Gammastep enabled in my system.

[jessesung]

Forgot to leave a comment here. I cannot reproduce the issue any more after an update of Waybar a while ago.

[supermarin]

also haven't noticed in a bit, although I switched some hardware

[samhh]

Unfortunately I can still reproduce this (1.8.1). It doesn't appear to correlate with CPU usage. It doesn't happen almost at all hovering Firefox, but a ton hovering foot. Actually, it lags over the address bar in Firefox as well. It's perfectly consistent going in and out of it.

[GrabbenD]

@asklow If it's happening due to VRR, try this:

1. Disable direct scanout to workaround refresh rate not matching your FPS
2. Try this branch which prevents mouse's polling rate from breaking monitor's refresh rate on cursor movement, here's usage instructions

[nnsee]

I, too, have stuttering when running dpms off and on. It started happening immediately after moving from an Intel based system to an AMD-based one - Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (OS install is the same, simply moved hard disks). I do not use waybar.