X won't show anything if the monitor hasn't been on since system boot - Monitor blank on console 7th

Hi all,

I have been experiencing something weird since I bought a new computer. (Intel i7-10700K, GeForce RTX 3070). After installing Leap on it I realized if and only if the monitor is off and the computer is booted up and has reached the Desktop Manager X stage (which normally takes about 15-20 seconds) then the monitor is turned on, there is no signal (Display Port). The monitor is black and because it has no signal the monitor goes to sleep. If I press CTRL + ALT + F1, the monitor wakes up and I get the first console with the login. I can login and if I do a ps ucx I can see that plasma, kwin… are running but when I switch to console 7 (CTRL + ALT + F7) the monitor says that there is no signal. The only was to get to X is to reboot the system through console 1 but making sure that the monitor is turned on while the boot is in process.

After a while of testing different configurations (testing with another monitor, disconnecting all the peripherals, disconnecting the motherboard battery for 5 minutes, reinstalling the RAM) and contacting Canada Computers (where I bought the PC from) I tool the graphics card in. The service guy tested it, updated the GPU BIOS and when brought home, it was the same. They were kind enough to swap my GeForce 3070 for an AMD Radeon RX 6800 and I paid the difference thinking that AMD GPU work better on Linux based OS, but it hasn’t helped.
The service guy asked me to try Windows, so I did. Here is the kicker, I installed Windows 11 on another SSD, did my test with monitor being turned off, and after 20-30 seconds, the monitor came on with no problem!!!

After that I thought maybe because Leap 15.3 uses an older version of Linux kernel (5.3.18-59.34), I might have a better luck with latest Linux kernel. So on another SSD I installed Tumbleweed, but experienced the same results as on Leap 15.3.

I am reaching out to anybody who can help me here. I was thinking to change my motherboard from Asus Prime Z490-A to Z590-A and see maybe it is the motherboard, but after seeing that Windows 11 has no problems, I am not sure what to do.

Would appreciate guidance.

Thank you.

Here’s an informative thread I found discussing the same…
https://unix.stackexchange.com/questions/463465/force-monitor-detection-low-level?noredirect=1&lq=1

If the monitor is power cycled does that cause the X-server to recognize it?

Does the following workaround discussed there wake the DP-connected monitor up?

env DISPLAY=:0 xset dpms force off
env DISPLAY=:0 xset dpms force on

When I turn off monitor during suspend to RAM, system has troubles with GPU during wakeup.
This is security issue or not? Is it related to secure boot?

Thank you for your reply. A monitor power cycle does not cause the X-server to recognize it. Switching to console 1 and back to console 7, results the monitor saying ‘DisplayPort NO Signal’.

I have to switch to console 1 to do the following:

env DISPLAY=:0 xset dpms force off
xset:  unable to open display ":0"

And

set | grep DISPLAY

Returns nothing.

The reason it’s unable to open display 0 is it because X-server hasn’t registered the display?!?

What driver are you using for nvidia?
Is it the RPM or the .run file?
Is there any nvidia services in Yast Services Manager?

I used to have the .run file with the same problem, a week ago I updated my GeForce 3070 to an AMD Radeon RX 6800:

**Machine:   Type:** Desktop **System:** ASUS **product:** N/A **v:** N/A **serial:** <superuser/root required>  
           **Mobo:** ASUSTeK **model:** PRIME Z490-A **v:** Rev 1.xx **serial:** <superuser/root required> **UEFI:** American Megatrends **v:** 2301  
           **date:** 07/13/2021  
**CPU:       Topology:** 8-Core **model:** Intel Core i7-10700K **bits:** 64 **type:** MT MCP **L2 cache:** 16.0 MiB  
           **Speed:** 4772 MHz **min/max:** 800/5100 MHz **Core speeds (MHz):** **1:** 3427 **2:** 3830 **3:** 3851 **4:** 3709 **5:** 3683 **6:** 3829 **7:** 3748  
           **8:** 3776 **9:** 4153 **10:** 3357 **11:** 3756 **12:** 3616 **13:** 3635 **14:** 4032 **15:** 4205 **16:** 3711  
**Graphics:  Device-1:** Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] **driver:** amdgpu  
           **v:** 5.11.32.21.40  
           **Display:** x11 **server:** X.Org 1.20.3 **driver:** amdgpu **unloaded:** fbdev,modesetting,vesa **resolution:** 2560x1440  
           **OpenGL:** **renderer:** AMD Radeon RX 6800 (SIENNA_CICHLID DRM 3.43.0 5.3.18-59.34-default LLVM 12.0.1)  
           **v:** 4.6 Mesa 21.3.0-devel

