Wayland support problems

Hi, I’m using GLFW for a small 3D app, which worked like a charm under Windows. I’m currently trying to make it work on an Arch Linux setup, which uses Gnome on Wayland.

As far as GLFW is concerned this is the code I use to create a window:

GLFWwindow* window = glfwCreateWindow(1280, 720, "Test", NULL, NULL);

I tested my code with both the glfw-wayland (3.3.2) package on the Arch repo, and version 3.4.0 of GLFW fetched directly from GitHub and compiled with Wayland flags.

In both cases, when I build and run my code, a black surface of the requested size surrounded by a white-greyish border appears on my screen, but it’s not a window. It’s got no controls, it’s not grabbable, and my error callback also prints an error message which is different depending on the GLFW being used.

When using the Arch package (3.3.2), I get the following:

GLFW error: 0x10008, "Wayland: Focusing a window requires user interaction"

But when I use the GitHub version (3.4.0), I get this:

GLFW error: 0x1000c, "Wayland: The platform does not support setting the input focus"

Am I missing some steps that would be essential to Wayland, or is the Wayland part of GLFW still not to the point it can display windows?

Using an OpenGL 3.0 context was also the only way I got as far as I did. As per glxinfo, I should be able to open an OpenGL 4.2 core context:

deqyra@Arch:/ $ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.2
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 4.2 (Core Profile) Mesa 20.0.7
OpenGL core profile shading language version string: 4.20
OpenGL version string: 3.0 Mesa 20.0.7
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 20.0.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

However, using the following calls:

GLFWwindow* window = glfwCreateWindow(1280, 720, "Test", NULL, NULL);

I get the following error:

GLFW error: 0x10007, "EGL: Failed to create context: Arguments are inconsistent"

The same happened for all OpenGL core contexts between versions 3.2 and 4.2. I know that whenever Wayland is detected, an EGL context is automatically created no matter which hints are provided, but does it make it impossible to open an OpenGL core context?

Thanks in advance.

Update: sorry for the long post, this was probably a noob mistake. I just realised that I was still using an OpenGL loader and not an EGL one (didn’t know there were separate loaders for both). I don’t know if that was the cause of the problem, but it probably didn’t help. I’ll test it and report on what happens then.

Thanks for the update, and apologies for not replying yet - I’m not that familiar with Wayland and it looks like the GLFW Wayland maintainers are busy.

In case you have further problems, a first step would be to run the GLFW examples and tests from a source distribution. If these work you can check out the differences with your own application to help get you to a working state, and then build from there.

@dougbinks Thanks for your reply as well. I did exactly what you suggested and ended up fixing my things. Setting the core profile hint was the one thing that caused EGL to throw errors all over the place. I also found out that my old hardware does not provide debugging output in its supported core profiles, which confused me as to why I wasn’t seeing any actual OpenGL errors. To top it all off I was using the wrong loader.

Crossplatform-ability sure is something you don’t get right at the first time :upside_down_face:

Cheers and thanks for making GLFW awesome :pray:

For whomever that might come across this (not so useful) topic, here is a helpful piece of information: the messages "Wayland: the platform does not support setting the input focus" and "Wayland: focusing a window requires user interaction" are Wayland error messages that are simply reported by GLFW. They also appear when running working code and thy are “non-blocking”, so you might as well ignore them entirely and avoid going down the rabbit hole, for your problem (if any) may reside somewhere else.