Bug 1193397 - amdgpu: Monitor NO signal if it hasn't been on since system boot
amdgpu: Monitor NO signal if it hasn't been on since system boot
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.3
x86-64 openSUSE Leap 15.3
: P3 - Medium : Major (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
https://gitlab.freedesktop.org/drm/am...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-12-03 22:20 UTC by Kourosh P.
Modified: 2022-08-27 16:55 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session (191.78 KB, text/plain)
2021-12-04 14:08 UTC, Kourosh P.
Details
journalctl Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session (191.78 KB, text/plain)
2021-12-04 14:11 UTC, Kourosh P.
Details
Xorg Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session (49.67 KB, text/plain)
2021-12-04 14:12 UTC, Kourosh P.
Details
journalctl Turning the monitor ON it shows DisplayPort NO Signal (203.13 KB, text/plain)
2021-12-04 14:14 UTC, Kourosh P.
Details
Xorg Turning the monitor ON it shows DisplayPort NO Signal (49.67 KB, text/plain)
2021-12-04 14:15 UTC, Kourosh P.
Details
journalctl Changing to console 1, CTRL+ALT+F1 (tty1) to get to command line (205.11 KB, text/plain)
2021-12-04 14:16 UTC, Kourosh P.
Details
Xorg Changing to console 1, CTRL+ALT+F1 (tty1) to get to command line (50.53 KB, text/plain)
2021-12-04 14:16 UTC, Kourosh P.
Details
journalctl While in console 1 (tty1), login, starting X (startx) (211.89 KB, text/plain)
2021-12-04 14:18 UTC, Kourosh P.
Details
Xorg While in console 1 (tty1), login, starting X (startx) (50.53 KB, text/plain)
2021-12-04 14:21 UTC, Kourosh P.
Details
dmesg After No Signal at console 7 (137.02 KB, text/plain)
2021-12-05 17:46 UTC, Kourosh P.
Details
dmesg After switching to console 1 and startx (253.55 KB, text/plain)
2021-12-05 17:48 UTC, Kourosh P.
Details
ps ucx for user after switching to TTY1 (2.63 KB, text/plain)
2021-12-05 17:49 UTC, Kourosh P.
Details
ps ucx for root after switching to TTY1 (20.96 KB, text/plain)
2021-12-05 17:50 UTC, Kourosh P.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kourosh P. 2021-12-03 22:20:12 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Build Identifier: 

Dear developers,

The predicament is: 
If the monitor is OFF since the booting of the system and letting the X-server load (around 20-30 second since boot) then turning the monitor ON, the display shows 'DisplayPort NO Signal', have to change to console 1 (CTRL+ALT+F1) to gain command line, and monitor comes ON. Login, either reboot the system and LEAVE the monitor ON the whole time, or startx to get to Display Manager.
I have tested my system with Tumbleweed (on a test SSD) and got the same problem. But installed MX Linux 21 and the problem wasn't there any more. I could leave the monitor OFF, start my computer, after 20-30 seconds turn ON the monitor and I would see the desktop ready and loaded. Same thing would result in no signal with openSUSE Leap or TW. So I think it is something that happens with openSUSE. I even tested with HDMI cable.
On the openSUSE forum I have some journalctl and Xorg.0.log that I hope could help pinpoint the matter.


Reproducible: Always

Steps to Reproduce:
1. Leave monitor OFF
2. Start the PC with monitor OFF
3. Wait about 20-30 seconds (so X-server is loaded) and turn the monitor ON
3. No signal is received by the monitor (HDMI nor DisplayPort) on console 7
4. Change to console 1, 2, 3 or.... Monitor will no show the login command on the respective console
Actual Results:  
No signal is received by the monitor (HDMI nor DisplayPort) on console 7 unless change to console 1, 2, 3 or.... Monitor will no show the login command on the respective console

Expected Results:  
The monitor should receive signal from the X-server and show the fully loaded desktop

ASUSTeK PRIME Z490-A - UEFI: American Megatrends v: 2301 - Intel Core i7-10700K - Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] driver: amdgpu v: kernel Display: x11 server: X.org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa

