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

[poperigby]

• Sway Version:
  1.6

• Debug Log:
  https://gist.github.com/PopeRigby/2f047584dec4988b460a2aab7559d2e1

• Configuration File:
  I was able to reproduce with the default configuration file /etc/sway/config

• Description:

  • Launch Steam
  • Launch Dark Souls Remastered, but this isn't specific to this one. All of the Dark Souls games seem to have this issue.
  • Start new game/continue (just need to get into the game world)
  • Switch to another workspace (for around 30 seconds)
  • Switch back to the game's workspace
  • Get booted from the game because your framerate is too low for online play

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

[vyivel]

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]

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]

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]

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

[poperigby]

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]

It's not ours either.

[poperigby]

Who's do you think it is then?

[fluix-dev]

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

[kujeger]

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 libsdl-org/SDL#4335 .

[kennylevinsen]

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]

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

[poperigby]

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

[progandy]

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]

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]

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]

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]

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]

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

[kennylevinsen]

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]

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