Consistent GLFW backend detection on hybrid Wayland/X11 systems#210
Merged
Conversation
almarklein
reviewed
Apr 29, 2026
almarklein
left a comment
Member
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?
Contributor
Author
Yes, the import-time checks are actually quite useless now, since they are executed again at runtime anyway. |
almarklein
reviewed
May 4, 2026
…tection to fall back to x11 (xwayland) in case wayland is not available
almarklein
reviewed
May 14, 2026
Member
|
I'll do some tests when I have access to my Linux box soon. |
almarklein
reviewed
May 15, 2026
almarklein
approved these changes
Jun 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.