The thread that this issue has been discussed on:
https://forums.opensuse.org/showthread.php/563022-X-won-t-show-anything-if-the-monitor-hasn-t-been-on-since-system-boot-Monitor-blank-on-console-7th
Comment 1 Stefan Dirsch 2021-12-04 10:19:35 UTC
Please attach Xorg.0.log and journalctl. to this bugreport.
Comment 2 Kourosh P. 2021-12-04 14:08:03 UTC
Created attachment 854309 [details]
Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session
Comment 3 Kourosh P. 2021-12-04 14:11:11 UTC
Created attachment 854310 [details]
journalctl Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session
Comment 4 Kourosh P. 2021-12-04 14:12:57 UTC
Created attachment 854311 [details]
Xorg Booting the system with monitor OFF since boot, leaving the monitor OFF and SSH into the system from another machine and run the commands from the SSH session
Comment 5 Kourosh P. 2021-12-04 14:14:15 UTC
Created attachment 854312 [details]
journalctl Turning the monitor ON it shows DisplayPort NO Signal
Comment 6 Kourosh P. 2021-12-04 14:15:18 UTC
Created attachment 854313 [details]
Xorg Turning the monitor ON it shows DisplayPort NO Signal
Comment 7 Kourosh P. 2021-12-04 14:16:17 UTC
Created attachment 854314 [details]
journalctl Changing to console 1, CTRL+ALT+F1 (tty1) to get to command line
Comment 8 Kourosh P. 2021-12-04 14:16:48 UTC
Created attachment 854315 [details]
Xorg Changing to console 1, CTRL+ALT+F1 (tty1) to get to command line
Comment 9 Kourosh P. 2021-12-04 14:18:54 UTC
Created attachment 854316 [details]
journalctl While in console 1 (tty1), login, starting X (startx)
Comment 10 Kourosh P. 2021-12-04 14:21:45 UTC
Created attachment 854317 [details]
Xorg While in console 1 (tty1), login, starting X (startx)

All the above commands were run via SSH session.
https://forums.opensuse.org/showthread.php/563022-X-won-t-show-anything-if-the-monitor-hasn-t-been-on-since-system-boot-Monitor-blank-on-console-7th?p=3087525#post3087525
Comment 11 Stefan Dirsch 2021-12-04 18:57:26 UTC
Indeed no monitor has been detected.  Sounds like a kernel issue to me.
Comment 12 Kourosh P. 2021-12-04 21:10:14 UTC
I would like to add the following for reference:

My original NEW system had an Nvidia GeForce 3070 GPU with the nouveau drivers, when I started experiencing this issue. Then I installed the Nvidia .run file thinking it might help but it didn't. When I contacted my PC store where I bought the system, Canada Computers, they were kind enough to swap the GPU for the current one, i.e. AMD Radeon RX 6800 (I was lucky that I purchased the extended warranty at the time of purchase). To summarize, I don't think it is ONLY amdgpu driver issue in my humble opinion.
Comment 13 Stefan Dirsch 2021-12-04 21:46:18 UTC
Summary change is confusing. There is no nvidia GPU in this system any longer.
Comment 14 Kourosh P. 2021-12-04 21:50:36 UTC
This issue was not only experienced with AMD GPU but with NVIDIA as well. You know better. I thought it would be helpful.
Comment 15 Stefan Dirsch 2021-12-04 21:53:00 UTC
Thanks. But in that case it's more confusing than helpful. ;-)
Comment 16 Takashi Iwai 2021-12-05 08:22:53 UTC
Try to boot with monitor off, run X.  Then before turning on the monitor, enable the debug option of drm, run the following as root:
   echo 0x1e > /sys/module/drm/parameters/debug

Then turn on the monitor, confirm the problem ('no signal').  Save the dmesg output at this stage.

Then move to VT1, restore the monitor out, and save the dmesg output again.
After that, clear the drm debug option
    echo 0 > /sys/module/drm/parameters/debug

Upload the saved two dmesg outputs to Bugzilla.

BTW, when you boot with another desktop environment (such as icewm), does the problem persist?  I mean not to log out and switch from KDE, but login directly to icewm session (which should be available as fallback) at boot.
Comment 17 Nikolai Nikolaevskii 2021-12-05 10:48:20 UTC
According to inxi output OP uses Intel Core i7-10700K + ASUSTeK PRIME Z490-A + AMD Navi 21 video card.
With Intel Core i7-10700K he has 2 video cards: built-in Intel UHD 630 and discrete AMD (previously Nvidia). But inxi shows only AMD Navi 21.
There are some settings in BIOS about video cards: disable/enable iGFX (i.e. built-in), and which video card BIOS will initialize first - built-in or discrete.
So, if built-in video card is disabled, but is set to be initialized first, he may get observed behaviour.

