Good analysis! Your testing confirms that the HDMI connection is physically detected correctly (EDID present and status “connected”), but the display pipeline isn’t working properly. This suggests the issue is deeper in the graphics stack.
Framebuffer Content Monitoring
To monitor if the framebuffer is actually outputting content, you can use these methods:
1. DRM/KMS Status Check
Use the modetest utility to check the actual display pipeline status (1):
apt update && apt install libdrm-tests
modetest -M imx-drm
(1)
This will show you the current mode, whether the CRTC (display controller) is active, and if there are any connected planes.
2. Check Active Display Mode
Verify if Weston has actually set a display mode:
modetest -M imx-drm -c
(1)
Look for the HDMI connector and check if it shows an active mode or if it’s in a disconnected state despite the physical connection.
3. Monitor Weston’s DRM Backend
Check if Weston’s DRM backend is functioning properly by examining the compositor state:
docker exec weston weston-info
(2)
This should show active outputs and their current modes.
Additional Diagnostic Indicators
4. Check GPU/Display Controller Status
Since you’re seeing OpenGL context creation failures, check the GPU status:
cat /sys/kernel/debug/dri/1/clients
cat /sys/kernel/debug/dri/1/gem_names
5. Monitor Display Controller Registers
For the i.MX8, you can check if the display controller is actually outputting:
cat /sys/kernel/debug/clk/clk_summary | grep -i display
This shows if the display clocks are running.
Automated Detection Script
Based on your findings, here’s a detection approach that combines multiple indicators:
#!/bin/bash
# Check if display pipeline is working
EDID_EXISTS=$(find /sys/devices -name "edid" | wc -l)
HDMI_CONNECTED=$(cat /sys/class/drm/*HDMI*/status)
WESTON_RUNNING=$(docker ps --filter "name=weston" --filter "status=running" -q)
# Check if modetest shows active display
ACTIVE_MODE=$(modetest -M imx-drm -c 2>/dev/null | grep -c "HDMI.*connected.*[0-9]x[0-9]")
if [ "$EDID_EXISTS" -gt 0 ] && [ "$HDMI_CONNECTED" = "connected" ] && [ -n "$WESTON_RUNNING" ] && [ "$ACTIVE_MODE" -eq 0 ]; then
echo "Black screen detected - restarting Weston"
docker restart weston
fi
Root Cause Analysis
From your logs and the fact that EDID is present but no display output occurs, this appears to be a timing issue in the display pipeline initialization (3). The OpenGL context warnings you mentioned are likely symptoms, not the cause.
Alternative Solutions
1. Force Mode Setting
Try explicitly setting the display mode in your Weston configuration:
[output]
name=HDMI-A-1
mode=1024x768@60
(2)
2. Use Software Rendering
As a fallback, you can force software rendering to bypass GPU issues:
docker run ... -e WESTON_DISABLE_ATOMIC=1 -e WESTON_USE_PIXMAN=1 ...
(2)
3. Delayed Weston Startup
Add a delay before starting Weston to ensure the display subsystem is fully initialized:
sleep 5 && docker run ...
The most reliable detection method for your case would be checking if modetest shows an active display mode, as this directly indicates whether the display pipeline is functioning regardless of physical connection status.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
