Consistent GLFW backend detection on hybrid Wayland/X11 systems#210
Consistent GLFW backend detection on hybrid Wayland/X11 systems#210mortacious wants to merge 4 commits into
Conversation
almarklein
left a comment
almarklein
left a comment
There was a problem hiding this comment.
Thanks! Great PR.
I think it makes sense to drop the api_is_wayland flag, and move the logic at the top of the module inside the get_glfw_present_info() function. So we have one clear point where the triage happens. What do you think?
Yes, the import-time checks are actually quite useless now, since they are executed again at runtime anyway. |
…tection to fall back to x11 (xwayland) in case wayland is not available
|
I'll do some tests when I have access to my Linux box soon. |
| if sys.platform.startswith("linux") and SYSTEM_IS_WAYLAND: | ||
| # Force glfw to use X11. Note that this does not work if glfw is already imported. | ||
| if "glfw" not in sys.modules: | ||
| os.environ["PYGLFW_LIBRARY_VARIANT"] = "x11" |
There was a problem hiding this comment.
This change means that with default glfw Python lib installed, on Wayland, the window has no decorations, which would be a regression.
You mentioned the libglfw3 system package. How do you tell pyGLFW to use that system libary, or does that happen automatically?
There was a problem hiding this comment.
The glfw package should choose the appropriate library automatically according to its documentation, although you can force it by setting PYGLFW_LIBRARY_VARIANT. It will also automatically determine which specific .so file to load upon import (on my system, it actually prefers the system library over the locally installed one for some reason). You can also optionally force a specific .so with PYGLFW_LIBRARY.
I've just tested it on my system again, and the window shows the correct decorations in both cases. For safety, I forced the .so to the bundled one in site-packages/glfw/<wayland/x11>/libglfw.so.
Wayland:
X11:
The missing decoration might be an underlying issue with your Wayland compositor. Decorations on Wayland are a frustrating mess at the moment because windows are responsible for drawing their own decorations (server-side decorations like on X11 are not available unless you force the applications into Xwayland), and each implementation does it differently, especially GNOME. This is also the reason why my Wayland window has a different decoration in the screenshot.
There was a problem hiding this comment.
I did apt install libglfw3, but glfw prefers the packaged lib, because it's a newer version (3.4 vs 3.3.10 for libglfw.so.3).
When I force it to use the system glfw, the decorations are ok, but with the packaged glfw the decorations are not there. This is on Ubuntu 24.04 LTS. I think we'll need to force x11 until the lib from glfw itself works properly on Wayland.
My proposal would be to bring back the setting of PYGLFW_LIBRARY_VARIANT, but only if it's not already set and if PYGLFW_LIBRARY is not set. That way we still fall back, but make it easier for users to disable the fallback.
2 participants
On linux systems where the glfw library supports both X11 and Wayland (e.g. the universal
libglfw3package),get_x11_windowandget_x11_displayare present as attributes even when glfw is actually running on the Wayland backend. The old detection logic relied solely onhasattr(glfw, "get_x11_window"), which incorrectly selected the X11 path and caused aTypeError: ...crash becauseget_x11_display()returned None.This replaces the attribute check with a runtime probe of the actual display handles:
get_wayland_display()is called first;get_x11_display()is only called when Wayland returns None. Both calls are wrapped inwarnings.catch_warnings(ignore, GLFWError)to suppress "X11: Platform not initialized" / "Wayland: Platform not initialized" warnings from glfw.