Games launched through Steam are not fullscreen in floating mode

[shoober420]

I remember reading somewhere that if you run a game in window mode, that it renders through the X server instead of directly from the GPU. When you run Fullscreen, it renders directly from the GPU, bypassing the X server. Supposedly, running through the X server is never a good idea and can effect performance.

So my question is, when I launch a game with bspwm, is it running true Fullscreen or just a borderless window that takes up the whole screen?

[shoober420]

So, I did some testing, and it seems certain games do indeed launch fullscreen. But some still remain in an window. A good way to test this is launching "Gone Home". It's a indie game on Steam. It launched in a window Instead of Fullscreen. But, Quake 1 via the QuakeSpasm source port did indeed launch fullscreen. You may want to force true Fullscreen for all games. Until then, I'm sticking with awesomewm.

[lamarpavel]

You may want to force true Fullscreen for all games.

How would you determine what a game is? Say I launch the files /usr/bin/quake3 and /usr/bin/mpv, how is bspwm supposed to know that one is a game and the other is not?

You can do this manually by setting rules like bspc rule -a quake3 state=fullscreen in your bspwmrc.

[shoober420]

OK, to be more specific, if a program, especially a game, requests to be fullscreen, it should be fullscreen.

If the program asks for it, then it should happen. There should be no reason to manually do it if the window manager handles the call properly.

It doesn't really matter whether it's a game or a media player, if the program asks to be fullscreen, then fullscreen it should be.

How do we know using "state=fullscreen" on a program that doesn't launch fullscreen, isn't just remaining in a borderless window that's unmovable? It would then be rendering through X11 instead of directly from the GPU like it should be.

[lamarpavel]

I don't know how bspwm actually does it, that would be interesting to know. What we are talking about here is X11 window hints, which programs can emit to inform the window manager what to do and having looked at the X11 protocol, I can say that it is not a nice thing to work with, but if there is a window hint for "direct rendering fullscreen" and bspwm is not respecting it, then this could be seen as a bug (unless it is done to prevent some problematic behaviour otherwise).

I don't think it is possible to bypass the X11 display renderer entirely, though. To do that, the game would have to write its own input/ouput handling for keyboard, mouse, the DRI interface and you would no longer be able to issue commands to your WM such as terminating a window. You would be bypassing the xf86-video-driver of your hardware manufacturer (eg. xf86-video-intel or xf86-video-amdgpu). The developer of the game engine would have to do all that on their own and coul not use libraries like SDL or GLFW to create OpenGL-contexts connected to an I/O device. In the end, your games will probably always talk to the xorg-server (or wayland, if you are using it) and request to show an image on screen. Maybe you can link to some documentation that explains what you mean by "rendering directly"?

[baskerville]

There was a proposal related to this. I guess it wasn't accepted by the EWMH committee.

[lamarpavel]

Interesting thread, especially the input from the e17 dev. A quick glance at the EWMH spec [1] reveals that no such window hint has been added. So now I'm wondering how AwesomeWM or others handle this to satisfy users? cc @shoober420 It must be a combination of the _NET_WM_STATE_* hints (eg. _NET_WM_STATE_FULLSCREEN + _NET_WM_ABOVE) and additional hints like, _NET_WM_OPAQUE_REGION and _NET_WM_WINDOW_TYPE_* that most games use and that the WM simply interprets independet of any EWMH standard.

[1] https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html

[baskerville]

@shoober420 You could try creating a rule for the problematic game with manage=off as consequence.

[shoober420]

Yes, I'll give it a try when I get home from work. Thank you for your consideration.

[shoober420]

Just so I have a better understanding, I was reading about X11 vs Wayland for games. And numerous people said the performance would be the same since it renders directly to the screen if it's fullscreen (unless it's Xwayland). I'm sure input goes through the X server, but rendering should skip the X server. There's a diagram on Wikipedia on the graphics stack and it indeed does this if fullscreen.

[shoober420]

Here is a picture of what I mean.

http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure

According to that chart, OpenGL programs are rendered directly to the screen, unless indirect rendering is being used. X11 programs are handled differently. If indirect rendering is used, then it's treated as a X11 program.

[shoober420]

OK, I think I know the problem. It only effects Steam games when in floating mode. If I launch Steam games from the default tiling mode, they are indeed true fullscreen and unmovable. But, when I go to my floating desktop, and launch a Steam game from there, it's windowed and movable.

Weird thing is, if I launch Quake 1, Quake 2, Quake 3, Doom, Doom 3, and anything not inside Steam, the game is true fullscreen and unmovable, even in floating mode. It must be something with launching games from Steam in floating mode.

[baskerville]

The xprop output of a floating and tiled Steam window might be helpful.

[lamarpavel]

This might be due to steam overlay, which might affect the window creation. Have you tried turning steam overlay off for testing purposes?

[shoober420]

I do have the overlay disabled for all games. I'll do an xprop when I get home from work.

[shoober420]

Here is Steam when floating:

_NET_WM_DESKTOP(CARDINAL) = 2 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 WM_NAME(UTF8_STRING) = "Steam" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW WM_HINTS(WM_HINTS): Client accepts input or input focus: True _NET_WM_ICON(CARDINAL) = Icon (48 x 48):

WM_CLASS(STRING) = "Steam", "Steam" WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 1056, 14 user specified size: 992 by 1508 program specified minimum size: 900 by 600

Here is Steam when tiled:

_NET_WM_DESKTOP(CARDINAL) = 0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 WM_NAME(UTF8_STRING) = "Steam" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW WM_HINTS(WM_HINTS): Client accepts input or input focus: True _NET_WM_ICON(CARDINAL) = Icon (48 x 48):

WM_CLASS(STRING) = "Steam", "Steam" WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 1056, 14 user specified size: 992 by 1508 program specified minimum size: 900 by 600

[shoober420]

I must add that playing "Gone Home" when in tiled mode makes the dimensions all messed up. The GUI is scaled wrong and even the rendering isn't right. Its zoomed in and runs very poorly. The FPS is somehow effected by it being in tiled mode. I will post a xprop of Gone Home in tiled and floating mode shortly.

On the plus side, it seems to be the only game I've come across that has issues with being launched in tiling mode.

[shoober420]

Sorry I haven't posted back in a while. I've been busy. I just was about to post the xprop of Gone Home when I realized that I can only do it when it's in window mode and floating. I assume that won't be of much help. If it is, let me know.

[shoober420]

Im going to close this, as bspwm isnt meant for floating mode, and tiling is superior anyway.