Mouse cursor is getting stuck on screen edge in some games

[valeth]

Operating System

Nixos

Wayland Compositor

Niri

Describe the issue.

In some games the mouse cursor can become stuck at either the left or right side of the screen, making it impossible to use the mouse for input in menus.

In the cases I tested (so far Warframe, and Deep Rock Galactic) the mouse can still escape and enter the window without issue, but clicking onto the window either won't work, or it captures the cursor and locks it in place again.

Sometimes the cursor can be corrected by switching the window to a different screen, but often it just gets stuck on the other side.

I was testing this with the latest release on NixOS unstable, and currently the flake.
The problem appears with both.

Here is a demonstration video to hopefully showcase the problem better:
https://youtu.be/QtgK6oVhPos

Steps to reproduce

I am currently not 100% sure how to trigger this reliably, but the following steps seem to result in it happening.

Precondition: Have multiple monitors

1. Launch a game in fullscreen mode
2. Move the cursor outside of the window onto a different screen
3. Move the cursor back into the game window
4. The cursor now has a chance to become stuck

Please confirm you have reproduced this on the latest commit.

• I have reproduced this on the latest commit

[Supreeeme]

Can you post a log? Is this on the latest git commit?

[valeth]

Is there an alternative log output to stdout/stderr?
Because xwayland-satellite is launched through Niri, which sends all output to /dev/null.

[valeth]

Here's a log from a manually started instance, while triggering the bug again
xwayland.log

The version in the logfile doesn't include the git commit hash, this is the full path to the executable:

$ which xwayland-satellite | get path.0 | readlink $in
/nix/store/lpf8iv40z9iqfibz0fp3qfnbqsy3irkk-xwayland-satellite-0.6.0-e0d1dad/bin/xwayland-satellite

[valeth]

I did some additional testing using Hyprland, and it exhibits the same issues.
The logs pretty much just show the same output: xwl-s-hyprland.log

So it is very unlikely that it is just Niri.

[valeth]

Captured a new hopefully more useful log with RUST_LOG=debug
This is still using e0d1dad like the last log

xwl-s-niri.log

[yuukibarns]

#66 (comment)

[valeth]

I have not been able to reproduce this issue for a while now, so I think this can be considered fixed.
I'll re-open the issue if it appears again.