<div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Your description sounds about right. Since I do see a message (<span style="color:rgb(80,0,80);font-size:12.8px">"</span><u style="color:rgb(80,0,80);font-size:12.8px">Entering energy saver mode</u><span style="color:rgb(80,0,80);font-size:12.8px">") </span>come up on the monitor when I move the mouse as I mentioned before, this does suggest it has been awakened and becomes unrigistered at this point and sees no input anymore (hence the message). All the windows are already moved to the other monitor at this point and the screen saver seems like it has more or less died (though it does prompt for the password and allows me to log in).</div><div class="gmail_default"><br></div><div class="gmail_default">I did what you asked, but it didn't really give any useful info since it normally takes a while for the monitor to fail to come back up (maybe 5 or 10 minutes after I lock the screen even with the sleep time as 1 minutes or so).  I kind of already generated the info you may be seeking in my original post.</div><div class="gmail_default"><br></div><div class="gmail_default">I am wondering if there is some way to just "lock" the setup so that the monitor is always there if it is a registration problem, or change things so the monitor is not unrigestering itself.</div><div class="gmail_default"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 9:55 AM, Thomas Lübking <span dir="ltr"><<a href="mailto:thomas.luebking@gmx.de" target="_blank">thomas.luebking@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Aug 09, 2017 at 11:39:06AM -0400, Greg Gorsuch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Where are the sleep logistics handled? Is it with the X server, the NVIDIA<br>
drivers, the Linux Kernel, or somewhere else? Is it possible to capture the<br>
communications on Windows 10 to identify how it is being handled. I don't<br>
get the feeling it should be that complex to fix or at least implement a<br>
work around since xrander is able to bring the monitor back online.<br>
</blockquote>
<br></span>
It sounds like when you go dpms off, the monitor unregisters and when<br>
you go dpms on, the monitor re-registers.<br>
Then some semi-smart randr daemon kicks in and adjusts the layout, but<br>
does not so when the monitor comes back.<br>
<br>
Try to log the setup in the various modes:<br>
<br>
xset dpms force standby; sleep 10; xrandr --current > ~/randr.standby;<br>
xset dpms force suspend; sleep 10; xrandr --current > ~/randr.suspend;<br>
xset dpms force off; sleep 10; xrandr --current > ~/randr.off; xset<br>
dpms force on<br>
<br>
Also try the behavior on a "naked" X11 server (no desktop session, only<br>
an xterm) to see whether some client or the server adjusts the randr setup.<br>
<br>
Cheers,<br>
Thomas<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Greg Gorsuch</div>
</div>