Monitor with EDID file becomes "unplugged" after DPMS off; but only while wine is running

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.

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:

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"

Section "Screen"
    Identifier     "ScreenSolo"
    Device         "GTX1050Ti"
    Monitor        "ViewSonic"
    DefaultDepth    24

Section "Device"
    Identifier     "GTX1050Ti"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"

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.

By defining the custom edid in the monitor section, you’re relying on undefined behaviour. According to the manual, nvidia driver options have to be specified in either the device or screen section. Furthermore, having an xorg.conf in the system config directory is not advisable. Please try this:
delete /usr/share/X11/xorg.conf.d/55-fixed-edid.conf
create /etc/X11/xorg.conf.d/55-fixed-edid.conf containing only

Section "OutputClass"
    Identifier     "nvidia-edid"
    MatchDriver    "nvidia-drm"
    Driver         "nvidia"
    Option         "CustomEDID" "HDMI-0:/lib/firmware/viewsonic-vx2260s-led.bin"

Maybe this helps, though I don’t know how only wine triggers this.

I took this advice prepared to feel very stupid if this fixed it. I’m almost relieved it didn’t. One thing is added to the logs when the monitor turns off, and nothing else changes:

[   854.469] (II) NVIDIA(0): NoScanout X screen configured with resolution 640x480
[   854.469] (II) NVIDIA(0):     (default)

Though paintdotnet proves to be an unreliable test vessel, leaving the monitor stuck off on only two of four back-to-back tests. All of the other programs mentioned before still cause monitor failure consistently, and even semi-reliably one more time after the wineserver exits, but now with only native apps running I can’t make it happen at all.

If there’s no monitor, the nvidia driver switches to a virtual screen with default 640x480 resolution. Previously, wine had a problem with this apparent on hybrid setups, the workaround for me was to set a higher virtual resolution, xorg.conf

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option         "AllowEmptyInitialConfiguration"

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    SubSection     "Display"
        Virtual     1920 1080
        Modes      "1920x1080"

Don’t know if that helps in your specific case.

That’s interesting to find out! Sadly, my problem persists.