I have an HDMI display for the first time. I have setterm power displays down after 60 minutes. It's supposed to come back on when I use the keyboard or mouse. It doesn't. When I have it connected to my laptop, which also uses its local display, it does. Powering it down then up doesn't make it work. If it matters, the computer has a DisplayPort output, I use a DP-HDMI adaptor.

this is usually a problem with the software on that computer. It couldn't handle that situation properly. But without details hard to say more. But also it can be that DP-HDMI adaptor too.
I have a similar problem with a HP docking station, sometimes I have to switch it off and on again to make the monitor work again.

It's Linux, kernel 6.5.2, Slackware up-to-date. What do you have in mind? It happens with no apps running.

What details do you want?

When I plug it into my laptop, which has an HDMI output, it disconnects with the slightest bump, but re-attaching makes it work immediately. No amount of fussing has made it restart with the new computer. DP has the virtue of locking connectors. I'm going to buy a DP cable, hope it works.


The monitor or the docking station or the computer?

This is usually the app which manages the video output, it is the display driver, or something similar (X server, desktop...). Unfortunately it is not that simple. And I don't really know which one is responsible for it.
A wake up event (keyboard, mouse) should trigger the reconnection to the monitor, but it fails. To diagnose it we would need to check the logs. I guess it is not an easy case.
Probably much better to buy a cable and forget that adaptor.

Sometimes the monitor, but sometimes the docking station should be switched off/on. And the reboot of the computer helps too.

When it happens, does 'xrandr -q' list the monitor as connected? Does running 'xset -display :0 dpms force on' turns the monitor on?

That's not really a solution.

X isn't running. The screen is blank, which would make it hard to read the output of any program.

totally agree with you

for that you can use screen (which can log the output into a file) or you can directly do that for example by implementing a shell script which will execute all of your test commands and keep the logs/results in a file. Just for troubleshooting.

Obviously you ssh to the stricken computer to do this - why else would I specify display explicitly? And the fact that the screen is blank doesn't mean that X isn't running.

If your X session is asleep on tty7, and you do Ctrl-Alt-F3, pause, Alt-F7, does it wake after either action? If it does not, try booting using video= on Grub's kernel cmdline specifying a valid supported mode lower than normally used in X, then try them again.

I was doing the latter with previous problems. Still, it's a pain.

This is possible now that I have 2 computers. It'll take more work.

I was explaining, not upbraiding.

No X.

just a comment, you can use an ssh client on your phone, tablet to connect to your computer (if you wish).

Unintentionally it seems I may have reproduced this on a desktop PC normally using only one display. If I did, it would seem either DisplayPort or software is likely the culprit. I've been using the same display with DVI cable and PC for quite a number of years. The motherboard provided HDMI, DVI and VGA outputs, while the display lacks HDMI input. A month or so ago I replaced the motherboard with one that also has a DisplayPort output. In an attempt to be able to get sound into the display's speakers via the video cable yesterday, I replaced the DVI cable with a DP cable without rebooting before or after using it the rest of the day.

I normally turn the display off when I go to bed, which I did last night after saving journal for the boot and dmesg to disk. The Energy Star DE powersave settings have been set to standby, suspend and power off all at 120 min for farther back than I can remember. When I got up this AM earlier than normal, no amount of fiddling would wake the display up for the tty7 Xorg session. Instead, it just played dead, unless I switched to any of tty[1-6], where it worked normally. I connected a second display via HDMI, which didn't help one bit. I logged in as alternate user on tty5 and startx worked normally for both displays, but I still couldn't get tty7 to light up. Eventually I gave up, kill -9'd the browser sessions, then rebooted. I logged into GUI as alternate user successfully, then turned the display back off and went back to bed. On arising again 3 hours later and logging in as normal user, all seems to be working normally so far. When the neighbor's tree trimmers stop, I'm going back to bed, hopefully for at least 120 min, but anxious to see what happens when I turn the display back on.

Same failure repeated after more than 3 more hours sleeping. I had to do a long shopping today, so I ran the test again, after switching back to DVI cable from DisplayPort. All found to behave normally on return more than 4 hours later.

I don't understand what you did. Coincidentally, I had the experience you described for the first time: X wouldn't unblank but non-X would. I only had to kill X (ctrl-alt-backspace) and restart it, not reboot.

Killing X would have been enough, but I've been having trouble with SeaMonkey refusing to close entirelly, so instead of trying to find its PID to kill, I often choose to reboot instead. On NVME, rebooting is seriously fast. Most of the delay is waiting for UEFI BIOS to do its things, responsible for probably 70%+ of reboot time. Also, rebooting ensures all RAM cruft is eradicated.

What are your GPU and display driver? When I try the DP cable test again, and find it won't light up again even with a different display or DP cable, if I can't find any existing bug report, I'll be creating one, and would want to refer to your similar experience. Also, are you using 15.0's Xorg 1.20.14, or something newer?