Unable to create a GL context

I migrated from Debian 12 Bookworm to Debian 13 Trixie on Raspberry Pi, libgtk-4-1/stable,now 4.18.6+ds-2 arm64 [installed]

Now I get this running any gtk python app:

Warning: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone’s code. You must ensure an error is NULL before it’s set.
The overwriting error message was: Unable to create a GL context

Here is a minimal example that triggers it:

import sys
import gi
gi.require_version(‘Gtk’, ‘4.0’)
from gi.repository import Gtk

class MainWindow(Gtk.ApplicationWindow):
    def __init__(self, app):
        super().__init__(application=app)

class MinimalApp(Gtk.Application):
    def __init__(self):
        super().__init__(application_id=“com.example.minimal”)

    def do_activate(self):
        self.window = MainWindow(self)
        self.window.present()

def main():
    app = MinimalApp()
    return app.run(sys.argv)

if __name__ == “__main__”:
    exit_code = main()
    sys.exit(exit_code)

Not sure about the GError issue but seems like the GL context message has something to do with OpenGL so I ran the example with GDK_DEBUG=opengl:

EGL API version 1.5 found

* Vendor: Mesa Project
* Version: 1.5
* Device: /dev/dri/renderD128, 226 128
* Client APIs: OpenGL OpenGL_ES
* Extensions:
  EGL_ANDROID_native_fence_sync
  EGL_EXT_buffer_age
  EGL_EXT_config_select_group
  EGL_EXT_image_dma_buf_import
  EGL_EXT_image_dma_buf_import_modifiers
  EGL_EXT_pixel_format_float
  EGL_EXT_present_opaque
  EGL_EXT_surface_compression
  EGL_EXT_swap_buffers_with_damage
  EGL_KHR_cl_event2
  EGL_KHR_config_attribs
  EGL_KHR_context_flush_control
  EGL_KHR_create_context
  EGL_KHR_create_context_no_error
  EGL_KHR_fence_sync
  EGL_KHR_get_all_proc_addresses
  EGL_KHR_gl_colorspace
  EGL_KHR_gl_renderbuffer_image
  EGL_KHR_gl_texture_2D_image
  EGL_KHR_gl_texture_cubemap_image
  EGL_KHR_image_base
  EGL_KHR_no_config_context
  EGL_KHR_reusable_sync
  EGL_KHR_surfaceless_context
  EGL_KHR_swap_buffers_with_damage
  EGL_KHR_wait_sync
  EGL_MESA_configless_context
  EGL_MESA_drm_image
  EGL_MESA_gl_interop
  EGL_MESA_image_dma_buf_export
  EGL_MESA_query_driver
  EGL_MESA_x11_native_visual_id
  EGL_WL_bind_wayland_display
  EGL_WL_create_wayland_buffer_from_image
* Selected fbconfig: R8G8B8A8, depth 0, stencil 0
  high depth: none
  Creating EGL context version 3.0 (debug:no, forward:no, legacy:no, es:yes)
  Creating EGL context version 3.3 (debug:no, forward:no, legacy:no, es:no)
  Creating EGL context version 3.3 (debug:no, forward:no, legacy:yes, es:no)

The applications seems to run correctly but slow to bring up widgets. Any ideas on how to resolve this?

Thanks.

P.S. I should also add that I am running headless so using a VNC server to display the desktop. Since its Raspberry Pi its wayland from what I know.

Ok, I dug into this deeper on some of the Pi forums and I think the underlying trigger is a platform issue and the Trixie available GTK4 release is responding to that.

I ran the example above on a PI3b+ running Bookworm and did not get these messages. The last release of GTK4 on Bookworm was 4.8.3:libgtk-4-1/oldstable,now 4.8.3+ds-2+deb12u1 arm64 [installed,automatic]

I’m in the process of migrating to Trixie so that I can use later release of GTK4, specifically I need the new api introduced for FileDIalog in 4.10. I have only setup test platforms on Pi3b+ and Pizero 2w. Unfortunately, it appears these platforms are not able to provide an OpenGL interface that the most current releases of GTK4 will support or at least that is my conjecture. I have not migrated a PI5 to Trixie yet, but its OPenGL support appears compatible. Here is the info from glxinfo:

Pi3b+

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL version string: 2.1 Mesa 25.0.7-2+rpt3
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 25.0.7-2+rpt3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

PI5:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 3.1
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL core profile version string: 3.1 Mesa 24.2.8-1~bpo12+rpt4
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.1 Mesa 24.2.8-1~bpo12+rpt4
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 24.2.8-1~bpo12+rpt4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
GL_EXT_separate_shader_objects, GL_EXT_shader_implicit_conversions,

PIzero 2w:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL version string: 2.1 Mesa 25.0.7-2+rpt3
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 25.0.7-2+rpt3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

So my questions at this point are:

  1. What GDK_DEBUG settings can I use, if any, to handle these OpenGL environments as best as possible?
  2. What can I do in Python to solve the uninitialized memory problem of GError?

I don’t understand well all these flavors of OpenGL so I have to study that some more. Maybe that will help me come up with something…

I solved the problem by making the symptoms go away:

GSK_RENDERER=vulkan

This link was extremely helpful:

All of the PIs now have some level of vulkan renderer API installed and GTK seems to accept them all. However, not sure if all Pis are actually using the VPU/GPU to implement the API. I suspect that on the “less capable” models like PI 3B+ and PI zero/zero 2 the API just punts to some kind of software rendering. It is what it is…

Details:

PI5 Debian 12:

VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan version 1.3.211, layer version 1:
VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211, layer version 1:

PI3b+ Debian 13:

VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan version 1.4.303, layer version 1:
VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.4.303, layer version 1:

PI Zero 2w Debian 13: Same as the 3B+

Clearly, the future is vulkan

A short update. I completed the migration on Pi5 from bookworm to trixie. This problem does not occur there. The OpenGL versioning under trixie is the same as under bookworm as listed above.

1 Like