Closing this since I switched to Fedora 40 and this issue is not present there, so I'll safely assume it's unrelated to Proton.

Same issue on Arch with KDE Plasma 6.2 with both X11 and Wayland while playing Metro Exodus

I don't think this should be closed, I am having the exact same issue with every Proton game I try, native Linux games are working correctly. I even tried using both native and Windows versions of a single game (CrossCode): Linux version worked correctly, Windows version through Proton had the mouse captured on the wrong monitor. I tried Proton 8, 9, and 9 GE, they all have this bug.

I'm on Lubuntu 24.04 with OpenBox for wm. My GPU is an Nvidia 2080 using the proprietary driver v550

@WyntrHeart - I closed this since I was only seeing it on Ubuntu. If you feel it should be reopened, I would say make a new issue so you own it and reference this one. I don't have any machine experiencing this issue anymore, so I wouldn't be able to easily verify potential fixes.

Ah, that does sound sensible. One question before I go though. Since I've found a couple threads that appear to be related to this same problem and none have any clues for a fix, I'll probably have to figure this out on my own. So in order to figure out some places to start looking, do you happen to know anything Ubuntu and Arch have in common that is different on Fedora that could be related to this? I'm a Linux noob, so I don't even fully understand the software in my own system (like, what the heck do the X display server, SDDM display manager, and OpenBox window manager all do? The only specifics I know is that OpenBox handles placement and decoration of windows, among other things I think). Knowing what parts of Fedora's input and monitor related software stack differ from my setup seems like it could at least help me find a place to start

Do you happen to know anything Ubuntu and Arch have in common that is different on Fedora that could be related to this?

The million dollar question! 😉

This is a tricky issue because there are a lot of elements at play. Things you might want to pay attention to if you find others with this issue are:

• Which distro are they seeing it on?
• What Linux kernel are they using?
• Are they on Nvidia or AMD graphics and what driver version?

My hypothesis is that it has something to do with the Wayland window manager/compositor Ubuntu is using not playing nice with Proton.

Things you could try to see if it fixes it:

• Update your Nvidia drivers to a newer version (anything below 555 is known to have incompatibilities with Wayland)
• Try installing Ubuntu 24.10 and see if you still have the issue

It couldn't be Wayland, I'm on X11. So it's affecting both.

Since the actual display is working correctly, I'm thinking it might be something more specific to input handling. The only software component I'm aware of related to that is xinput, but that's specific to X, so I would think it must be something else. I guess I'll start by researching what systems are involved in handling mouse input. Or maybe I can start by looking into how Proton in particular does mouse capture. I hope I can find some good documentation, I'm terrible at reading code >_<

Similar issue also happens on Gentoo with kernel 6.6.74-gentoo-dist, Wayland/Sway for WM and with an AMD RX 6700XT GPU. Interestingly enough, games affected (in my experience) do not show the issue when it's being played on the second monitor.

Gamescope tends to solve the issue, but is mostly unreliable on my system (crashes a bunch sadly).

I do request the issue to be reopened if its OK.

Found a possible(?) workaround with protontricks, essentially run $ protontricks STEAM_GAME_ID_HERE winecfg and enable virtual_desktop with the desktop size set to the size of your monitor. Works with Balatro in my case, but I'm not sure if it will work with more complex games.

Since this is getting a little more attention and it doesn't look like this issue has been mentioned in another, I'll re-open this one. I'm not experiencing this issue on Fedora 41, so I'll have to ask you all to test any potential fixes and decide when/if to close this.

I have a... somewhat similar issue.

My primary workstation is a laptop with a native resolution of 2256x1504. I have an external display that is 2560x1440. I use Wayland, and a tiling compositor (river, but this shouldn't matter). When my laptop is connected to the external display, it does this through a thunderbolt dock, which outputs to a hardware KVM, which outputs to the display. I use kanshi to automatically disable the native display, and enable this external display.

I have a game configured to use Proton in Steam. When I launch the game after docking my laptop (such that the only display my system knows about is the external display) my mouse is "stuck" to the left side of the game window, at roughly half the width of the delta between my native display and the external monitor (~150px wide). It's as if the game is "centered" and the window is stuck at my laptop's native display.

Found a possible(?) workaround with protontricks, essentially run $ protontricks STEAM_GAME_ID_HERE winecfg and enable virtual_desktop with the desktop size set to the size of your monitor. Works with Balatro in my case, but I'm not sure if it will work with more complex games.

Can confirm, it is working for overwatch 2. I had to use a window rule to remove the frame. I'm on Nobara 42, Proton experimental. I have tested in full-screen and border-less window mode. In both cases cursor is not escaping to my second monitor like before.

I figured out my issue. Even though kanshi was disabling my native display, the virtual position of the external monitor wasn't set to 0,0, causing Steam to detect that the display was pushed over. I think this caused the game to behave erratically.

Explicitly setting the display's position to 0,0 in my kanshi configuration solved my issue.

Explicitly setting the display's position to 0,0 in my kanshi configuration solved my issue.

Had similar issue, same problem with kanshi. I had profile for laptop primary monitor that mentions and explicitly disables external output. Adding position to this profile didn`t help, but i defined profile with only laptop output and position and it finally worked. Kanshi was unable to match profile with two outputs but one disabled when disable one is not connected.
I hope someone with similar setup will find it useful

Kanshi was unable to match profile with two outputs but one disabled when disable one is not connected.

This is unrelated to this issue, and is instead a defined and expected behavior of kanshi. The output attributes defined in a kanshi profile could more aptly be called "queries". By this, I mean that the outputs defined in a profile cause kanshi to apply that profile only if the listed outputs are detected.

This means that with the following configuration:

profile default {
  output "eDP-1" enable
}

profile docked {
  output "eDP-1" disable
  output "DP-1" {
    mode 2560x1440@60Hz
    position 0,0
  }
}

The default profile will be applied when only eDP-1 is detected, and the docked profile will be applied when both eDP-1 and DP-1 are detected. Basically, kanshi lists all of your currently connected outputs, and then looks for a profile that has all of those outputs defined.