Factorio Forums

Hi!

This might be an Allegro "feature" that dates back to times when compositing was just "fancy eyecandy" without important functionality? Anyway, depending on user setup, disabling the compositor can leave users locked in (p.E. when they use compositing for window switching) until Factorio is closed or even totally stranded and unable to use their PC (p.E. if they require accessibility features that use compositing, like screen magnification). Since it is not immediately apparent that the compositor is turned off, that can be hard to recover from.

( BTW, just a little story for your amusement and to make my point: At first the idea that an application would do something like that on purpose didn't even occur to me - never encountered an application that did it before. So I falsely assumed that your game accidentally keyboard-grabs due to some shoddy third party input library that aspires to be part of a screensaver/locker one say and rule over all other input libraries. I dissected my window manager hotkeys, my .xbindkey configuration, then I started reading up on input and libx, tried reconfiguring Xorg to allow "keyboard releasing" - a feature I'm not sure is even part of Xorg any more. Browsed Xorg changelogs from the last 10 years, ended up messing with the libx source code, broke the whole keyboard grabbing mechanism on purpose, also broke my screensaver as a side effect, recompiled my whole DE and graphics stack and then some - to be sure - started reading the allegro source code, couldn't find anything... and that was my first day of "playing factorio" - I didn't realized that it was compositing or the lack thereof that broke my hotkeys and that I could just press ctrl+alt+F12 to turn it back on until later. By then, I was half way to ending up in kernel code again. I can't even really read code. Why do I always end up knee deep in source code? Oh well, that's Linux I guess )

Long story short... Since there is no "anti-feature" category, I'm putting this here: Please make your game keep its fingers off my window manager? :3

It might help to know what DE you use, mainly for testing purposes.

Factorio does not do anything to compositors. At least not actively. And indeed, at least on Gnome, compositing still works with Factorio running.

So I'm leaning toward this being a bug in your WM.

Oh...

Argh... then what's going on?

I assume you have allegro 5 statically linked? And that comment sounds kind of ominous :

allegro wrote: /* This seems like a good idea */
const long _NET_WM_BYPASS_COMPOSITOR_HINT_ON = 1;

~ https://github.com/liballeg/allegro5/bl ... lay.c#L249

Checked the factorio window...: What window manager are you using for testing? Maybe it doesn't honor extended window hints in the same way? I think the current version of gnomes "mutter" advertises support for the "X atom / _NET_WM_BYPASS_COMPOSITOR", but I have no idea what that means and I didn't test it. :3

I'm using kwin at the moment, which is honoring the window hint since version...:

support _NET_WM_BYPASS_COMPOSITOR
FIXED-IN: 5.20

~ (https://bugs.kde.org/show_bug.cgi?id=349910)

I'm not familiar with allegro and I can barely read C... is it correct that you can't turn off that window hint without changing the allegro source? So is this an upstream problem? Or am I totally on the wrong track?


In the meantime: Figured out that with kwin at least, I can turn off "allow application to block compositing" as a workaround.

Thanks for finding all these. Allegro coppied that code from SDL and SDL used the hint for performance reasons. But from the KDE bug report is seems not having the hint may cause driver crashes.
Anyway, we could probably expose it as an option in config.ini.

yay wrote:I'm not familiar with allegro and I can barely read C... is it correct that you can't turn off that window hint without changing the allegro source? So is this an upstream problem? Or am I totally on the wrong track?

That hint is supposed to be there. It exists specifically for games and other applications that don't want to be rendered offscreen.

Also, it's a hint that the WM isn't obliged to honour, so I think the configuration option should be left where it is: In the WM itself.

In other words, everything seems to be working as it should. So, not a bug.

Well, Everything is not working as it should.The question is: WHAT isn't working as it should? I think our candidates so far are: kwindow framework, allegro, factorio, mutter, and of course could just be me or maybe the problem is simply that the specs of that flag are too ambiguous when it comes to how stuff "should" be working?

Yes, If other WMs use & handle the flag in a more graceful manner, there is absolutely no need to introduce that setting. So, what result do you want or expect for your users when you put up that flag? What is it supposed to do for you / why does Factorio "not want to be rendered offscreen"? Is the WM you use for testing doing what you want or is it simply ignoring the flag?

The main problem for you as I see it would stay the same even with an additional configuration option:
- How does the user find out about the flag in the first place? Can't change the setting if I don't know *why* my hotkeys / task switching / screen magnifier / etc suddenly stopped working...

The main problem in general:
- If I understand the KDE approach correctly, it works like this: "If you need to render directly, you put up that flag, then compositing gets disabled and everything that happens on the screen is your problem until you remove the flag again". This approach - as far as I can tell - should work great for applications that actually want to take care of everything (as in: full-screen, real-time, immersive, make sure nothing interrupts the experience) while they have the flag and give the user an explicit way to get out of that little "jail" (p.E. remove the flag temporarily when game is paused or minimized). Allegro / SDL on the other hand appear to use the flag largely as a good luck charm against potentially crappy graphics drivers because it has fixed something for someone in the past (...probably...) and just keep it turned on, trusting that the WM will still handle everything anyway somehow? Those both seem to me like valid interpretations of the specs... but behaviors derived from those two interpretations don't really mix well...

( *sigh* This looks like it could easily turn into one of those mysterious quantum bugs where it's impossible to define what the problem is and which project it is located in at the same time. )