6

Background

I've had this issue in one way or another for a long time now (years), and in multiple configurations. I've updated the driver & kernel on multiple occasions, and at this point I'm really at a loss as to where the culprit is.

It seems to be some kind of race condition where if one monitor is 'ready' before the other, the other just gets 'No Input', despite xrandr (and i3) thinking it's connected and should be working.

Old setup

  • One 4K monitor
  • One 1080p monitor

Behavior: Both monitors goes to sleep (from inactivity), and upon moving the mouse only one of them (the 1080p monitor) correctly wakes. The other one wakes a few seconds later, but then shows 'No Input'.

Workaround:

  • Run xrandr.sh (old version, see below for the new version)
    • I can't say for certain if I had to do something else to get it working (the whole process became muscle memory more or less...)

New setup

  • One 4K monitor (same as previous setup)
  • One 4K monitor (new)

Behavior: Similar behavior, but now the behavior applies to the new monitor. The old one behaves just fine (just like the old 1080p monitor).

Workaround 1 (remembering to wake the monitor first):

  • (before waking screens by moving mouse/keyboard) Wake 'slow' screen by using menu buttons on monitor
  • When monitor has completed resume from standby and shows menu items, move mouse/keyboard to wake monitors.
  • Both monitors work correctly!

Workaround 2 (forgetting to wake the monitor first):

  • (move mouse/keyboard) Both monitors wake. One works correctly, the other takes more time to wake from suspend and then just shows 'No Input'.
  • Run xrandr --output HDMI-0 --off, which puts the monitor back in standby.
  • Apply workaround 1.
  • Both monitors work correctly!

Details

Nvidia driver version (from Arch repos): 455.45.01-6

$ lspci | grep NV
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1)
$ xrandr
Screen 0: minimum 8 x 8, current 7680 x 2160, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 621mm x 341mm
   3840x2160     60.00*+  59.94    50.00    30.00    29.97    25.00    23.98    23.98
   2560x1600     59.97
   2560x1440     59.95
   1920x1080     60.00    59.94    50.00    60.00    50.04
   1680x1050     59.95
   1440x900      59.89
   1440x576      50.00
   1440x480      59.94
   1280x1024     75.02    60.02
   1280x960      60.00
   1280x800      59.81
   1280x720      60.00    59.94    50.00
   1024x768      75.03    70.07    60.00
   800x600       75.00    72.19    60.32    56.25
   720x576       50.00
   720x480       59.94
   640x480       75.00    72.81    59.94
   640x350       70.07
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 3840x2160+3840+0 (normal left inverted right x axis y axis) 1280mm x 720mm
   4096x2160     29.97 +  25.00    24.00    23.98
   3840x2160     29.97*   25.00    23.98    23.98
   1920x1080     60.00    59.94    50.00    29.97    25.00    23.98    60.00    50.04
   1280x1024     60.02
   1280x720      59.94    50.00
   1024x768      60.00
   800x600       60.32
   720x576       50.00
   720x480       59.94
   640x480       59.95    59.93    59.94
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)

dmesg shows nothing out of the ordinary.

xrandr.sh:

# This used to be uncommented, but doesn't cut it anymore with the new setup
#xrandr --output HDMI-0 --off

sleep 0.5

xrandr --output HDMI-0 --primary --mode 3840x2160 --panning 0x0
xrandr --output DP-1 --mode 3840x2160 --right-of HDMI-0

Attempted solutions

Over the years, I've googled several times for similar issues, and I've never really found anything promising. I used to think it was something weird with the old 4K monitor (like a bad EDID), but now that I'm having the same issue with the new monitor I've discarded that suspicion.

I've found a lot of threads about screens failing to resume after suspend (usually fixed with modeset), but in my case there's no real suspend happening, it's simply a screen off/blanking (and it only happens for one of the monitors!). Furthermore, I've also not found any issue similar to mine with respect to the 'race condition'-like nature of the issue/workaround.

1 Answer 1

0

Keep your 'work around' script that gets both monitors the way you want them with the xrandr command. I suggest writing a small udev rule to run your script triggered by the 'wake from power save' kernel event. You can monitor what kinds of triggers your getting by running:

udevadm monitor -u

You can also get info on all possible attributes in the udev rules key format for your monitors by running: udevadm info -a -n /dev/dri/card0

Where card0 is your onboard video card. Do some reading on udev rules: https://linux.die.net/man/7/udev

You typically place a file in /etc/udev/rules.d/

Something that simply contains the following:

KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/opt/xrandr.sh"

Might work, with correct the path to your script that is. Hope this helps.

2
  • How do I figure out what should be the value of card0 on my system?
    – japreiss
    Dec 10, 2021 at 20:31
  • For me on Gentoo I can grep -n3 'card' /var/log/Xorg.0.log and cross check with lshw -C video and xrandr -q however with linux distros using wayland now YMMV
    – turtle
    Dec 11, 2021 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .