I couldn’t find a guide that catered to beginners on using OpenGL without glfw or sdl on Linux, so I resurrected my website and wrote one myself featuring zig. I hope it serves as a useful introduction to Wayland and EGL for anyone that has the same drive that I do to see how things work on a deeper level.
11 Likes
A tangential comment, but still - I’ve been playing with OpenGL from Zig, also on Linux, but I have actually been using GLFW and GLAD.
They’re both C, but hey, Zig does work with C swimmingly!
1 Like
Also tangential, but this is one area that Vulkan improved a lot over OpenGL. You just need to request a surface using whatever extension fits your OS. It’s really easy to use Vulkan without depending on anything else, other than the OS itself.
Nice! This will be a useful reference for me in the near future.
I’m actually currently putting the finishing touches on an OpenGL binding generator written in Zig that is fully integrated with the Zig package manager, which will hopefully make using OpenGL in Zig a lot more convenient than using some external tool to generate bindings in advance. Should be up for public consumption in a few days 
2 Likes
I’ve been meaning to explore this in the future, I saw that vulkan had a windowing system interface by default which is very nice! Always nice to see new APIs improve on things.
Having some more type safety with enum definitions and stuff would be super nice, and I hope it’s something you look into! Would have saved me a good chunk of time. Either way, I’d happily update the guide once your generator is ready.
1 Like
hey, so i’m implementing wayland in pure zig (no c libs), and i’m curious if it would be possible to use opengl without the libwayland?
I looked into this when I was writing the articles last year when I was trying to understand the difference between eglCreateWindow and eglCreatePlatformWindow.
I am not sure to be honest, I was able to find the source code for mesa’s EGL implementation and followed the callstack around, but I really don’t remember quite what I gleaned from that as I don’t have any notes. If you want to follow my breadcrumbs though, you can look at where libwayland defines the wl_egl_surface struct and where Mesa implements eglCreatePlatformWindowSurface function.
You can also find the right people to ask by looking at the git blames or at contributors to those projects 
Edit: I looked through the wayland and mesa source code again and I don’t think you need libwayland. You’ll need to create a wl_egl_window according to the layout expected by EGL, but the only wayland specific thing in there is the wl_surface which is a wayland proxy object which I believe is used to make the zwp_linux_dmabuf_v1 requests on the client’s behalf, which you can see happening inside the driver here:
This leads me to believe it is indeed possible to draw with OpenGL in a pure zig library. However, while using the wayland egl extensions is the way you are supposed to use OpenGL with wayland, I think it might not be only way? I have a feeling there might be some way to directly use EGL and the linux dmabuf API to sidestep libwayland? You’d really have to dig into the guts of zwp_linux_dmabuf_v1 and dmabuf to see if that is even possible. Mesa has an example which renders a cube directly using the Linux kernel modesetting API without X11 or wayland, and if you are able to then later share those buffers with a wayland compositor using the dmabuf protocol extension it could work.
thank you for the reply!
here’s what i think also might be relevant: Inter-Process Texture Sharing with DMA-BUF - Blaztinn's Blog
1 Like
Update: @two I looked into libwayland some more, and the wl_surface proxy object being passed into egl does probably create a hard dependency on libwayland; using the zwp_linux_dmabuf_v1 protocol extension would be the way to build a zig-only wayland implementation that is capable of OpenGL rendering. I think there’s a chance though that Nvidia’s implementation of the EGL dmabuf extension might not play nicely with the rest of the ecosystem.