Package: libaquamarine10 Version: 0.11.0-2~bpo13+1 Severity: important Tags: fixed-upstream
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.
