Tim Richardson reported on the Debian BTS that nv driver 2.1.5 causes his SyncMaster display to not resume after DPMS sleep. The config and log is available in the Debian bug at the URL above. nv 2.1.3 worked fine. He has a nVidia Corporation G71 [GeForce 7300 GS] rev 161 [10de:01df] Since there were very few intrusive commits between these releases, I asked him to try applying commit b2db7d414400d80a5567d71eed9a7e94f1043a20 (G80: Fix LVDS detection on some laptops) on top of 2.1.3. After testing, he thinks this commit causes the breakage. That's surprising since his board doesn't seem to be a G80. But maybe I am missing something... Anyway, something seem to have broken DPMS resume from sleep between 2.1.3 and 2.1.5. Brice
Yes, I would be extremely surprised if any of the commits between nv-2.1.3 and nv-2.1.5 were actually responsible for DPMS breakage on a G71. If anything were going to affect it, it would be deff2965ef35260b4b7c4bc23718833bec7143b3. How many times did you try DPMS? Are you sure you're not just seeing an intermittent problem? How sure are you that he correctly cherry-picked b2db7d on top of nv-2.1.3?
Created attachment 11913 [details] FIrst of two files changed when looking for the bug (the patch will also be attached)
Created attachment 11914 [details] second of two 2.1.3 files changed by the suspect patch
Created attachment 11915 [details] [review] the patch I applied
My rebuilt 2.1.3 has been running for around a week (rebuilt so as to work with the xserver version of Debian unstable). The sleep/resume problem has not been seen once. Applying the suspect patch almost immediately recreated the problem. I let the monitor sleep for less than one minute. It resumed ok. Then I let it sleep for around 2.5 minutes. It did not resume, instead showing the broad horizontal bands of color. When this happens, I must power-cycle the monitor. Restarting X does not help. This problem always happens when the monitor sleeps for a short while. It is not an intermittent problem. It is the first time I have applied a patch or even built a source package so it is likely that I made a mistake somewhere. I hope the patch file and changed source files help you investigate it further. But whatever I did turns 2.1.3 from good to bad. The monitor is a Samsung 930BF. It is driven via a digital signal. Please let me know if I can provide further help.
Hi. How can I help further? So far the conclusion was that this bug was impossible because the patch proved to cause the problem could not cause the problem because it is supposed to affect hardware different to my video card. This is a very convincing argument, except that when I applied the patch to a good version, I clearly saw the problem reappear. There were questions about whether I correctly applied the patch, which is why I provided some attachments. Would you like me to take photos or make a small movie and upload it to youtube? I very much want to file a useful bug-report, but with status "Needinfo" I feel like I need to do something more.
Oh, I forgot this was still NEEDINFO. As I said, I would be extremely surprised if that commit affected G71, but I'll move this back to NEW and give it a try at some point. You didn't change xorg.conf between your tests, did you?
xf86-video-nv has been officially unmaintained for a bit now, and we are closing all -nv bugs. If your problem was not addressed, and -nv is still broken, please try xf86-video-nouveau. Thank you.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.