OpenGL ES 3: Fail to start on aarch64: [glfw error 65543]

[tgunnoe]

Describe the bug
Fails to start

To Reproduce
$ kitty

Expected behavior
Startup

Screenshots

[175 14:38:59.616720] [glfw error 65543]: EGL: Failed to create context: Arguments are inconsistent
[175 14:38:59.621982] Traceback (most recent call last):
  File "/nix/store/b9zhn4izh0c2xnhxk94s4rqshzc8jwr8-kitty-0.16.0/bin/../lib/kitty/kitty/main.py", line 351, in main
    _main()
  File "/nix/store/b9zhn4izh0c2xnhxk94s4rqshzc8jwr8-kitty-0.16.0/bin/../lib/kitty/kitty/main.py", line 344, in _main
    run_app(opts, args, bad_lines)
  File "/nix/store/b9zhn4izh0c2xnhxk94s4rqshzc8jwr8-kitty-0.16.0/bin/../lib/kitty/kitty/main.py", line 145, in run_app
    _run_app(opts, args, bad_lines)
  File "/nix/store/b9zhn4izh0c2xnhxk94s4rqshzc8jwr8-kitty-0.16.0/bin/../lib/kitty/kitty/main.py", line 129, in _run_app
    args.cls or appname, load_all_shaders)
ValueError: Failed to create GLFWwindow

Environment details
OS: NixOS 20.03 aarch64
on Pinebook Pro
RK-3399 and Mali-T860
Panfrost on Mesa 20.1, experimental OpenGL ES 3.0 support

 $ env PAN_MESA_DEBUG=gles3 glxinfo | grep OpenGL                            

OpenGL vendor string: Panfrost
OpenGL renderer string: Mali T860 (Panfrost)
OpenGL version string: 2.1 Mesa 20.1.0
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 20.1.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Output of kitty --debug-config

kitty 0.16.0 created by Kovid Goyal
Linux gammu 5.6.0 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 aarch64
<<< Welcome to NixOS 20.03.2262.2b417708c28 (\m) - \l >>>

Run `nixos-help` for the NixOS manual.
Running under: Wayland

Config options different from defaults:

Additional context

Is OpenGL ES 3.0 not enough to support kitty? If this isnt a bug, should there not be errors here?

[Luflosi]

Is this crash new? Did previous versions of kitty work?

[tgunnoe]

This is installing on a new system. I normally use kitty on an x86 machine with OpenGL, not aarch64 and OpenGL ES 3

[Luflosi]

I'm not sure if OpenGL ES is supported but if it's not, I would imagine, that it wouldn't be too difficult to support considering that OpenGL ES 3.0 is similar to OpenGL 3.3, which is supported.
There is a very similar issue where the author of that issue only had OpenGL 2.1 available and kitty printed basically the same error message. @kovidgoyal wondered, why kitty wasn't printing an error message about the low version number, even though such a check exists. The reason for this is, that the check happens in gl_init(), which is called after the failing function glfwCreateWindow(). Maybe there is a way to somehow move that check up a couple lines.
I'll dig around in the code some more, maybe I'll find something.

[tgunnoe]

Much thanks, my experience with OpenGL is limited. Alacritty has a similar issue FYI, so there might be some important information in that issue alacritty/alacritty#2773

[kovidgoyal]

@Luflosi that check cannot be moved up, since glad requires a current OpenGL context to load. As for the actual issue, it might be possible to support OpenGL ES 3, but it would require someone with the hardware to contribute code and test things. To start with you will want to set the glfw context creation hint to use opengl ES. https://www.glfw.org/docs/3.3/window_guide.html#window_hints_ctx

[Luflosi]

I spent some time trying to implement support in Luflosi@b692da6 but I got stuck trying to replace glTexStorage3D with glTexImage3D, which I couldn't get to work for some reason. I posted the link to this commit in case anybody is interested in continuing this in the future.

[Luflosi]

Maybe it did work correctly but I got stuck after that. Keep in mind that I don't really know OpenGL, which doesn't exactly make this easier...

[tgunnoe]

I am definitely interested in trying this out more. I will test out that commit and build on it if I can and report back!
So I assume you have GLES3 hardware available?
Thanks @Luflosi

[Luflosi]

I don't have any special hardware. I ran kitty in an LXC container on my server since I'm using macOS as my desktop OS, which only supports the non-ES version of OpenGL. When I execute the unmodified kitty with kitty --debug-gl, I get GL version string: '3.3 (Core Profile) Mesa 20.1.1' Detected version: 3.3. If you look in my commit above, you can see that I replaced GLFW_OPENGL_API with GLFW_OPENGL_ES_API (since I couldn't be bothered to use the GLFW init hints, which is the intended way of doing this). When running kitty with my modifications, kitty --debug-gl prints GL version string: 'OpenGL ES 3.1 Mesa 20.1.1' Detected version: 3.1. So apparently, Mesa just automatically handles this.
I read that the Raspberry Pi 4 supports OpenGL ES 3.0, so it might be fun to try to get kitty to run there.

[tindzk]

Thanks for looking into it, @Luflosi. I would like to use Kitty on my Raspberry Pi 4 which supports OpenGL ES 3.1. I have tried your branch and got the following error:

$ /kitty/launcher/kitty --debug-gl
GL version string: 'OpenGL ES 3.1 Mesa 20.1.1' Detected version: 3.1
[191 11:08:30.587974] OpenGL error: This operation is invalid (GL_INVALID_OPERATION) (calling function: glTexSubImage3D)

The function gets called in send_sprite_to_gpu().

It looks like glTexSubImage3D does not support GL_UNSIGNED_INT_8_8_8_8 in OpenGL ES. The error vanishes when I change it to GL_UNSIGNED_BYTE, but the terminal window still does not render any glyphs.

[Luflosi]

I also got a Raspberry Pi 4 a couple days ago. I might try to get kitty to run on it but don't hold your breath.