Mouse unusable in game's menus on a multi-monitor setup when running games with Proton fshack

[RicArch97]

• Sway Version

Sway version 1.6.1

• Debug Log

https://gist.github.com/RicArch97/7ff13a92adf718b26fd6af7d773cb1ac

• Configuration File:

The issue was reproduced with the default config.
My own configuration files can be found here

• Description:

Proton has a patch called "fshack". Which allows resolution changes for fullscreen games without changing desktop resolution, including a raw input patch that only works with fshack, that makes games much more playable.

I've tested this with 2 games:

• Overwatch on lutris, using lutris-fshack-6.14 and lutris-ge-6.14-2
• Far Cry 5 on steam, using proton-6.14-GE-2

I believe Proton has this patch enabled by default, in lutris it is optional.

The problem is that the mouse is not usable in the menus of both games. The mouse pointer changes into the game's pointer, and moves around just fine, but entries cannot be clicked. In a lot of games this is a problem because the mouse is necessary to play the game. When using the keyboard to enter a training range, the mouse does work for aiming and shooting correctly.

When testing this on just a single monitor, everything seemed to work fine. With a 2 monitor setup (even with default config) the problem occurs. That's only when running the game on monitor 2. On monitor 1 the mouse works just fine.
My monitors are set up like so:

-------------------------    -----------------------------------
  monitor 1 (16:9)                   monitor 2 (21:9)         
  3840 x 2160                        3440x1440
  left                               right
-------------------------    -----------------------------------

When using scaling on monitor 1 however (1.5), the mouse was "working" in the far right section of monitor 2, when moving the mouse around in the far left section of monitor 2.

My guess is that the mouse pointer somehow operates on the area of monitor 1 (3840x2160) while the game is running on monitor 2. And with scaling monitor 1, is overlapping into monitor 2. and because monitor 2 is starting at 2560, I was able to move the mouse in the far left side of monitor 2 and get a reaction on the far right side of the monitor 2.

I believe this to be a Sway issue as I was was not able to reproduce this issue on Gnome on the exact same setup.

[robclancy]

I got the same issue in overwatch with bspwm.

[RicArch97]

I got the same issue in overwatch with bspwm.

That's interesting, since that runs on X11, so the issue is probably not within XWayland.

But it's an annoying bug, since it makes playing any game at all pretty difficult. I've tested more steam games and the mouse seems to be completely unusable in the menus of all games tested.

Gnome does not have this issue. As a workaround I've decided to put Manjaro Gnome on dual boot and play all my games there. I have not tested KDE.

[robclancy]

For me the issue was because it was using the primary monitor for actual mouse input but I wasn't running the game on the primary. Basically, overwatch is doing something weird that wine doesn't account for.
Could be unrelated to this issue though.

[pinkfluid]

I'm having the same issue on two single monitor setups -- my main PC and my laptop. I've tested this only with Final Fantasy XIV online, but it seems that the issue is present whether I use fullscreen (no virtual desktop) with wine-fshack or proton-ge via lutris.

Gnome Wayland (gnome-shell --wayland) seems to work fine with both.

[pinkfluid]

It seems that the latest master version of sway fixes the issues:

sway --version
sway version 1.6-57d6f6f1 (Sep  2 2021, branch 'master')

I'm able to run fullscreen FFXIV with proton-ge an wine-fshack.

[RicArch97]

It seems that the latest master version of sway fixes the issues:

sway --version
sway version 1.6-57d6f6f1 (Sep  2 2021, branch 'master')

I'm able to run fullscreen FFXIV with proton-ge an wine-fshack.

I've tested with the master branch as well;

sway version 1.6-00b10a93 (Sep  3 2021, branch 'master')

Horizon Zero Dawn - Proton-GE-6.16
Overwatch - Lutris-fshack-6.14

Unfortunately, the issue is still there for me. Unable to use the mouse in the menu's.

[yernarakimzhanov]

It seems that the latest master version of sway fixes the issues:

sway --version
sway version 1.6-57d6f6f1 (Sep  2 2021, branch 'master')

I'm able to run fullscreen FFXIV with proton-ge an wine-fshack.

I've tested with the master branch as well;

sway version 1.6-00b10a93 (Sep  3 2021, branch 'master')

Horizon Zero Dawn - Proton-GE-6.16 Overwatch - Lutris-fshack-6.14

Unfortunately, the issue is still there for me. Unable to use the mouse in the menu's.

Still having the same issue. Did you manage to get it working?

[RicArch97]

This issue is revolved by setting a primary monitor for XWayland. You can do so by running xrandr to check the output names, and then for example: xrandr --output XWAYLAND0 --primary to set an output as primary. Make this persistent by using xwayland force at the very top of your Sway config and then you can run exec xrandr --output XWAYLAND0 --primary.

This is not an issue Sway can resolve in particular, as Wayland does not work with the concept of a primary output, and thus cannot provide that information. A lot of X11 apps do expect a primary monitor to exist however, so especially games running on XWayland tend to behave much better with it set.

[rinpatch]

For whatever reason my xwayland refuses to set a primary monitor.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  28
  Current serial number in output stream:  29

Worked around the issue by running steam inside of cage inside of sway (the command is simply cage steam)

[rinpatch]

Genshin Impact wasn't too happy running in cage, so I had to figure out something else. I used to have 3 monitor setup, left to right, with the rightmost one being primary. Later I disconnected the leftmost monitor, but didn't modify the config. So my new leftmost monitor had pos 1920 0. After setting it to pos 0 0 and adjusting the pos of the rightmost monitor to match the new config everything seems to work fine.

[weeviltime]

Genshin Impact wasn't too happy running in cage, so I had to figure out something else. I used to have 3 monitor setup, left to right, with the rightmost one being primary. Later I disconnected the leftmost monitor, but didn't modify the config. So my new leftmost monitor had pos 1920 0. After setting it to pos 0 0 and adjusting the pos of the rightmost monitor to match the new config everything seems to work fine.

Yes. Following your steps I was able to fix the same problem. Thank you very much!

Just to add and make it easier to replicate for anyone else trying to solve the same problem.

1. Edit your ~/.config/sway/config with the following

# Set your "primary" gaming monitor
output <NAME> <SETTINGS, which is mode, vsync/f-sync> pos 1920 0 # the pos is important. The order as well. This is my gaming monitor so I set it first.
output <NAME> <SETTINGS> pos 0 0 # the pos is important, even with 0 0 it doesn't become the Workspace 1.

Restart sway and only start your games/applications with mouse constraint on the "primary" monitor. If you start anything on the "secondary" it will present the same problems as before.

Example copy/paste from my sway/config

output DP-2 mode 1920x1080@144Hz adaptive_sync on pos 1920 0
output HDMI-A-1 mode 1920x1080@60Hz pos 0 0

[ammgws]

@Pobre If you start it on the "primary" monitor but move it to the secondary monitor, does it still work? Or do you always have to have the window in the "primary" monitor?