bsnes
bsnes copied to clipboard
bsnes-emu
hiro gtk3: Support native Wayland display
Currently, when you build bsnes with hiro=gtk3, it works well enough under X11, but it crashes when run under Wayland. That's because hiro does a lot of things directly via Xlib since GTK2 didn't provide an API for them. Often GTK3 does provide an API for them, but to keep GTK2 and GTK3 supported side-by-side, hiro uses the same Xlib code for both.
You can run bsnes with GTK3 under Wayland if you set GDK_BACKEND=x11 in the environment before running it, and assuming your Wayland compositor has XWayland support enabled (which they probably all do).
This will probably be made more complex by ruby - I think it use Xlib to create a custom window for each video backend and reparents it into whatever window the application is using. That won't work for Wayland, since reparenting isn't a thing there. On the other hand, GTK+3 provides a native OpenGL widget.
Currently hiro/ruby assume that non-Windows and non-macOS is POSIX and X11, but maybe we need another POSIX non-X11 platform for Wayland.
We already have parent window ID in Ruby, no need for reparenting. Though I've never used Wayland, perhaps normal child windows are already a showstopper.
GtkGLArea is quite different from the existing GL and not-GL backends (GTK widgets don't have window IDs; needs gtk_gl_area_attach_buffers() rather than glBindFramebuffer(0) for the actual output, which likely requires an extra copy or some annoying refactoring; the equivalent of glXSwapBuffers seems to be returning from the render signal, which may also require some refactorings).
I recommend using EGL if possible. If not possible, and if GtkGLArea would require too ugly refactorings, a third option would be using the GDK/GL API directly (here's an example on how to use it, though it still seems to have some of GtkGLArea's quirks).
It is my understanding that the correct way to do this in Wayland is with subsurfaces: https://wayland-book.com/surfaces-in-depth/subsurfaces.html
Since on Linux there are only OpenGL 3.2/2.0 drivers outside of X-specific stuff, the GL widget is probably the best choice as it hides these details from you. I have not looked at ruby to determine what's going on there yet.
I believe the GTK3 GL widget only supports core profile, so that would mean deprecating OpenGL 2.0 support for use under Wayland. Correct me if I'm wrong here.
It is my understanding that the correct way to do this in Wayland is with subsurfaces: https://wayland-book.com/surfaces-in-depth/subsurfaces.html
Since on Linux there are only OpenGL 3.2/2.0 drivers outside of X-specific stuff, the GL widget is probably the best choice as it hides these details from you. I have not looked at ruby to determine what's going on there yet.
I believe the GTK3 GL widget only supports core profile, so that would mean deprecating OpenGL 2.0 support for use under Wayland. Correct me if I'm wrong here.
Upstream issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/2619
Hopefully this gets resolved soon (including upstream), as this partially impacts HiDPI support on Plasma Wayland - Xwayland applications appear blurry when on scaled displays.