To OP: please provide full output for command:
sudo inxi -aSCGImz
Comment 18 Stefan Dirsch 2021-12-05 11:01:51 UTC
Well, according to the logs the reporter provided the internal GPU has been disabled.
Comment 19 Kourosh P. 2021-12-05 16:57:01 UTC
To @Nikolai

In the BIOS Advanced > System Agent (SA) Configuration > Graphics Configuration > Primary Display > 'Auto' was selected. The other options were 'CPU Graphics', 'PEG', 'PCIE' and I changed it to 'PEG'.
Advanced > System Agent (SA) Configuration > Graphics Configuration > iGPU Multi-Monitor is already set to 'Disabled'. I rebooted the system with monitor OFF and got the same result with DP NO Signal when monitor was turned on.

sudo inxi -aSCGImz
System:    Kernel: 5.3.18-59.34-default x86_64 bits: 64 compiler: gcc v: 7.5.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.3.18-59.34-default root=UUID=843c52a9-20ba-4694-abc3-a3988c2c354a 
           splash=silent resume=/dev/disk/by-uuid/295c1286-73fd-42fa-9f7a-21fa1103e118 mitigations=auto quiet 
           Console: tty 1 dm: SDDM Distro: openSUSE Leap 15.3 
Memory:    RAM: total: 15.53 GiB used: 733.7 MiB (4.6%) 
           Array-1: capacity: 64 GiB slots: 4 EC: None max module size: 16 GiB note: est. 
           Device-1: ChannelA-DIMM1 size: No Module Installed 
           Device-2: ChannelA-DIMM2 size: 8 GiB speed: 2133 MT/s type: DDR4 detail: synchronous bus width: 64 bits 
           total: 64 bits manufacturer: G-Skill part-no: F4-3000C16-8GISB serial: N/A 
           Device-3: ChannelB-DIMM1 size: No Module Installed 
           Device-4: ChannelB-DIMM2 size: 8 GiB speed: 2133 MT/s type: DDR4 detail: synchronous bus width: 64 bits 
           total: 64 bits manufacturer: G-Skill part-no: F4-3000C16-8GISB serial: N/A 
CPU:       Topology: 8-Core model: Intel Core i7-10700K bits: 64 type: MT MCP arch: N/A family: 6 model-id: A5 (165) 
           stepping: 5 microcode: EC L1 cache: 512 KiB L2 cache: 16.0 MiB L3 cache: 16.0 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 121596 
           Speed: 800 MHz min/max: 800/5100 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 801 6: 800 7: 800 8: 800 
           9: 801 10: 800 11: 800 12: 800 13: 800 14: 800 15: 800 16: 800 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] vendor: Tul driver: amdgpu 
           v: kernel bus ID: 04:00.0 chip ID: 1002:73bf 
           Display: server: X.org 1.20.3 compositor: kwin_x11 driver: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa 
           tty: 208x57 
           Message: Advanced graphics data unavailable in console for root. 
Info:      Processes: 338 Uptime: N/A Init: systemd v: 246 runlevel: 5 target: graphical.target Compilers: gcc: N/A 
           Shell: bash (sudo) v: 4.4.23 running in: tty 1 (SSH) inxi: 3.1.00
