radeon - HDMI Audio fails when "video=..." is set on the kernel command line
linux 6.3.4.arch1-1
When video=...
is set on the kernel command line, then the radeon driver never configures the HDMI audio. This leaves /proc/asound/card1/eld#0.0
completely unconfigured, and HDMI audio becomes unusable. See originally at #1569 (closed)
Normally, video=...
would not be needed on the command line, but the radeon driver may automatically choose an incompatible video mode when using a high-resolution display, and the hardware will then provide no video output. This is the result of a different and unrelated bug. See originally at #1566 (closed)
Also, even without setting video=...
on the kernel command line, if the monitor is turned-off or unplugged, the audio configuration will be disabled, but when the monitor is turned back on or plugged in, the audio configuration remains disabled. Again, HDMI audio becomes unusable. This circumstance may have something to do with X11 and the display manager, where the order of events matters with respect to the DPMS state. This failure occurs when DPMS display is "off" and the monitor is turned off or unplugged - which disables HDMI audio - and then the monitor is turned on or plugged in while DPMS display is still "off". When DPMS display comes back "on", the HDMI audio is not configured. However, if the monitor goes off or is unplugged and then turned back on or plugged in while the DPMS display is "on", the HDMI audio is reconfigured properly.
The radeon driver has more trouble when running without X11. With only a virtual terminal, /proc/asound/card1/eld#0.0
monitor_present
can recognize when the monitor has been turned on after being turned off, but cannot recognize when the monitor has been plugged in after being unplugged.
Regardless, when running with only a virtual terminal, there appears to be no way to trigger detection and configuration of HDMI audio with the radeon driver - sometimes. Sometimes turn-off/turn-on or unplug/re-plug will properly configure /proc/asound/card1/eld#0.0
.
And then, with video=...
on the kernel command line, running with X11 and forcing configuration of HDMI audio by turning the monitor off then on, or unplugging and re-plugging, HDMI audio will still not deliver sound - sometimes.
Using the drm_info
tool, this HD 4000 series card provides 3 Encoders: 2 "TV DAC", and 1 "TMDS". I suspect that when setting video=...
on the kernel command line, the radeon driver blindly configures the wrong encoder, even after a turn-off/turn-on or unplug/re-plug. The irony here is that the driver can clearly discover the existence of an active HDMI audio channel and still fail to configure the TMDS encoder on the associated CRTC.
I have not found any tool which will disclose which encoder is being used with which CRTC, and "encoder" is not a "Property" that can be set on the DVI-I connector.
Sometimes, running and exiting X11 and returning to a virtual terminal will restore HDMI audio with the virtual terminal, sometimes not.
Apparently this restoration of HDMI audio depends upon the state of /proc/asound/card1/eld#0.0
when X11 is started. When "eld_valid" is "0" and starting X11, HDMI audio is not restored, and when "eld_valid" is "1" and starting X11, HDMI audio is restored.
So that is a ritual that will restore HDMI audio with video=...
on the kernel command line - 1) turn-off and turn-on the monitor so that "eld_valid" is "1" before running X11 - unplug/re-plug may not reconfigure /proc/asound/card1/eld#0.0
- and 2) run X11. Of course a proper fix would be preferred.