X-Less OpenGL on RPi 4?

[Lotharyx]

Hi folks,

I am working with a 2GB Raspberry Pi 4 with the very latest edition of the OS which was shipped with the Pi kit I bought (Debian 10.2, kernel 4.19.75-v7l+).

Long long ago (around the time of the first Pi Zero IIRC), I succeeded in getting GLES functional in a command-line environment without X. Unfortunately, somewhere along the way I lost all that (probably re-imaged the wrong SD card without a backup...). Recently I've started afresh, but things aren't going very well.

It's difficult to make this long story shorter, but ultimately I came across the advice published here, involving combining EGL and dispmanx.

What my problem seems to boil down to is EGL_BAD_NATIVE_WINDOW returned by eglCreateWindowSurface. According to khronos.org, this error "...may be generated if native_window is not a valid window for the same platform as display." If I am honest, I must admit I have almost no idea what that means.

What other info should I provide in order to get help on this?

Thanks in advance!

[dividuum]

The previous closed source driver from the Pi3 and before is no longer usable on the Pi4. OpenGL is now based on Mesa3D and DRM. Both keywords should result in previous discussion about this. Getting a GL context is unfortunately a lot more complex than before. A somewhat complete demo of how GL is initialized is https://gitlab.freedesktop.org/mesa/kmscube/

[Lotharyx]

Thanks for the informative response. Unfortunately, that demo doesn't work on my Pi. It just prints out lots of info about the EGL and GLES environment, and then an error message. The specific error varies based on whether I tell it which device to use. Specifying no device, it ends with "Using modifier ffffffffffffff" and "failed to set mode: Invalid argument":

Code: Select all

$ ./kmscube
Using display 0x1103d88 with EGL version 1.4
===================================
EGL information:
  version: "1.4"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_wayland EGL_EXT_platform_x11 EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless EGL_EXT_platform_device"
  display extensions: "EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_KHR_cl_event2 EGL_KHR_config_attribs 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_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_image_dma_buf_export EGL_MESA_query_driver "
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 3.0 Mesa 19.2.0-rc1"
  shading language version: "OpenGL ES GLSL ES 3.00"
  vendor: "VMware, Inc."
  renderer: "llvmpipe (LLVM 8.0, 128 bits)"
  extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_polygon_offset_clamp GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_OES_texture_stencil8 GL_EXT_blend_func_extended GL_EXT_float_blend GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_OES_EGL_image_external_essl3 GL_EXT_clip_cull_distance GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb GL_MESA_shader_integer_functions GL_EXT_clip_control GL_EXT_texture_compression_bptc GL_KHR_parallel_shader_compile GL_EXT_texture_sRGB_R8 GL_EXT_depth_clamp GL_EXT_texture_query_lod "
===================================
Using modifier ffffffffffffff
failed to set mode: Invalid argument

If I specify the device /dev/dri/card0 (noted in this article on standalone EGL programming), I get nothing but two errors: "drmModeGetResources failed: Invalid argument" and "failed to initialize legacy DRM".

If I specify device /dev/dri/card1, the output is identical (save for the display identifier) to not specifying the device.

Are you (or is anyone) aware of any working examples of GL on the Pi 4 without X? I will continue to tinker, of course, but am always keen to hear of anyone else's successful attempts.

[Lotharyx]

Edit: This post was full of incorrect conclusions. Here's the corrected version.

So it turns out kmscube does work just fine, and using X remotely (via x2go, which is what I'm doing to enjoy CodeLite as an IDE on this project) has nothing to do with it. The secret sauce is that kmscube (and, presumably, any code that is trying to do the same thing) has to be run from the local terminal the first time. That's it. Once that's done, it can be subsequently invoked from a remote command line, either via SSH or through a terminal emulator inside the remote X session, and up pops the cube on the Pi's primary display.

Strange. I'd love to know why it behaves that way, but I don't want to take the time right now to ferret out the answer...

Anyhow, things are working. I've got a GL context that I can scribble on. Thanks for the help!