Comment 20 Kourosh P. 2021-12-05 17:42:29 UTC
(In reply to Takashi Iwai from comment #16)
> Try to boot with monitor off, run X.  Then before turning on the monitor,
> enable the debug option of drm, run the following as root:
>    echo 0x1e > /sys/module/drm/parameters/debug
> 
> Then turn on the monitor, confirm the problem ('no signal').  Save the dmesg
> output at this stage.

dmesg | susepaste
https://susepaste.org/49240459

> Then move to VT1, restore the monitor out, and save the dmesg output again.
> After that, clear the drm debug option
>     echo 0 > /sys/module/drm/parameters/debug

I hope with "move to VT1" you mean CTRL+ALT+F1 and run the command, and not rebooting the system with monitor ON this time.

I did go to TTY1, login, startx (X took a lot longer time to load but only the mouse cursor is visible with screen showing black) waited few minutes and the ddesktop came on for a split second and everything went black except the mouse cursor being visible. I did dmesg:

dmesg | susepaste
https://susepaste.org/12185740

I had to move to TTY2 to be able to reboot the system safely (took a LONG time).
Don't know if I should have done another dmesg output after a successful reboot with monitor ON?!

> Upload the saved two dmesg outputs to Bugzilla.
> 
> BTW, when you boot with another desktop environment (such as icewm), does
> the problem persist?  I mean not to log out and switch from KDE, but login
> directly to icewm session (which should be available as fallback) at boot.
Comment 21 Kourosh P. 2021-12-05 17:46:10 UTC
Created attachment 854329 [details]
dmesg After No Signal at console 7
Comment 22 Kourosh P. 2021-12-05 17:48:14 UTC
Created attachment 854330 [details]
dmesg After switching to console 1 and startx
Comment 23 Kourosh P. 2021-12-05 17:49:37 UTC
Created attachment 854331 [details]
ps ucx for user after switching to TTY1
Comment 24 Kourosh P. 2021-12-05 17:50:35 UTC
Created attachment 854332 [details]
ps ucx for root after switching to TTY1
Comment 25 Kourosh P. 2021-12-05 18:04:51 UTC
(In reply to Takashi Iwai from comment #16)

> BTW, when you boot with another desktop environment (such as icewm), does
> the problem persist?  I mean not to log out and switch from KDE, but login
> directly to icewm session (which should be available as fallback) at boot.

I enabled icewm to load instead of Plasma at boot, but still NO Signal when turning on monitor after boot I am afraid.
Comment 26 Nikolai Nikolaevskii 2021-12-11 16:34:37 UTC
(In reply to Nikolai Nikolaevskii from comment #17)
> According to inxi output OP uses Intel Core i7-10700K + ASUSTeK PRIME Z490-A
> + AMD Navi 21 video card.
> With Intel Core i7-10700K he has 2 video cards: built-in Intel UHD 630 and
> discrete AMD (previously Nvidia). But inxi shows only AMD Navi 21.
> There are some settings in BIOS about video cards: disable/enable iGFX (i.e.
> built-in), and which video card BIOS will initialize first - built-in or
> discrete.
> So, if built-in video card is disabled, but is set to be initialized first,
> he may get observed behaviour.
> 
> To OP: please provide full output for command:
> sudo inxi -aSCGImz

OK, theory was good, but failed.

New one: https://wiki.archlinux.org/title/AMDGPU#Issues_with_power_management_/_dynamic_re-activation_of_a_discrete_amdgpu_graphics_card

[QUOTE]
Issues with power management / dynamic re-activation of a discrete amdgpu graphics card

If you encounter issues similar to [9], you can workaround the issue by setting the kernel parameter amdgpu.runpm=0, which prevents the dGPU from being powered down dynamically at runtime.
[/QUOTE]

Try to use parameter amdgpu.runpm=0.
Comment 27 Kourosh P. 2021-12-11 17:49:24 UTC
(In reply to Nikolai Nikolaevskii from comment #26)
> (In reply to Nikolai Nikolaevskii from comment #17)
> > According to inxi output OP uses Intel Core i7-10700K + ASUSTeK PRIME Z490-A
> > + AMD Navi 21 video card.
> > With Intel Core i7-10700K he has 2 video cards: built-in Intel UHD 630 and
> > discrete AMD (previously Nvidia). But inxi shows only AMD Navi 21.
> > There are some settings in BIOS about video cards: disable/enable iGFX (i.e.
> > built-in), and which video card BIOS will initialize first - built-in or
> > discrete.
> > So, if built-in video card is disabled, but is set to be initialized first,
> > he may get observed behaviour.
> > 
> > To OP: please provide full output for command:
> > sudo inxi -aSCGImz
> 
> OK, theory was good, but failed.
> 
> New one:
> https://wiki.archlinux.org/title/AMDGPU#Issues_with_power_management_/
> _dynamic_re-activation_of_a_discrete_amdgpu_graphics_card
> 
> [QUOTE]
> Issues with power management / dynamic re-activation of a discrete amdgpu
> graphics card
> 
> If you encounter issues similar to [9], you can workaround the issue by
> setting the kernel parameter amdgpu.runpm=0, which prevents the dGPU from
> being powered down dynamically at runtime.
> [/QUOTE]
> 
> Try to use parameter amdgpu.runpm=0.

I tried that kernel parameter on both my test SSD (runs vanilla Leap 15.3 without AMDGPU-PRO drivers) and my main m.2 (runs Leap 15.3 with AMDGPU-PRO drivers) and still the same results I am afraid.
Comment 28 Kourosh P. 2021-12-12 19:45:42 UTC
I was asked to report the following:

My system works well with Windows 11 (monitor OFF from the boot sequence, turn monitor ON after 20-30 seconds, desktop is showing). Same is true with MX Linux 21.
Comment 29 Takashi Iwai 2021-12-13 14:39:46 UTC
The log showed that DP-3 connector was detected while HDMI-A-1 connector was disconnected.  Isn't this DP-3 corresponding to your monitor?  Or is it a different output?
Comment 30 Kourosh P. 2021-12-13 15:33:40 UTC
(In reply to Takashi Iwai from comment #29)
> The log showed that DP-3 connector was detected while HDMI-A-1 connector was
> disconnected.  Isn't this DP-3 corresponding to your monitor?  Or is it a
> different output?

Thank you for your follow-up.
When doing the test to get a log I don't remember physically disconnecting an HDMI cable. I have always performs the logs when on DisplayPort. I have tested to see if HDMI works in the past, but not unplugging while getting logs.

I hope I understood your question.
Thank you.
Comment 31 Takashi Iwai 2022-01-10 16:35:57 UTC
Could you check whether the issue is seen with the latest kernel in OBS Kernel:stable:Backport?  (without AMDGPU pro.)

If the problem is still present with the latest kernel, we need to report to the upstream devs, gitlab.freedesktop.org Issues.
Comment 32 Kourosh P. 2022-01-11 01:59:50 UTC
(In reply to Takashi Iwai from comment #31)
> Could you check whether the issue is seen with the latest kernel in OBS
> Kernel:stable:Backport?  (without AMDGPU pro.)
> 
> If the problem is still present with the latest kernel, we need to report to
> the upstream devs, gitlab.freedesktop.org Issues.

Thank you for your follow-up.
Is it possible to install TW on my test SSD and test it? I believe TW runs the latest kernel, right? My daily driver has been Leap since 2016. 

Thanks.
Comment 33 Takashi Iwai 2022-01-11 07:03:39 UTC
The kernel in OBS Kernel:stable:Backport is equivalent with TW kernel (can be even newer), just built for Leap file hierarchy without UsrMerge.
Checking with that kernel would make clearer whether it's fixed solely in kernel or not.
Comment 34 Kourosh P. 2022-01-11 14:52:04 UTC
(In reply to Takashi Iwai from comment #33)
> The kernel in OBS Kernel:stable:Backport is equivalent with TW kernel (can
> be even newer), just built for Leap file hierarchy without UsrMerge.
> Checking with that kernel would make clearer whether it's fixed solely in
> kernel or not.

Thank you for your reply.

1. I was reading about 5.16 and how it is supporting more newer hardware, but TW is still on 5.15, is that OK?
2. Is this link OK for doing it through Leap? : https://software.opensuse.org/download/package?package=kernel-debug&project=Kernel%3Astable%3ABackport#manualSLE

Thanks
Comment 35 Takashi Iwai 2022-01-11 14:55:53 UTC
The update to 5.16 on TW is already in staging.  The movement will happen sooner or later.  So, we should concentrate on 5.16 for now.

And, you need to install only kernel-default.rpm.  Nothing else is needed.
Comment 36 Kourosh P. 2022-01-11 18:02:01 UTC
(In reply to Takashi Iwai from comment #35)
> The update to 5.16 on TW is already in staging.  The movement will happen
> sooner or later.  So, we should concentrate on 5.16 for now.
> 
> And, you need to install only kernel-default.rpm.  Nothing else is needed.

I did a fresh install of Leap 15.3 on my test SSD, made sure it has first priority on GRUB (and not my main m.2 with Leap 15.3).
Added repositories/Kernel:stable:Backport/standard/Kernel:stable:Backport.repo and only installed kernel-default and 5.16 got installed, reboot to make sure everything is OK. Confirmed after boot and desktop that 5.16 was installed.

Shutdown, turned the monitor OFF, booted the system, after 30 seconds turned the monitor ON 'DisplayPort NO Signal'! Had to switch to Console 1 to gain command line to reboot into my main m.2 Leap.  :(

Same steps and MX Linux didn't have problems showing the desktop, same is true with Windows 11, but I like openSUSE ;)
Comment 37 Takashi Iwai 2022-01-17 15:32:56 UTC
So the problem seems reproduced with 5.16.  In that case, you'd better to report to the upstream, gitlab.freedesktop.org Issues, and let the upstream devs handling it.
Comment 38 Kourosh P. 2022-02-08 01:34:34 UTC
(In reply to Takashi Iwai from comment #37)
> So the problem seems reproduced with 5.16.  In that case, you'd better to
> report to the upstream, gitlab.freedesktop.org Issues, and let the upstream
> devs handling it.

Thank you for your reply.
I don't know what to do on gitlab.freedesktop.org
Comment 39 Takashi Iwai 2022-02-08 07:36:34 UTC
Please report the problem at
  https://gitlab.freedesktop.org/drm/amd/-/issues
Comment 40 Kourosh P. 2022-03-29 14:07:23 UTC
(In reply to Takashi Iwai from comment #39)
> Please report the problem at
>   https://gitlab.freedesktop.org/drm/amd/-/issues

Thank you Takashi.

I have reported this matter at the following link:
https://gitlab.freedesktop.org/drm/amd/-/issues/1952
Comment 41 Felix Miata 2022-08-27 16:55:44 UTC
(In reply to Kourosh P. from comment #40)
> I have reported this matter at the following link:
> https://gitlab.freedesktop.org/drm/amd/-/issues/1952

I just made the following addition there:

# inxi -S
System:
  Host: ab250 Kernel: 5.18.19-200.fc36.x86_64 arch: x86_64 bits: 64
    Desktop: Trinity v: R14.0.12 Distro: Fedora release 36 (Thirty Six)
#

If I keep my second display's cable disconnected, I get this:
# grep onnec /var/log/Xorg.0.log
[     5.313] (II) modeset(0): Output DP-1 connected
[     5.313] (II) modeset(0): Output HDMI-1 disconnected
[     5.313] (II) modeset(0): Output HDMI-2 disconnected
[     5.313] (II) modeset(0): Output HDMI-3 disconnected
[     5.313] (II) modeset(0): Output DP-2 disconnected
#
Or this:
# grep onnec /var/log/Xorg.0.log
[     5.544] (II) modeset(0): Output DP-1 disconnected
[     5.544] (II) modeset(0): Output HDMI-1 disconnected
[     5.544] (II) modeset(0): Output HDMI-2 connected
[     5.544] (II) modeset(0): Output HDMI-3 disconnected
[     5.544] (II) modeset(0): Output DP-2 disconnected
#

It may surprise many that if I keep my second display's signal cable connected
from the PC, but with it powered off, I get this on booting instead:
# grep onnec /var/log/Xorg.0.log
[     5.412] (II) modeset(0): Output DP-1 connected
[     5.412] (II) modeset(0): Output HDMI-1 disconnected
[     5.412] (II) modeset(0): Output HDMI-2 connected
[     5.412] (II) modeset(0): Output HDMI-3 disconnected
[     5.412] (II) modeset(0): Output DP-2 disconnected
#
Or this:
# grep onnec /var/log/Xorg.0.log
[     5.451] (II) modeset(0): Output DP-1 connected
[     5.451] (II) modeset(0): Output HDMI-1 disconnected
[     5.451] (II) modeset(0): Output HDMI-2 connected
[     5.451] (II) modeset(0): Output HDMI-3 disconnected
[     5.451] (II) modeset(0): Output DP-2 disconnected
#

So, at "connection" time, the secondary display isn't providing any information
about it's capability, only the cable connection is "reporting" something is
connected. Some may want to rethink their definition of "connected", and not boot
with an external display attached but un-powered.[/quote]

It would be nice to know what MX Linux is doing that it doesn't present the problem.