Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

Enrico1989 · Yesterday 06:39:48

I run XMonad on VT1.

Hi there. Ten days ago or so, I woke up my system after `systemctl suspend`ing it via SSH from the smartphone (JuiceSSH). **_I saw a black screen on VT1 where XMonad was running_**. I could change to other VTs just fine, e.g. to tty4 via Ctrl+Alt+F4, check journal, `htop`, and whatever.

I could literally do

env DISPLAY=:0 mpv /some/video/file

, and it would open up in the xmonad session, with audio and all, I could Ctrl+Alt+F1 back to it, and even seek through the video with arrow keys, and so on. Basically I just saw a black screen, but all was working fine.

It is not this, because I see no cursor. Indeed, when I write "black screen", it does not mean the "black" of the terminal, but rather the black of a turned-off screen.

It was not at all the first time this happened. And I'm not sure if there's some relation to https://bbs.archlinux.org/viewtopic.php?id=314396&p=2

---

Anyway, I ended up putting the system to sleep again (but I don't remember if via JuiceSSH or from some other VT), and upon waking up the issue affected all other VTs, so I ssh-d into the system and rebooted the machine.

---

A bit more than 7 hours ago, I run

systemctl suspend

from my phone, using JuiceSSH, which apparently is not on the playstore anymore.

I start wondering whether it's JuiceSSH that does something wrong? Feels strange though.

Anyway, I've switched to VT2 and logged in XMonad again. So I have 2 XMonad sessions running, and they're both still doing their job, I can do for instance

# I'm on XMonad running on VT2
env DISPLAY=:0 mpv /some/video/file # opens on the XMonad running on VT1, I hear the audio and can control mpv via its key bindings if I switch there via Ctrl+Alt+F1
env DISPLAY=:1 mpv /some/video/file # opens on the XMonad running on VT2

It's just that if I switch to VT1, I see a black screen -.-

Here's a video of what's happening. It's less than a minute.

The output of

journalctl -b --user

is this: https://paste.c-net.org/HuntersRolled, and last night reboot happens at

Oct 24 01:09:00 greywarden systemd-sleep[1226942]: localhost:9091/transmission/rpc/ acknowledged notification
...

Last edited by Enrico1989 (Yesterday 06:43:10)

Enrico1989 · Yesterday 21:31:26

Incidentally, I've killed all I could on VT1, and now all that's left is this:

 fuser -v /dev/tty1
                     USER        PID ACCESS COMMAND
/dev/tty1:           enrico     1112 F.... startx
                     enrico     1280 F.... xinit
                     enrico     1281 F.... Xorg
                     enrico     1296 F.... xmonad-x86_64-l

Still, black screen there. Is there any useful log I can share?

seth · Today 06:47:20

Check "xrandr -q" to see whether you lost the output or it's deactivated.
Otherwise "xset dpms force on" but dpms comes w/ input.

Lastly post your xorg log, there're incidents where input devices trigger some udev bug stalling the hand off forever (usually keyboards registrating as joystick)

Enrico1989 · Today 07:29:51

seth wrote:

Check "xrandr -q" to see whether you lost the output or it's deactivated.

I get different output if I run it in the X session I've started from VT2 vs the "broken" one on VT1:

$ DISPLAY=:0 xrandr -q # this the "broken" session on VT1
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary (normal left inverted right x axis y axis)
   3840x2160     60.00 +  30.00  
   2560x1440     59.95  
   1920x1080     60.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   640x480       75.00    72.81    59.94  
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 disconnected (normal left inverted right x axis y axis)

$ DISPLAY=:1 xrandr -q # this the session from which I'm writing on VT2
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 607mm x 345mm
   3840x2160     60.00*+  30.00  
   2560x1440     59.95  
   1920x1080     60.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   640x480       75.00    72.81    59.94  
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 disconnected (normal left inverted right x axis y axis)

seth wrote:

Otherwise "xset dpms force on"

Run this prepending DISPLAY=:0, with no effect.

seth wrote:

but dpms comes w/ input.

What do you mean?

seth wrote:

Lastly post your xorg log, there're incidents where input devices trigger some udev bug stalling the hand off forever (usually keyboards registrating as joystick)

Ok, after reading the first paragraph of https://wiki.archlinux.org/title/Xorg#General, I checked these outputs:

$ ls -l /var/log/Xorg.*
-rw-r--r-- 1 root enrico  3818 Jul 27 13:20 /var/log/Xorg.0.log
-rw-r--r-- 1 root enrico  3818 Jul 27 13:06 /var/log/Xorg.0.log.old
-rw-r--r-- 1 root enrico 46184 May 10  2024 /var/log/Xorg.1.log
-rw-r--r-- 1 root enrico 40895 May 10  2024 /var/log/Xorg.1.log.old

$ ls -l .local/share/xorg/
total 772
-rw-r--r-- 1 enrico enrico 287474 Oct 25 08:11 Xorg.0.log
-rw-r--r-- 1 enrico enrico  80765 Oct 21 10:31 Xorg.0.log.old
-rw-r--r-- 1 enrico enrico 182774 Oct 25 08:11 Xorg.1.log
-rw-r--r-- 1 enrico enrico  42639 Oct 15 08:01 Xorg.1.log.old
-rw-r--r-- 1 enrico enrico  56293 Jun  2 22:21 Xorg.2.log
-rw-r--r-- 1 enrico enrico  37759 Jun  2 22:19 Xorg.2.log.old
-rw-r--r-- 1 enrico enrico  41149 Jun  5 07:48 Xorg.3.log
-rw-r--r-- 1 enrico enrico  41148 Jun  5 07:46 Xorg.3.log.old

I assume you're alluding to these two files:

.local/share/xorg/Xorg.0.log https://paste.c-net.org/FailuresTicklish
.local/share/xorg/Xorg.1.log https://paste.c-net.org/HydrantSmash

seth · Today 07:38:02

xrandr --output DP-0 --auto

Enrico1989 · Today 07:53:03

Oh, this worked, but I had to run it "blindly" on the VT1.

As in, doing this from the VT2 where I'm currently on X

DISPLAY=:0 xrandr --output DP-0 --auto

would error like this

xrandr: Configure crtc 0 failed
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  49
  Current serial number in output stream:  50

so I had to Ctrl+Alt+F1, and then blindly open a terminal and run that command.

Why did this work and what causes it to break?

Last edited by Enrico1989 (Today 07:53:31)

seth · Today 08:17:22

The output will unregister with the power cut.
The x11 server enables all present outputs when starting and then stops caring.
You'll need a sleep hook or a daemon like x-on-resize the handle (re)appearing Outputs.

Arch Linux

#1 Yesterday 06:39:48

Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#2 Yesterday 21:31:26

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#3 Today 06:47:20

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#4 Today 07:29:51

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#5 Today 07:38:02

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#6 Today 07:53:03

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

#7 Today 08:17:22

Re: Black screen on WM on VT1 after suspend, but starting WM on VT2 is ok

Board footer