Problem with glx on am62

Technical Support
, ,
1

Hello,

First of all, this is the result of tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.94-7.3.0-g7642ad324113 #1-Torizon SMP PREEMPT Thu Jul  3 08:47:26 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/e54388c03b414f15de5038757766a36da4957b04d84c897e8d44a069401c4dec/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.3.0-build.18
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-am62-15645571
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin AM62 WB on Verdin Development Board
Toradex version:          0075 V1.2A
Serial number:            15645571
Processor arch:           aarch64
------------------------------------------------------------

I’m trying to run an application that uses the JUCE framework on a Verdin AM62 module, but the problem I’m having is that none of the graphical interface elements are drawn inside the window.

I believe I’ve identified the cause — it seems there’s an issue with the graphics server, since when I run the glxinfo command, I get the following response:

# su - torizon -c glxinfo
name of display: :0
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  35
  Current serial number in output stream:  36

Meanwhile, on another module I have (Verdin iMX8M Plus WB), my application works correctly and the glxinfo command returns valid data:

# su - torizon -c glxinfo | head -n 40
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_get_drawable_type, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_ATI_pixel_format_float, GLX_EXT_buffer_age, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_no_config_context, GLX_EXT_swap_control, 
    GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, 
    GLX_NV_float_buffer, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample,

I’d like to clarify that I ran the glxinfo command using the Qt example project (without any modifications from the Torizon IDE Extension template in VS Code) inside the container that runs that application and uses the “Torizon Application Container” qt6-wayland${GPU}.
This was done to ensure that the glxinfo tests couldn’t have been affected by any misconfiguration of the operating system or my Docker containers.

What could be the problem on the AM62 module?

Thank you very much!
Best regards,
Eng. Juan Pablo Ciciarelli

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Graphics Architecture Differences Between AM62 and iMX8M Plus

The issue you’re experiencing with the JUCE framework on the Verdin AM62 is related to the different graphics architectures between the AM62 and iMX8M Plus modules.

Key Differences in Graphics Support

The Verdin AM62 uses a different GPU architecture compared to the iMX8M Plus (1). According to the documentation, both modules support hardware-accelerated graphics, but they use different underlying graphics stacks (2).

Qt Container Selection for AM62

For the Verdin AM62, you should be using the qt6-wayland-am62 container specifically designed for AM62-based modules (3). The documentation states:

These containers provided by Toradex are called qt6-wayland, qt6-wayland-vivante (for the IMX8 modules, that use the Vivante GPU) and qt6-wayland-am62 (for AM62-based modules) (3).

Graphics Backend Requirements

The documentation indicates that Toradex BSPs support Wayland as the graphics backend, and this is particularly important for proper hardware acceleration (2):

Wayland: Supported on i.MX 8 Series modules as well as BSPs starting from 5.0. You should prefer to use Wayland whenever possible (2).

Recommended Solution

  1. Use the correct container: Ensure you’re using qt6-wayland-am62 instead of the generic qt6-wayland or qt6-wayland-vivante containers
  2. Verify Wayland support: The AM62 module should be running applications through Wayland rather than X11/GLX
  3. Check container configuration: Make sure your Docker container is properly configured with the AM62-specific graphics acceleration

Hardware Acceleration Validation

The documentation mentions that Toradex validates OpenGL ES using benchmark applications (2). For the AM62 family, the graphics acceleration should work properly when using the correct container and Wayland backend.

The GLX error you’re seeing suggests the application is trying to use X11/OpenGL instead of the Wayland/OpenGL ES path that’s optimized for the AM62 hardware.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

4

Greetings @jpciciarelli,

I’ve discussed this at length with our team internally. Right now we are not supporting GLX with XWayland. This is consistent with the SoC vendors at NXP and TI, who are just not supporting X in general on their current SoCs that we base our modules off of.

Your application working on the Verdin iMX8M Plus is just a coincidence and not something we actively planned for. Also looking at the glxinfo output on that module it looks like it’s using CPU/software rendering for your application anyways.

If possible I would recommend using other frameworks that don’t rely on GLX/XWayland, as we can’t guarantee that solutions using this will continue to be stable and work.

Best Regards,
Jeremias