Hmm - which function in that path actually selects and sets the display mode? And, which function actually selects and sets the encoder used?
I expect that, HDMI audio cannot even be detected unless a "TMDS" encoder has been selected. Maybe the radeon driver selecting the wrong mode is related to the driver selecting the wrong encoder.
The linux Virtual Terminal, which is, as far as I know, a necessary precursor, and so effectively, a fundamental component, for running any userspace application able to access or control a directly connected video display device, is not itself a userspace application in the sense that it is a device driver running from within, as a part of, the linux kernel.
Additionally, reviewing the source for the linux Virtual Terminal under drivers/tty/vt, there is no direct reference there to DRM_IOCTL_MODE_GETCONNECTOR
, connector->funcs->fill_modes()
, drm_helper_probe_single_connector_modes()
, or to mode_valid()
, nor is there any reference at all to "DRM".
To your example, then, what userspace application is selecting the video display mode being used by the linux Virtual Terminal?
the kernel driver already tells userspace that it is not capable of using that mode when userspace asks it to validate what modes it supports
I know of no tool, and am not aware of any tool having been suggested, which would allow userspace to inspect or discover which modes the radeon driver, in association with some particular video hardware device, will or will not support. Nor am I aware of any information published by ATI/AMD which discloses the limits imposed by the radeon driver upon some particular video hardware device.
Currently, the only techniques I have available to discover the display mode limits imposed by the radeon driver are 1) direct email to ATI/AMD staff regarding specific hardware, and 2) trial and error.
Please provide an example to support the assertion that the radeon driver already tells userspace that some specific display mode is or is not supported.
Please read-through my most recent edit above. I think that the basic problem is the radeon driver blindly choosing an incompatible encoder for the CRTC and associated DVI-I connector. This should be fixed.
I'm wondering if a better solution might be customizing your EDID to pull out the bad resolution for your monitor.
That is a matter of the other bug, #1566 (closed) . Here, a 4k TV is being used with a 4000 series card that apparently marketing did not want running at 4k resolution. Editing the 4k TV EDID to remove the 4k modes is not a reasonable work-around. The radeon driver should be fixed so that it does not select a mode that it will not support. Yes, 4k displays did not exist when the 4000 series was first released, but times have changed.
The issue with the state of DPMS is an annoying quirk, but not a show-stopper.
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
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
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.
The problem here is the consequence of the driver not selecting a mode that is actually compatible with the hard-coded driver limits. One part of the code selects the wrong mode, and another part of the code disables the hardware, based upon undocumented hard-coded hardware limits. The reason that this bug has not been fixed is simply because AMD staff have not addressed the problem. You might look to the above https://bugzilla.kernel.org/show_bug.cgi?id=172421 and patch the driver yourself, or instead, manually select a mode that is compatible with the imposed driver limits, "blind", using a start-up script or from a remote terminal. Another option is to set video=...
on the kernel command line, but this can lead to the HDMI audio failing, which is a different bug.
The driver's detect needs to run to run to detect the displays capabilities.
And yet, it does not run, when forcing the mode via the command line.
... forcing the mode via the command line skips the driver's detect routine ...
And then clearly, that is broken behavior that needs to be fixed.
Is this fault in the video driver? Or, in the eld code?
I have applied the two patches
0001-drm-radeon-Add-HD-audio-component-notifier-support-v4.patch
0001-drm-radeon-Use-a-local-mutex-for-bind-unbind-protect.patch
to the kernel from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-6.1-rc2.tar.gz
compiled and booted, including
video=DVI-I-1:1920x1080D
in the kernel command line.
I still see:
$ cat /proc/asound/card1/eld#0.0
monitor_present 0
eld_valid 0
codec_pin_nid 0x3
codec_dev_id 0x0
codec_cvt_nid 0x0
the same as in the original problem description.
These patches have done nothing to resolve the problem in the original bug report.
It appears still that there is nothing which actually calls radeon_audio_detect().
I tried commenting-out libpipewire-module-x11-bell in /etc/pipewire/pipewire.conf and then killall wireplumber pipewire-pulse pipewire ; pw-cli load-module libpipewire-module-x11-bell
, but then pw-cli list-objects|grep libpipewire-module
does not show libpipewire-module-x11-bell as loaded.
I tried re-enabling libpipewire-module-x11-bell in pipewire.conf again and restarting pipewire, but then activating the terminal bell just locks-up the terminal and the entire display for about a minute, without playing any sound, and sound stops working altogether, from any source.
Disabling libpipewire-module-x11-bell in pipewire.conf and restarting, sound works normally again.
I probably don't understand what libpipewire-module-x11-bell is supposed to be doing here, or it's misconfigured. Does the module have working defaults when the args = {...}
list is empty? Or some args are required?
Yes, still an issue.
Log-in on a terminal, and pipewire will fail to start if it attempts to load libpipewire-module-x11-bell.
The log has:
systemd[1]: Started User Manager for UID 1000.
...
systemd[846]: Started PipeWire Multimedia Service.
pipewire[871]: mod.x11-bell: XOpenDisplay() failed
pipewire[871]: pw.conf: 0x55a3ee6550c0: could not load mandatory module "libpipewire-module-x11-bell": Input/output error
pipewire[871]: default: failed to create context: Input/output error
systemd[846]: pipewire.service: Main process exited, code=exited, status=251/n/a
systemd[846]: pipewire.service: Failed with result 'exit-code'.
Pipewire can be restarted manually after starting Xorg, but this is quite annoying, and still, pipewire will not be available when using just the linux virtual terminal.
Of course, it is also possible to just run pipewire without libpipewire-module-x11-bell, but then that defeats the whole purpose of having the module in the first place.
So, it seems that libpipewire-module-x11-bell is pretty poorly thought-out.
Is there some way to have libpipewire-module-x11-bell load successfully without Xorg running, and still attach whatever after Xorg starts?
@lestcape dmesg shows no "video=..." option on the kernel command line, so we can ignore that as a possible factor.
And you still have "eld_valid 0", so your HDMI audio is still not working, I expect.
I see that your LG TV has an "Is the input connected to your PC?" setting, which might disable the HDMI sound and select the stereo audio inputs instead, if set to "Yes". I can only wonder. You may want to make sure that that setting is "No".
You might install "get-edid" and "edid-decode", run "sudo get-edid | edid-decode", and make sure that you see "Speaker Allocation Data Block: FL/FR ...".
You might try "systool -vm radeon" and make sure you have 'audio = "1"'. If not, try creating "/etc/modprobe.d/radeon.conf" with "options radeon audio=1" and reboot.
You might try "lsmod|grep snd", and make sure you see "snd_hda_codec_hdmi". Actually, looking through your dmesg file, we see: "snd_hda_codec_hdmi hdaudioC2D0: HDMI ATI/AMD: no speaker allocation for ELD".
You might look at the parameters from "modinfo snd-hda-codec-hdmi", and play with the configuration. Create an "/etc/modprobe.d/snd-hda-codec-hdmi.conf" if you find something that helps. See this bug from 2015 with this same radeon driver "no speaker allocation for ELD" problem: https://bugs.freedesktop.org/show_bug.cgi?id=90777 One person had some luck setting "options snd-hda-codec-hdmi static_hdmi_pcm=1".
That's all I have for the moment. See if any of that sheds light on the problem.
Alex, I'm not sure that you are quite understanding the audio problem, as I am seeing it. As best as I can tell, the audio problem is not about configuration of the radeon hardware - ELD or not - but instead, about whether or not the alsa driver is properly informed that the radeon audio hardware even exists. The result is that, either /proc/asound/card1/eld#0.0 says:
monitor_present 0
eld_valid 0
and HDMI audio fails, or, it shows:
monitor_present 1
eld_valid 1
...
showing the complete HDMI audio interface, and everything works normally.
It seems that, until something calls radeon_audio_detect(), the radeon HDMI audio is jut not going to work. After that, if alsa doesn't know about the HDMI audio, there is nothing that pulseaudio or pipewire can do about it.
And, unfortunately, the seemingly distinct issue with properly selecting a working display resolution also appears to interact with the process of informing the alsa driver under some circumstances, and vice versa. For instance, a command like "xrandr --display :0 --output HDMI-0 --set audio on" can disable the display completely, leaving only a black screen - and won't help with audio anyway.
From my testing, Iwai's HD audio patch does nothing to change the situation, one way or the other. That wasn't its purpose. I can only guess that your reluctance to accept Iwai's patch might be the reason that he no longer contributes to this thread, since his efforts have been ignored. We need his help here - though from what I can tell, the radeon driver is "doing the wrong thing", not running radeon_audio_detect() - as well as "doing the wrong thing" selecting a 4k resolution in a driver hard-coded to disallow a 4k configuration.
Still, at this point, I cannot tell whether Lester is, or is not, still having a problem with his HDMI audio - or whether his kernel is, or is not, trying to force "video=..." with KMS.
It may be that, through trial and error, everyone eventually finds some kind of annoying workaround when using the radeon driver.
Hmm - I need to get oriented here. You did not say whether or not you were running your kernel with or without the "video=..." command line option. You did not say what type of display you are wanting to send HDMI audio. Also, if you have a workaround with pulseaudio that is not working with pipewire, could you just revert to using pulseaudio?
Yes, I looked-over your references. You may notice that Christian Koenig has not participated in this conversation at all. You might want to look through https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/high-definition-audio-multi-stream.pdf
Christian claims that "The hardware we are talking about here doesn't have ELD support at all. So no ELD pass-through or unsolicited event when something is connected. You basically have to setup the capabilities in the applications manually." However, he fails to suggest a method to trigger this ELD read event manually. He then says "I mean it would be great to get this cleaned up, but you need to take care all those nasty corner cases not supported by ELD", a sad example of "the perfect being the enemy of the good".
Now, in my situation, using the radeon driver on an HD 4350, I noticed that a "mysterious something" was able to trigger an ELD read, after which, even having forced the video mode from the kernel command line, the audio would work perfectly well. However, I was not able to find a set of circumstances that would allow me to identify this "mysterious something", and I have not been able to persuade Alex or Iwai to help me understand what bit of the driver code actually calls the ELD read routines. I was also a bit discouraged trying to read their code after noticing that the radeon driver would call some simple status reporting function literally hundreds of times, for seemingly no reason, while still, never calling the ELD read routine.
I don't know which way you want to go here. Do you want to try to understand the kernel DRM and radeon driver code, and create a software patch? Do you want to try and engage Christian into the conversation? Do you think you could get Alex or Iwai to help us understand how the ELD read gets triggered, or how it might be triggered manually? I found an annoying but functional workaround for my own audio problem, while running Xorg, so I am less motivated, deciphering the radeon driver. Maybe you could get more people asking for help with audio problems on old radeon hardware?
This issue has nothing to do with pipewire or pulseaudio, and instead, is a combination of a "not robust" audio driver and a "not robust" video driver. The radeon driver is unable to configure itself properly when a 4k display is attached, and the audio automatic configuration does not seem to always work properly with the kernel DRM.
Either the display display resolution can be forced with "video=DVI-I-1:1920x1080e", which will break the audio, for reasons that are not clear, or the audio will work and the display is disabled when attached to a 4k display. At least, when running Xorg, the display can be recovered with xrandr, leaving the audio working, but the virtual terminals will be disabled.
Do you have any "video=..." in your kernel command line? If so, you could try removing that and see if audio comes back. Not much help from Alex and Iwai because radeon and amdgpu are older drivers.
X.Org X Server 1.21.1.3
one radeon card and one nvidia card
Run Xorg with "-layout server0" command line switch
Explicitly, Serverlayout server0 -> screen0 -> device0 - 'Driver "radeon", BusID "PCI:2"' and Serverlayout server1 -> screen1 -> device1 - 'Driver "nvidia", BusID "PCI:3"'.
In the log, both radeon and nvidia drivers are loaded, which does not seem to be a problem in itself. But then, nonetheless:
...
[ 214.260] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_33
[ 214.262] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 214.262] (II) Platform probe for /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.0/drm/card0
[ 214.263] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[ 214.263] (II) xfree86: Adding drm device (/dev/dri/card1)
[ 214.263] (II) Platform probe for /sys/devices/pci0000:00/0000:00:07.0/0000:03:00.0/drm/card1
[ 214.264] (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 12 paused 0
[ 214.270] (**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/xorg/modules"
[ 214.275] (--) PCI:*(2@0:0:0) 1002:68d9:103c:6872 rev 0, Mem @ 0xc0000000/268435456, 0xf9fc0000/131072, I/O @ 0x00009000/256, BIOS @ 0x????????/131072
[ 214.275] (--) PCI: (3@0:0:0) 10de:0df8:10de:0835 rev 161, Mem @ 0xfa000000/16777216, 0xd8000000/134217728, 0xd6000000/33554432, I/O @ 0x0000ac00/128, BIOS @ 0x????????/524288
[ 214.276] (II) Open ACPI successful (/var/run/acpid.socket)
[ 214.276] (II) LoadModule: "glx"
- then, the wrong glx module is loaded -
[ 214.276] (II) Loading /usr/lib/nvidia/xorg/libglx.so
[ 214.282] (II) Module glx: vendor="NVIDIA Corporation"
...
Xorg has loaded the nvidia glx module, not the glx module for the radeon driver, despite the command line layout switch and xorg.conf explicit configuration, referencing only the radeon driver for this layout. Later in the log, there is:
[ 214.671] (II) Initializing extension GLX
[ 214.671] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
But it is too late. The wrong glx module has already been loaded.
Note the Marker, "(**) from config file", for the log entry 'OutputClass "nvidia" ModulePath extended to ...', but "man 5 xorg.conf" simply references OutputClass as "automatically added". Since only the radeon gpu is referenced in this layout, this incorporation of 'OutputClass "nvidia"' here seems to be a bug.
It is possible to force the correct behavior by adding an explicit "-modulepath /usr/lib/xorg/modules" command line switch to this instance of Xorg - but, this seems like a workaround for a bug.
Setting Serverflags Options "NoAutoAddGPU" and "NoAutoBindGPU" makes no difference here.
And consequently, glx fails:
$ glxinfo
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig
Incidentally, with two instances of Xorg, one on the radeon driver and one on the nvidia driver, running xrandr on the radeon display lists only the connectors for the radeon card, but running xrandr on the nvidia display lists the connectors for both cards, again, despite the explicit configuration, and the radeon display being completely separate and distinct.
Is all this "intended" behavior for the Xorg server? Or, are these bugs?
It has become apparent that we are dealing with two different problems here, one effecting the hdmi audio, and the other effecting the selection of a valid video mode. I would prefer that we address these each distinctly, one at a time. Since the original symptom was with respect to the hdmi audio configuration, let us resolve that problem first.
We can see that, regardless of the manner of configuration, the edid must be examined for the eld, and the eld communicated to the alsa driver. It makes no difference that the hdmi was configured with video=DVI-I-1:1920x1080e and the radeon driver then makes a digital connection but reports the wrong encoder, or the hdmi was properly configured with video=DVI-I-1:1920x1080D and the radeon driver reports the correct encoder, or if the hdmi connection is configured automatically, and an invalid video mode is selected. In all cases, the hdmi audio must still be properly configured.
As it is now, when any version of the "video=" kernel command line parameter is used, hdmi audio configuration fails. It appears that this hdmi audio configuration process runs through radeon_audio_init(), which itself may be called from several different places, depending upon the specific GPU being used.
How do we make certain that radeon_audio_init() is run, regardless of the existence of the "video=" parameter?
Let's get a fix for this, and mainstream it, and then we can go back and look at the video mode selection process.
@agd5f It seems pretty obvious now that the radeon driver failed to anticipate a monitor having a higher hdmi maximum clock frequency than the card itself. The result now, is that, on boot, either video can be forced to work, or audio works, but not both at the same time. I cannot find any mechanism to force a virtual terminal video mode change after boot.
Alex, do you have a patch to resolve this issue?
Also, can you comment on what about the drm "video=" design with respect to "e" and "D"? This provision for both an "e" and "D" appears to be a mistake, without some degree of sanity checking by the video driver and clear error reporting in the log:
Documentation/fb/modedb.rst
DRM drivers also add options to enable or disable outputs:
'e' will force the display to be enabled, i.e. it will override the detection
if a display is connected. 'D' will force the display to be enabled and use
digital output. This is useful for outputs that have both analog and digital
signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
is specified the output is disabled.
@tiwai Takashi, what about this "video=" setting with respect to the alsa hdmi driver? Is it reasonable to expect that the alsa driver should still be configured properly when the kernel command line "video=" parameter is used?
And, is the hdmi audio configuration working the way you want when the "video=" parameter is not used?
Yes, and yes, so far. The hex modeline IDs, reported by xrandr, are assigned different values, with and without the "video=DVI-I-1:1920x1080e", though, and the script I use to correct the display mode then has to be changed.
I also looked again at Documentation/fb/modedb.rst, "modedb default video mode support", which has:
DRM drivers also add options to enable or disable outputs:
'e' will force the display to be enabled, i.e. it will override the detection
if a display is connected. 'D' will force the display to be enabled and use
digital output. This is useful for outputs that have both analog and digital
signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
is specified the output is disabled.
Apparently, I should have used "video=DVI-I-1:1920x1080D", instead of "video=DVI-I-1:1920x1080e" on the kernel command line.
Interestingly, using "D", instead of "e", the dmesg log shows that, now, the correct encoder is selected, but that still, both radeon_dvi_detect() and radeon_audio_detect() are never called, and radeon_audio_component_get_eld() still fails to configure the hdmi audio and populate /proc/asound/card1/eld#0.0 , because radeon_encoder_atom_dig->pin == 0
, and audio configuration is skipped.
Running aplay will again trigger the call to radeon_audio_component_get_eld(), but the behavior is no different, and audio will still fail.
The dmesg log, using "video=DVI-I-1:1920x1080D", is attached for comparison: dmesg_log_V_D
Ha! Yes! Or, yes and no. On one hand, in the log, there is conspicuously, for instance:
[ 2.689011] radeon_dvi_encoder : drm_connector = DVI-I-1
[ 2.689012] radeon_dvi_encoder : encoder->encoder_type ==DRM_MODE_ENCODER_TMDS : return drm_encoder = TMDS-50
[ 2.689013] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CONNECTOR:49:DVI-I-1] to [CRTC:42:crtc-0]
and /proc/asound/card1/eld#0.0 is correctly populated, with:
monitor_present 1
eld_valid 1
...
Also, both radeon_dvi_detect() and radeon_audio_detect() are called, with my printk's showing, for instance:
[ 7.200874] radeon_dvi_detect : drm_connector = DVI-I-1
...
[ 7.281318] radeon_audio_detect : drm_connector = DVI-I-1 : drm_encoder = TMDS-50
and also:
[ 2.689012] radeon_dvi_encoder : encoder->encoder_type ==DRM_MODE_ENCODER_TMDS : return drm_encoder = TMDS-50
...
[ 20.936090] radeon_dvi_encoder : encoder->encoder_type ==DRM_MODE_ENCODER_TMDS : return drm_encoder = TMDS-50
[ 20.941553] radeon_audio_component_get_eld : encoder = TMDS-50 : proceed
...
[ 20.974764] radeon_audio_component_get_eld : drm_eld_size = 40 : Enabled
On the other hand, there is no display, since there is also:
[ 39.878691] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:49:DVI-I-1] probed modes :
[ 39.878712] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48 0x5
[ 39.878749] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
[ 39.878787] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 593407 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
[ 39.878824] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
[ 39.878861] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
...
and these enabled modes are using prohibited clock frequencies. Obviously, still a problem there, not having video.
Starting Xorg bypasses the broken virtual terminal video, but even then, Xorg made a surprisingly bad choice, with xrandr showing "1920x1080i (0x64) 74.250MHz +HSync +VSync Interlace *current". I don't know why Xorg didn't start with one of the invalid 600MHz clock modes there, but also a problem, either way, clock too high or too low.
Attaching the dmesg log: dmesg_log_V_4
It would appear that radeon_audio_detect() either never gets called or never sets up the audio. Can you you figure out why that is the case? Start with radeon_dvi_detect().
Quickly adding some printk's to radeon_dvi_detect(), radeon_dvi_encoder(), and radeon_audio_detect(), from boot to login, radeon_dvi_detect() and radeon_audio_detect() are never called.
However, radeon_dvi_encoder() is called after drm_crtc_helper_set_config():
[ 4.488387] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CRTC:42:crtc-0] [FB:51] #connectors=1 (x y) (0 0)
[ 4.488408] radeon_dvi_encoder : drm_connector = DVI-I-1
[ 4.488409] radeon_dvi_encoder : encoder->encoder_type !=DRM_MODE_ENCODER_TMDS : return drm_encoder = TV-48
[ 4.490279] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CONNECTOR:49:DVI-I-1] to [CRTC:42:crtc-0]
[ 4.492174] [drm:drm_crtc_helper_set_config [drm_kms_helper]]
[ 4.492192] [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CRTC:44:crtc-1] [NOFB]
and in the midst of calls to radeon_audio_component_get_eld():
...
[ 20.091324] radeon_audio_component_get_eld : list_for_each_entry()
[ 20.093261] radeon_dvi_encoder : drm_connector = DVI-I-1
[ 20.095210] radeon_dvi_encoder : encoder->encoder_type !=DRM_MODE_ENCODER_TMDS : return drm_encoder = TV-48
[ 20.097134] radeon_audio_component_get_eld : encoder = TV-48 : proceed
...
Now, the encoder with Object ID 48 is type TV DAC. It certainly looks here like the radeon driver has configured - or "thinks" it has configured - the TV DAC encoder, and not the TMDS encoder. But then, as I understand, only the TMDS could generate a signal on the HDMI cable - and there is an HDMI signal, and a working display.
How is any of this suppose to work when radeon_dvi_encoder() is returning the wrong encoder?
Can you attach your full dmesg output from boot with nothing culled out?
That is what you have in dmesg_log_V_boot, minus the very beginning that is overwritten in the ring buffer.
I am also attaching here the dmesg log with the new printk's: dmesg_log_V_3
Are you passing any special parameters on the kernel command line?
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=7a7ef1d1-cbc9-49b3-bd47-84003529da62 rw console=tty17 loglevel=5 resume=/dev/sda3 vt.color=0x70 zswap.enabled=1 zswap.zpool=z3fold video=DVI-I-1:1920x1080e drm.debug=0x1e