Hello,
I would like to report a reproducible HDMI hotplug/reconnect failure with Aquamarine 0.11.0 from trixie-backports on a Raspberry Pi 5, together with a controlled A/B test of the upstream fix.
Environment
Hardware:
-
Raspberry Pi 5 / BCM2712
-
arm64
-
Two HDMI displays
Software at the time of the final test:
-
Raspberry Pi OS / Debian trixie-based system
-
Linux 6.18.39+rpt-rpi-2712
-
Hyprland 0.55.2
-
libaquamarine10 0.11.0-2~bpo13+1
Displays:
-
HDMI-A-1: TCL Roku TV
-
HDMI-A-2: PDi monitor
User-visible failure
Both displays initially operate normally.
A reliable real-world reproduction was:
-
Start Hyprland with both displays working.
-
Power the displays off.
-
Leave them off for a period of time.
-
Power them back on.
HDMI-A-2 would commonly remain at "No Signal" immediately after reconnection. HDMI-A-1 could also eventually become unrecoverable.
The Raspberry Pi itself remained alive.
The same Raspberry Pi and display hardware had previously been operated with Sway for approximately 305 days, including repeated display power cycling, without this failure.
Failed-state observations
During a failed HDMI-A-2 reconnect:
/sys/class/drm/card1-HDMI-A-2/status
reported:
connected
while DRM state showed the connector with:
crtc=(null)
and HDMI-A-2 was absent entirely from:
hyprctl monitors all
Further tracing established that:
-
the kernel generated the DRM hotplug notification,
-
Aquamarine/Hyprland received the notification,
-
userspace subsequently issued DRM_IOCTL_MODE_GETCONNECTOR,
-
the kernel returned valid connector/mode information,
-
but no final HDMI-A-2 activation atomic request reached DRM.
This indicated that the kernel was detecting the returned display correctly, but userspace was aborting before requesting its reactivation.
Aquamarine failure
With Aquamarine logging enabled, the failed reconnect produced:
drm: Connector HDMI-A-2 connected
drm: Connecting connector HDMI-A-2, CRTC ID 106
followed by:
[EGL] Command eglQueryDeviceStringEXT errored out with EGL_BAD_PARAMETER
CDRMRenderer(drm): Can't create renderer, no matching devices found
drm: initMgpu: no renderer
drm: Failed to update renderer state for HDMI-A-2 on connect
Following the Aquamarine 0.11.0 source showed that failure of the renderer-state update causes the connector connect() path to abort before the output is successfully made available to Hyprland.
Raspberry Pi DRM/render-node topology
The relevant device topology on this Raspberry Pi 5 is split:
KMS/display device:
/dev/dri/card1
parent approximately:
/sys/devices/platform/axi/axi:gpu
Render device:
/dev/dri/renderD128
parent approximately:
/sys/devices/platform/axi/1002000000.v3d
There is exactly one renderD* device on the system.
Therefore the KMS/display device and V3D rendering device do not have the same immediate parent syspath.
Upstream fix
Aquamarine upstream PR #291:
https://github.com/hyprwm/aquamarine/pull/291
was merged as commit:
f44fecf
https://github.com/hyprwm/aquamarine/commit/f44fecf
The change adds a fallback to the sole renderD node when normal parent-syspath matching fails on a system containing exactly one render node.
Although the upstream report primarily discusses Apple/Asahi split-node hardware, Raspberry Pi 5 has a topology that exercises the same condition.
Controlled A/B test
Rather than installing a newer Aquamarine release, I downloaded the exact Debian source package:
aquamarine 0.11.0-2~bpo13+1
and applied only upstream commit f44fecf.
I rebuilt it locally as:
libaquamarine10 0.11.0-2~bpo13+1+f44fecf1
No other Aquamarine changes were introduced.
Before applying f44fecf, power-cycling HDMI-A-2 repeatedly reproduced:
-
eglQueryDeviceStringEXT failure
-
Can't create renderer, no matching devices found
-
initMgpu: no renderer
-
Failed to update renderer state for HDMI-A-2 on connect
-
HDMI-A-2 absent from Hyprland
-
physical PDi display reporting No Signal
With the same system and only f44fecf added, repeating the same monitor power-cycle produced:
-
HDMI-A-2 present in hyprctl monitors all
-
dpmsStatus: 1
-
disabled: false
-
physical video signal restored to the PDi display
-
the previous HDMI-A-2 renderer-init failure sequence absent from the reconnect capture
Extended validation
The locally patched package has now been in normal operation for approximately five days.
During that period:
-
both displays remained powered off over an entire weekend and recovered normally when powered back on,
-
two additional overnight display-off periods also recovered normally,
-
the original No Signal failure has not recurred.
Before applying the patch, leaving both monitors off overnight was a reliable real-world way of encountering the failure.
Requested action
Could you please consider cherry-picking upstream commit f44fecf into the Aquamarine 0.11.0 package currently shipped by trixie-backports, or otherwise provide the equivalent fix through the backports update path?
The single-commit cherry-pick has been sufficient on this Raspberry Pi 5 and avoids requiring the newer Aquamarine ABI solely to obtain this fix.
I can provide the complete diagnostic logs, DRM state captures, strace evidence, exact package-build procedure, and additional hardware/software information if useful.
Thank you.
Sent with [Proton Mail](https://proton.me/mail/home) secure email.