I was on NVIDIA version 410 and decided…ahh why not upgrade to the latest driver. I had a look in my Additional Drivers under Software & Updates and decided to download and install version 430
Since this update and after a reboot, the following bug exists:
As the screen under power settings is set to blank after 5min (which always has been this way by the way!)
The screen does not wake up after i move the mouse or press keys on the keyboard. It says “cable not connected”
I have to then press the reset button on my PC since there is NO way to get my screen back.
I know that this happens for a fact as i attached a second screen simulaneously on the DVI port and after i try waking up the screen, it does not wake up the original screen (since it says no cable connected) it only wakes up this second DVI-port screen.
As i said, and im going to repeat this:
This has never happened on version 410.
This has happened and was tested on version 415, 418 AND now 430!! (i thought at least by version 430 this problem would be picked up by someone, but clearly not)
Can you please revert back to whatever changes you did so that the screen can wake up properly from “blanking” because this is very annoying if i want to upgrade to a newer display driver.
inside the OutputClass section of /usr/share/X11/xorg.conf.d/10-nvidia.conf returns the driver to the previous behaviour, if not, check if setting it to “true” does what you want.
Thanks for that but it did not fully work as intended.
My findings:
I tried with “false” as you stated. It did not work, and did the same thing.
I tried with “true” the login screen came back after it locked and after moving the mouse, however after entering password to login, the screen disconnected and said no signal again. I had to ctrl+alt+L to re-lock (behind the scenes) and then the screen appeared so that i can safely reboot and login again.
I have now reverted back to 410. please can you find a permanent solution for this? I cant be the only one with this issue.
Sorry, missed your previous post.
This looks like some completely different issue.
You have one monitor connected via DVI and one on HDMI. The HardDPMS option is for DisplayPort monitors not waking up so it’s a bit puzzling why this had an effect in your case.
Which DE are you using, I presume Gnome?
The problem you’re running into is that after login, the user Xserver starts but doesn’t get permission on the gpu so it runs in fbdev framebuffer and then everything behaves weird.
Two things to try:
remove ‘quiet splash’ from kernel command line, check if behavior changes and create a new nvidia-bug-report.log
change from gdm to lightdm (sudo apt install lightdm), check if behavior changes and create a new nvidia-bug-report.log
Looking at the logs, a second xserver is spawned which doesn’t get permission on the drm device so runs in fbdev mode. XFCE explains the permissions problem, that was some bug introduced in newer versions but this doesn’t explain why a second xserver is started at all when using lightdm, only gdm would do this. Did you switch user when creating the log?
No i didnt switch users at all. Only one user logging on, from locking the screen, i move mouse to get the screen which i do and then i login under the same username.
Aligning your description with what I can see in the logs, probably this is happening:
log in, session starts
lock screen
unlock screen, log in again
instead of returning to the already running session, lightdm starts a new session running on fbdev
Still wondering why this is happening and only with driver >410. Did you check what happens without ‘quiet splash’?
Please check if you can use ctrl+alt+f7 to return to the previous session or if that stopped.
Please attach /var/log/lightdm/lightdm.log after logging in the second time.
Sorry for such a long wait. I was going to do the follow-up tests now but i wanted to find out if the latest driver will make a difference first.
So i went ahead and tried Version 440 (Open Source) and voila, no more issues.
Just note that i tried every version between (not including) 410 - 440 (Proprietary & Open Source) and i got the same issue.
But it seems the problem was somehow picked up and fixed in 440.
Also note that the current kernel working with this is: 4.15.0-72-generic
thank you!