This is likely lower-level (driver/firmware specific), rather than X-server related. My understanding is essentially as mentioned in the stack exchange thread I linked to already…

That sounds like a possible hardware/firmware interaction issue: in the “cable connected/monitor off during boot” situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks “looks like these GPU pins are wired straight to ground, so this interface is not present”. The driver won’t re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help? – telcoM
Aug 19 '18 at 11:02

Thank you for your reply.

I followed SDB:AMDGPU-PRO - openSUSE Wiki and installed the latest amdgpu-pro driver from https://www.amd.com/en/support/graphics/amd-radeon-6000-series/amd-radeon-6800-series/amd-radeon-rx-6800 for my card and system (Radeon™ Software for Linux® installer version 21.40.1 for SLED/SLES 15 SP 3).
Before installing the amdgpu-pro driver, I tested the system/monitor and had the same results. That is why I decided to install the amdgpu-pro with no different result(s).
Am I missing something?
I am not very savvy, but if somebody directs me to the right direction, I might get somewhere.

Thank you in advance.

I can only recommend sending a bug report to AMD…
https://amdgpu-install.readthedocs.io/en/latest/install-bugrep.html#
It’s not an openSUSE issue.

BTW, does unplugging and re-plugging the DP cable get the display active at all? I’ve also seen a couple of reports that suggest turning off DCC/CI (Display Data Channel/Command Interface) in the monitor settings (if present). YMMV.

https://www.reddit.com/r/radeon/comments/gbi7mk/displayport_sleep/

Which brand/model is the monitor in question?

Have unplugged the DP cable in the past as well, will try it again though.
I did disable the DDC/CI just now and will test rebooting.
My monitor is ASUS TUF Gaming VG27AQ.

Unplugging results in the same DP NO Signal message.
Disabling DDC/CI doesn’t help either.

While in console 1, I did a ps ucx and the only processes running were systemd and sd-pam none of the X-server stuff weren’t running!

I just asked because I had this similar problem with nvidia just recently.

I had an NVIDIA GeForce 3070 before, experiencing the DP No Signal thingy, and upgraded to Radeon RX 6800 thinking AMD is probably better with Linux based OS.
Did you fix your issue?

Yes I had fixed it. I am using the .run driver and the nvidia systemd which is installed by the driver was the culprit.
There is an option to not install it and that was I did and now it is behaving as it should.

Interesting. Can you please expand on that?
I wonder if there is an equivalent option for AMD (amdgpu) driver as well.

I did a full MX Linux 21 installation on my test SSD and booted the system while the monitor is off (same SSD that I tested openSUSE Tumbleweed on). It doesn’t matter which stage of the system boot I turn on the monitor on, there is DP signal and no problems at all with MX Linux.

So now I have my doubt that **IT IS **openSUSE (both Leap and Tumbleweed, I’ve tested both) that causes the problem. Is it systemd? Because systemd is disabled by default on MX Linux.
I have used openSUSE since 2016 and don’t want to use any other distribution. Should I test the issue with another distro WITH systemd and see if it is systemd?!

Would greatly appreciate help.

Regards

Of course. It is the reason of everything bad that happens in Linux. What else?

Would greatly appreciate help.

Start with determining whether kernel detects your display.

grep . /sys/class/drm/*/{enabled,status}

Do it first in your good distribution before and after you switched on monitor. Is there any difference? Then do it in openSUSE. Is there any difference?

Thank you so much for your reply.

After MX install, my openSUSE grub menu is gone. So I am figuring out how to rescue my main openSUSE Leap drive (it is on an m.2 drive).
What do you mean “good distribution”? On MX? How do I do that when the monitor is off? Do I SSH into it?

Right now, I am on MX and this is the output:

$ grep . /sys/class/drm/*/{enabled,status}
/sys/class/drm/card0-DP-1/enabled:disabled
/sys/class/drm/card0-DP-2/enabled:disabled
/sys/class/drm/card0-DP-3/enabled:enabled
/sys/class/drm/card0-HDMI-A-1/enabled:disabled
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:connected
/sys/class/drm/card0-HDMI-A-1/status:disconnected

Thank you

Well, you can blindly type but yes, ssh into system will certainly be easier. You can also run cron job or systemd timer that executes it shortly after boot.

$ grep . /sys/class/drm/*/{enabled,status}
/sys/class/drm/card0-DP-3/enabled:enabled
/sys/class/drm/card0-DP-3/status:connected

Is it your correct monitor (or, better, video input where monitor is connected)?