kitty
kitty copied to clipboard
kovidgoyal
OpenGL ES 3: Fail to start on aarch64: [glfw error 65543]
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?
This is installing on a new system. I normally use kitty on an x86 machine with OpenGL, not aarch64 and OpenGL ES 3
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.
Much thanks, my experience with OpenGL is limited. Alacritty has a similar issue FYI, so there might be some important information in that issue https://github.com/alacritty/alacritty/issues/2773
@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
I spent some time trying to implement support in https://github.com/Luflosi/kitty/commit/b692da6fe3b9e79855c3e527de42261b46a13dce 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.
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...
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
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.
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.
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.
I was quickly into testing your commit, but realized I need to include the 20.1 version of mesa with the debug flag in my nix derivation, and since that mesa for me is an overlay, well.. i'm still learning nix. will report back in another week or 2 when I figure out how to do that properly...
I'm just here with a similar issue on Raspberry Pi 4, with 64 bit raspbian, I'll post the error I got here shortly. Have not tried 32 bit just yet. A version of the GLX components was too low to allow kitty to run. I realize 64 bit raspbian is experimental, but I will gather info on the 64 bit enabled, 32 bit userland version as well and report back with glxinfo shortly.
I didn't get the specific error, but the opengl version is less than version 3.3, so kitty won't work on the 64 bit raspbian (raspberry pi OS with 64 bit userland experimental)
@sigkill please read all comments in this issue, they should explain some things.
a solution for this issue would be really helpful to finally utilize kitty on minimalist raspi4 arm64 wayland setups.
right now now kitty doesn't start because of the already reported OpenGL initialisation obstacles, but the very well support GLES 3.1 capabilites of raspberry pi 4 resp. V3D/mesa and on many similar devices should be sufficient for an application like this.
pi@raspberrypi:~ $ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Broadcom (0x14e4)
Device: V3D 4.2 (0xffffffff)
Version: 20.2.0
Accelerated: yes
Video memory: 861MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 4.2
OpenGL version string: 2.1 Mesa 20.2.0
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
Workaround: $ LIBGL_ALWAYS_SOFTWARE=1 kitty It's slower but it works for me on Marjaro/Arch aarch64. I did initially get a strange clipping artifact at the top of the window, but haven't been able to reproduce it and haven't seen it since.
Any status on this, its been a while since anything regarding this was changed. It shoudnt be to hard to add opengl es support, though I dont have the experience to do so.
There is another workaround for the PineBook Pro (and other boards with the same SOC)
You can enable experimental support for OpenGL 3.3 on the GPU. Just add this line: PAN_MESA_DEBUG="gl3" to /etc/envorinment file.
It's working for me, and it's fast. The only thing that's missing is that there is no highlighting when I select text on the terminal.
I have a wired issue on the rapi4 where I can not start kitty on its own or trough lxterminal. But I can start it trough alacritty... I have the OpenGl mismatch too since I also use arrch64 of the Rasbian Build
Questions why the f** does it work when I start it inside of alacritty.
I am also very interested on this, as it's the final obstacle to run this on the Pi4 on Wayland...
@dominikhaid — I see this exact problem on my RPi4 running the current aarch64 release. The desktop icon fails to bring up kitty (though can't see any error even if the desktop-icon enables to run via a terminal). But with lxterminal the error is clear:
lxterminal:
RPi64 » ~
ⓔ ▶︎ kitty --debug-gl
[094 15:44:28.456008] [glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig
[094 15:44:28.456124] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.
alacritty:
RPi64 » ~
ⓔ ▶︎ kitty --debug-gl
GL version string: '4.5 (Core Profile) Mesa 20.3.5' Detected version: 4.5
Alacritty enables V4.5 — using glxinfo it shows the software renderer llvmpipe is responsible for this. Using LIBGL_ALWAYS_SOFTWARE=true kitty although I can't use this method in the .desktop file...
In summary alacritty auto-falls-back to the software path, whereas kitty doesn't.
Sure you can. You can set env vars in .desktop files, or alternately make a launcher script that sets the env var and then runs kitty
Just in case, I also tried to see if OpenGL over Vulkan could work, but no luck (it supports only up to 2.1 as well):
▶︎ MESA_LOADER_DRIVER_OVERRIDE=zink kitty --debug-gl
WARNING: v3dv is neither a complete nor a conformant Vulkan implementation. Testing use only.
[095 12:15:25.456058] [glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig
[095 12:15:25.456236] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.
Hi, I ran into this issue as well. May I ask do we know the exact cause and how to fix yet? 😭 . I'm running aarch64 nixos linux VM on an M1 mac.
@sandangel — did you try setting LIBGL_ALWAYS_SOFTWARE=true in terminal before running kitty?
That works but it seems like a hack. So I just wonder if we have found the root cause yet or not. Is it because of a bug in Kitty or a bug in the system?
Kitty requires a minimal level of OpenGL support which at least the Raspberry Pi 4 does not support, there is no bug here as far as I understand it (read this issue for more details). For an M1 mac I really doubt you're going to have any hardware rendering or compliant OpenGL for years (without open-source devs having to reverse engineer things), blame Apple for either not releasing open-source drivers and forcing their own proprietary GPU system. Now perhaps some sort of OpenGL > Vulkan > Metal shim and some magic to expose that in a VM, but good luck with that...