-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenGL context error on Ubuntu 22.04.2 in wayland session #81
Comments
Whoa, this is not great! I don't know why the new version wouldn't work. |
Figured it out! It is actually an ubuntu issue: after upgrading to 22, ubuntu was using Wayland by default. After switching back to Xorg, I can use the latest PyOpenGL without error. Some useful issues for context over on pygame: It's interesting that it works at all with PyOpenGL==3.1.5. Might indicate a bug in PyOpenGL? Or that I need to setup my environment a little more carefully? I'll keep digging but I'd say this is a little less critical than it appeared at first. |
This only makes me feel worse about it! 😄 I hope we can figure out how to address this, as Linux is usually one of the more reliable deployment environments for OpenGL stuff lately, if I am remembering correctly. |
well it seems pyopengl has had some trouble in detecting Wayland vs Xorg in the past (https://sourceforge.net/p/pyopengl/mailman/message/36989497/): Wayland needs to use egl. I'll see if adjusting some environment variables helps... |
OK, so I think I've narrowed this down a bit. pyglet on it's own is OK on wayland (cause it'll use the xwayland forwarding/wrapping even though it doesnt have native wayland support). The problem is coming in the imgui-pyglet integration. imgui's example, https://github.com/pyimgui/pyimgui/blob/master/doc/examples/integrations_pyglet.py , crashes with the same error message above when I'm logged into a wayland session AND have PyOpenGL > 3.1.5. Pinning PyOpenGL to 3.1.5 on wayland OR using an xorg session (with any version of PyOpenGL) works. So I think this is enough to ask upstream in pyimgui. |
An issue already exists! pyimgui/pyimgui#318 the second comment notes that it also errors for pyglet. |
Ok, found a potential fix: explicitly telling PyOpenGL what to use seems to work. After setting the following environment variable
I can run our examples in a Wayland session with the latest PyOpenGL. @matthewturk , I think I'll just add a note to the installation instructions recommending to either set this environment variable or run yt_idv in an xorg session. We could also try setting the environemnt variable on initial import of yt_idv via |
hmm. Can you take a look at what is going wrong with |
well I don't think anything is going wrong with yt_idv's selection. We still want the pyglet default. What I think is happening: pyglet doesnt support wayland (yet?) and when I run a standalone pyglet app, it somehow tells PyOpenGL to use glx, not wayland without me having to set any environment variables. But for some reason when running pyimgui-pyglet, pyglet still needs glx, but PyOpenGL thinks it's OK to use a different session type and I need to set this environment variable to enforce that. |
Edit (Summary)
Summarizing this thread: recent versions of Ubuntu have switched to using the Wayland graphics protocol by default (from Xorg). At present, pyglet does not support Wayland. While using pyglet on its own still works (thanks to xWayland), using pyimgui-pyglet results in PyOpenGL selecting the incorrect graphics backend. Forcing PyOpenGL to use Xorg solves this (
$ export PYOPENGL_PLATFORM='glx'
). Alternatively, you can select an Xorg session on the Ubuntu login screen.Original:
Just created a new yt_idv environment with python 3.9.16 on ubuntu 22.04.2, installed everything and got the following error trying to run
examples/amr_volume_rendering.py
:I noticed that our test requirements pin PyOpenGL to 3.1.5, so I downgraded and that fixed the error. Should we be pinning PyOpenGL in
setup.cfg
? It currently specifiespyOpenGL>=3.1.5
. Note that I first downgraded from 3.1.7 to 3.1.6 and still got the error before downgrading again to 3.1.5.The text was updated successfully, but these errors were encountered: