Window xlib event issue? Solus Linux

[binary1248]

Are you using the library provided through the package or your own self-built library? If you are using the package, can you try to build SFML yourself and test with that?

[victorlevasseur]

I'm using the system packages. I'll try to build SFML 2.3.2 and latest asap.

[tapirath]

Hi,

I'm having the same issue on Gnome 3.20 in arch linux. It happens with every SFML app. I'm using 2.3.2 from the official repos.

[tapirath]

This is definitely an issue from the SFML side, not Gnome. Tested SDL, GLFW and Allegro apps, none of them triggers this.

[tapirath]

After a small research in IRC with the help of a mutter developer I found out below.

* Gnome window manager decides a window is unresponsive if the ping timesout as seen here: https://git.gnome.org/browse/mutter/tree/src/core/display.c#n2210

* A grep to SFML source shows that a pong sent back only in "close event" (if the comments are correct) and only in some special case: https://github.com/SFML/SFML/blob/master/src/SFML/Window/Unix/WindowImplX11.cpp#L1753

Keep in mind I know nothing about this I'm just hoping to narrow down the source of the problem. Please ignore if I'm not making any sense

Should I create a bug report on github?

[Laurent]

There's already one: https://github.com/SFML/SFML/pull/947

Have you read all the information provided there first?

[tapirath]

I didn't actually . From what I see that code went into 2.3.2 and the bug is still there so I'm guessing we need another bug report.

[Laurent]

Are you sure that you're using SFML 2.3.2? Linux repos sometimes have older versions.

[tapirath]

I will check when I have access to my linux machine

[binary1248]

Actually, using master, I can reproduce this every now and then, and only if the window is in fullscreen mode.

The code that sends the pong back to the window manager is exactly identical to how everybody else (SDL, GLFW, etc.) also do it, and yet the window manager doesn't accept ours. It's also strange that this only happens with Gnome and only since recent versions. If I comment out the pong response, other window managers would also flag the application as unresponsive, so the code seems to be doing what it is meant to with other window managers.

I really have no idea what to do at this point. If anybody has contact to some Mutter developers, maybe they can also check if this might be some kind of regression. This is reproducible with the available packages and a really tiny amount of code, so it hopefully shouldn't cost them too much time.

[tapirath]

I will try my luck in IRC.

That being said, I now see that arch linux has CSFML 2.3 in their repos not 2.3.2.

This is now my second time I come across a bug that is fixed in 2.3.2 and turns out I have CSFML 2.3 (the other one was "OpenGL extension SGIS_texture_edge_clamp unavailable" on windows).

The reason for that there is no precompiled binaries for people who uses Windows and there is no source tarball release for 2.3.2 so that distros can pacakge it. It's also extremely easy to mistake 2.3 for 2.3.2 in the website.

So can we get a 2.3.2 CSFML release pretty please  ?

[eXpl0it3r]

The reason there's no package is because there's no 2.3.2 CSFML version. But I'll try and see what needs to be done.

[tapirath]

The reason there's no package is because there's no 2.3.2 CSFML version. But I'll try and see what needs to be done.

Unlike the windows shared libraries CSFML on linux doesn't seem to be statically linked with SFML so eventhough it's 2.3 I was using 2.3.2 effectively since that was the SFML version installed.

To make sure I've installed CSFML and SDML from git. Indeed the same problem persists and not only on fullscreen mode. Windowed mode is also affected. I'll make a new bug report for this.

[eXpl0it3r]

Could you guys test the new bugfix/xlib branch?
If you build SFML yourself, you might notice that the dependencies changed a bit.
Our continues integration system has also create Debian artifacts for the lazy people.