Normally the power management on my desktop works as expected: the monitor shuts off after a pre-configured amount of time, and a click of the keyboard or a move of the mouse turns it back on. But very infrequently, X won’t give me my desktop back, even though everything is still running and I can SSH in or Ctrl+Alt+F1 to get to any of my TTYs just fine.
I have tested multiple applications to try to force the failure and It’s most reliably produced running wine. I can reproduce the failure almost 100% of the time running any of the following in wine: An AHK script running in the background; Paint .net 3.5.11; Battle .net desktop client; WoW game client; and Loop hero (GOG version). I’ve tested most recently with wine-staging 5.19 and 6.4, and wine-vanilla 6.0. I even tested wine-vanilla compiled without xinerama or xcomposite support to see if it would change anything. It does not.
Native linux applications don’t seem to have any problem; I tested with The Silent Age running on Steam for Linux and Minecraft and neither caused the monitor to stay off.
This started nearly a year ago on the Cinnamon desktop on Linux Mint 19 using a release of wine-staging 5.x. I can’t remember if it correlated exactly with my video card upgrade, but I did move up to a GTX 1050ti from a GTX 560 around that time. Unfortunately I don’t have any other cards now to try to test with. I’ve been using the official nvidia drivers (Legacy for the GTX 560, then 450 series, now 460.39) the whole time. All other hardware in the system since that time has changed, and I’ve moved from Mint to Gentoo, moving from systemd to openrc in the process. I’ve tried using Gnome Shell, which suffers the same problem. To solve it back then, I just turned off power saving. But I’m not content and I have time, so here we are:
I use this script to force this situation.
#!/bin/bash xset dpms force off sleep 1 xset dpms force on
Under most circumstances, my monitor flickers as expected. If wine is running, it stays off and errors are logged:
$ tail /var/log/Xorg.0.log [ 701.299] (WW) NVIDIA(0): No valid modes for "DFP-1:nvidia-auto-select"; removing. [ 701.299] (WW) NVIDIA(0): No valid modes for "nvidia-auto-select"; removing. $ tail /var/log/messages Mar 24 23:08:46 tz-penguin kernel: [ 701.334661] nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device HDMI-0
In order to bring the monitors back up, I have to run the following:
#!/bin/bash xrandr sleep 1 xrandr --output HDMI-0 --mode 1920x1080
Running just one of the xrandr lines doesn’t wake the monitor - I have to re-find modes and then declare one to use, together, to wake it. Without the initial probe, the error occurs:
`xrandr: Configure crtc 0 failed`
While simultaneously logging an error in Xorg.0.log:
[172868.570] (WW) NVIDIA(0): No valid modes for "NULL"; removing.
Please be aware that I am using nvidia’s recommended way to provide an EDID to a monitor that doesn’t supply one:
$ cat /usr/share/X11/xorg.conf.d/55-fixed-edid.conf Section "Monitor" Identifier "ViewSonic" ## Unlike kernel params, X doesn't use a # known firmware directory, so specify it. Option "CustomEDID" "DFP-1:/lib/firmware/viewsonic-vx2260s-led.bin" Option "IgnoreEDID" "false" Option "UseEDID" "true" Option "PreferredMode" "1920x1080" EndSection Section "Screen" Identifier "ScreenSolo" Device "GTX1050Ti" Monitor "ViewSonic" DefaultDepth 24 EndSection Section "Device" Identifier "GTX1050Ti" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection
The reason I use a firmware file is because the EDID from hardware has a broken header. I am certain the fixed EDID is correct; You can even see in the xorg log that it reads it correctly.
nvidia-bug-report.log.gz (1.2 MB)
I don’t entire understand what’s going on, but my surface level interpretation is that the driver is using data from the monitor to tell if it’s still plugged in even while it’s off, but that fails for some reason, so all video modes are removed because its “unplugged”, and therefore won’t be woken up.
But I don’t see why it isn’t always like this. There is something about running wine in particular, and very infrequently other applications that’s causing monitor DPMS shutoff to be treated differently than normal.