As far as I know, Wayland is not using OpenGL but OpenGL ES for 3D rendering, usually used on embedded systems (except for Intel IGPs). In the long term, I read that OpenGL support would be implemented but was not a priority for now.
I guess it is because OpenGL ES is somewhat simpler but it does not seems like a strong point for making such a choice.
I was wondering what were the reasons for this decision, and what were (and would be, for the future of Linux) the consequences of this choice.
The Wayland FAQ was my fist stop before even thinking about asking it here. Feel free to correct me if I am wrong, but the last part seems, at least, not very clear, IMHO:
EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X.
As far as I understand, it's not that simple. EGL is an interface between GLs such as OpenGL and OpenGL ES. OpenGL ES calls are possible directly through Wayland/Weston while OpenGL support needs XWayland.
GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.
So, this part refers to what I was saying above and, as far as I know, Wayland development team does not want to take that alternative route. So, for now, people willing to ports their applications which does not make direct use of Wayland/Weston are forced to translate their OpenGL API calls to OpenGL ES ones.
A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so Weston uses OpenGL ES to render.
This seems understandable, on a short-time basis, at least. Still, on the long run, Wayland devlopment team wants to add OpenGL APIs as well, so it seems more like a workaround for now to me, until things get serious. This is one of the sentences which triggered my question here in the first place.
As detailed above, clients are however free to use whichever rendering API they like.
If I am not mistaken, which means going for XWayland for OpenGL applications and Weston OpenGL ES, which seems to be a bigger deal that what the sentence implies, especially when it comes to 3D rendering, not to mention the fact that Wayland/Weston aim to replace Xorg.
XWayland is a series of patches over the X.Org server codebase that implement an X server running upon the Wayland protocol. The patches are developed and maintained by the Wayland developers for compatibility with X11 applications during the transition to Wayland, and was mainlined in version 1.16 of the X.Org Server in 2014.When a user runs an X application from within Weston, it calls upon XWayland to service the request.
N.B.: I am trying to learn more about Wayland/Weston, especially when it comes to (3D) rendering, but exact information on this subject is diffcult to find, especially because it seems that the only people really X11-savvy seem to be Wayland developers.
As far as I can tell so far, for OpenGL:
- if OpenGL function calls are made through GLX interface, it falls back to XWayland, so the programme is (really) not using Wayland.
It might seems that the discussion is out of the scope of the original question but it is actually linked to underlying OpenGL interfaces/libraries and it is difficult to separate all of this from the original question.
As it seems to be a complicated and confusing subject, here are some various links and quotes which lead me to think that OpenGL (not ES) is not really supported by Wayland per se, but falls back to X11, through XWayland:
The Wayland server in the diagram is Weston with the DRM backend. The server > does its rendering using GL ES 2, which it initialises by calling EGL.
Wayland is actually pretty stable. Nvidia has problem with OpenGL in Xwayland (i.e. 3d accel for x11 apps), otherwise, it should work. There are warts though, when using Wayland. When using scaling (doesn't have to be fractional, either), X11 apps are being upscaled, not downscaled, resulting in blurriness. Unfortunately, neither Firefox nor Chrome does support Wayland natively, and who wants to use their most used app on their computer in blurry mode?
So based on the link @genpfault provided:
So based on the link @genpfault provided:
- XWayland is a part of XOrg that's providing an X server on top of Wayland. Any application that's linked against X11 libs and running under Wayland will automatically use XWayland as its backend. So the GLX part of XWayland is the mechanism that allows GLX-based OpenGL applications to run on Wayland.
- Not being able to use MSAA in GLX-based applications seems to be a known bug of XWayland, at least for Intel and AMD GPUs (cf. https://bugs.freedesktop.org/show_bug.cgi?id=98272 ). But I couldn't find any additional information on the matter.