search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.51k stars 1.11k forks source link

Getting booted from Dark Souls Remastered when window is invisible because "framerate is too low for online play" #6263

Open poperigby opened 3 years ago

poperigby commented 3 years ago

To be clear, this only happens when the game window is invisible. It never happens when I'm playing the game.

vyivel commented 3 years ago

I think it's because invisible windows don't get rendered => they don't receive frame done events => the game thinks its FPS is 0. (Not sure if it applies to X11 windows at all, though.) Does it work correctly with an X11 window manager?

kennylevinsen commented 3 years ago

The game likely blocks on eglSwapBuffers due to not receiving frame events. If it is timing rendering operations, it will seem like fps dropped to zero.

poperigby commented 3 years ago

Does it work correctly with an X11 window manager?

Yeah. I just installed i3 to check and it was fine after leaving it for over a minute.

emersion commented 3 years ago

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1118

poperigby commented 3 years ago

Heh. That's actually me that filed that issue. They said it wasn't an XWayland bug, so I'm guessing it's a Sway issue?

emersion commented 3 years ago

It's not ours either.

poperigby commented 3 years ago

Who's do you think it is then?

fluix-dev commented 3 years ago

It seems like the game's. It shouldn't really care about client frame rate when it comes to having a server connection.

kujeger commented 3 years ago

It's by design in wayland that hidden windows "stop" rendering, and it does make quite a few things break and/or bug out, particularly games (I also often have video meetings in chrome break if the window gets completely hidden). It happens in all wayland compositors and is not particular for sway.

See also https://github.com/libsdl-org/SDL/issues/4335 .

kennylevinsen commented 3 years ago

We don't stop windows from rendering - a client is always free to render and submit frames which may or may not be shown. We do not send the optional frame events to hidden windows, as these events mean that it's a good time to start rendering your next frame for us. This is a feature, as it automatically save resources from useless rendering when windows are hidden anyway.

Xwayland is in some regards just a Wayland client, and ends up inheriting some Wayland behavior. While refresh rate has always been variable, X applications might get slightly confused by the rate dropping all the way to zero 1 Hz. Regardless of this change, the games in question are broken as they conflate refresh rate with frame rate in some broken logic of questionable purpose.

You should be able to work around it by either disabling vsync in the game, or doing vblank_mode=0 ./game to forcibly disable synchronization in mesa.

emersion commented 3 years ago

Note, Xwayland will fallback to a 1s timer when the compositor stops sending frame events.

poperigby commented 3 years ago

Turning off v-sync seems to fix the issue. Setting vblank_mode to 0 doesn't.

progandy commented 3 years ago

Another option may be to run the game in a nested gamescope

Or sway would need a window config setting to generate frame events when they are hidden similar to the idle inhibition.

sykhro commented 3 years ago

I have a similar problem with AnyDesk. When I place it in a different workspace it stops receiving events, so when I switch back to it I see everything sped-up until it catches up. The same issue happens on GNOME as well, so if it's not XWayland I really wonder where the problem is

varris1 commented 3 years ago

It looks like there is an extension in the works to fix this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99

There is already a pull request by emersion: #6336

poperigby commented 3 months ago

That protocol PR was closed, but it looks like this one is a continuation: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/276

kennylevinsen commented 3 months ago

A different version of surface suspension was merged through a new "suspended" xdg_toplevel state. See https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:suspended

poperigby commented 3 months ago

@kennylevinsen Ah, great. So will this particular problem be fixed soon, or does that protocol not fix the issue?

kennylevinsen commented 3 months ago

xdg_toplevel is not applicable to X11 clients like games run through Steam (which use xwayland_shell through Xwayland), and it's up to the client themselves to react and change behavior when suspended. So no, I do not expect that to fix games played through proton soon.

The refresh cycle protocol you link is more flexible, but it still requires clients themselves to run their own timers.

If you want a solution now, I imagine setting up gamescope should sort it out.

poperigby commented 3 months ago

So is this something that should be fixed in the Wayland version of Wine?