glew
glew copied to clipboard
nigels-com
Cannot run glew on wayland
I'm currently working on wayland support in Supertuxkart.
The problem is that I have to compile glew with glx support, because I need fallback for xorg session. I mean, I dynamically check when starting the game if wayland is available. If it's available then I use wayland+egl, if not available then fallback to x11+glx. And for this reason I can't use glew+egl.
On wayland I don't need glx extensions at all. And glXGetProcAddress should work as long as we are linking with x11.
Currently I use patched glew: https://github.com/supertuxkart/stk-code/commit/961ac4d79eda230722d270bbf46f1545b324d0c8
Or I can use glXGetProcAddress/eglGetProcAddress depending on x11/wayland. Doesn't really matter.
Ideally I would like to execute glxewInit as a separate function that doesn't depend on glewInit, or maybe provide a kind of ignore_glx = true parameter to glewInit.
Also people complain that we don't use system glew: https://github.com/supertuxkart/stk-code/pull/3059
I see. So the goal here is use GLEW for OpenGL bindings, but we don't know until runtime if that's in combination with EGL (Wayland) or GLX (not Wayland)? In the glewInit there isn't a runtime way to specify the EGL or the GLX path - it's a compile-time choice. But you're finding that you can use GLEW compiled in default X11/GLX mode providing it doesn't error-out in EGL Wayland mode with no X display?
From a historical perspective I don't think GLEW was intended to support a runtime choice between WGL and GLX, or GLX and Apple. I added EGL support along similar lines, although it's a reasonable thing to have applications that can do Wayland (or not) at runtime.
It doesn't seem like supertuxkart actually needs either EGL or GLX entry-points from GLEW. But ideally there would be more control available via glewInit to initialise via EGL or via GLX, as a runtime choice? Or skip the EGL/GLX/WGL initialisation entirely?
The other aspect is that glXGetProcAddressARB seems to be working fine even in Linux EGL/Wayland mode, rather than eglGetProcAddress. Can you confirm that? (I do have a box with Arty installed, I guess I could give Wayland a try there...)
One option here is to expose glewContextInit as an alternative to glewInit, and indeed for supertuxkart you could declare that manually to bypass the call to glxewInit from glewInit.
That doesn't solve the problem of using the system-installed GLEW, but it does spare you from patching GLEW to fail more gracefully from glxewInit in EGL/Wayland mode. I'd consider bringing glewContextInit into glew.h, but that would take a while to percolate to various distributions as a GLEW 2.2.
Thoughts?
Actually I noticed that current version doesn't crash and it only fails with GLEW_ERROR_NO_GLX_DISPLAY error. So that I can just ignore this error and assume that glewInit is success.
Maybe add something like glewIgnoreGLX = true in the same way as glewExperimental variable? In this way we can check if glew returned GLEW_OK and that everything is loaded properly.
And yes, glXGetProcAddressARB works fine on EGL/Wayland. They say:
GL function pointers returned by glXGetProcAddress are independent of the
currently bound context and may be used by any context which supports the exten-
sion.
I think I'd prefer to add glewContextInit to the interface, than another state variable. That leaves the option open to the application to initialise WGL/GLX/EGL as appropriate. But stops short of supporting either GLX or EGL as a runtime choice. Is Wayland really coming? :-)
It depends on what do you mean by really comming ;) I think that some solutions are too young (stable xdg shell is not supported by compositors yet and you still have to use unstable version) and some issues are not solved yet. For example Gnome still doesn't want allow to use server-side decorations, which affects multiple applications. But I think that it's usable in general.
I was expecting a "Wayland Apocalypse" with Ubuntu 18.04 Bionic, but that didn't come to pass.
In preparation for an upcoming GLEW 2.2.0 - I'm considering simply exposing glewContextInit as an alternative path to glewInit.
I have Ubuntu 18.04 and I'm facing the same situation here. What is the alternative for building, it seems that it lacks some support with GLEW_ERROR_NO_GLX_DISPLAY. Not sure how to handle it though.
We're the team behind Sonic 2 HD and Linux is one of our ports.
@VictorJL I did propose a change for this. Could you take a look and indicate if this might solve your problem? https://github.com/nigels-com/glew/pull/216 Thanks!
glewContextInit is added in the upcoming release. (In master branch now)
If someone is interested, I'm running supertux and supertuxkart on pure wayland, I compiled GLEW as following
sed -i -e 's/-lGL\>/-lGLESv2/' config/Makefile.linux-egl
make SYSTEM=linux-egl
GL bits provided by libglvnd
[2023-11-12 07:42:55-0800] Michel Ganguin:
If someone is interested, I'm running supertux and supertuxkart on pure wayland, I compiled GLEW as following
sed -i -e 's/-lGL>/-lGLESv2/' config/Makefile.linux-egl make SYSTEM=linux-egl
GL bits provided by libglvnd
lGL → lOpenGL makes a lot more sense (it's lGL but without GLX), I wouldn't be surprised that GLES ends up being too limited in some cases.
