Continuous fake monitor connection/disconnections are reported by the 310 and newer drivers

I use nvidia-drivers on a fairly up to date 64 bit Linux system. Since upgrading to a driver newer then 310 I observed that X was using a lot of CPU. It took me a while to find out that this was caused somehow by the nvidia-driver which was reporting continuously monitor connections/disconnections. It seems realy strange so I created a video of the output of xrandr. Here it is

Should I file a bug report for this?

Extra info: I have a GeForce GTX 260 connected to a DVI monitor. Sometimes after booting the monitor is not correctly detected (the monitor doe not receive any input) although nothing else is plugged in the video card.

I tried Option “UseHotplugEvents” “false” without any success since this behavior would appear again when any vdpau enabled applications would run.

I’ve managed to solve this using this option (DFP-1 is the output at which the monitor is connected)

Section "Screen"
   Option         "ConnectedMonitor" "DFP-1"

It’s pretty stupid though that the driver behaves this way. I wasted a day of my free time untill I’ve found this option.

Can you please attach an nvidia-bug-report.log.gz (rename it to .jpg to work around a forum bug). This is the first that any of us have heard of this problem, so it’s pretty surprising. Do yo have a different graphics card you could try? Also, you said you upgraded the driver: what driver were you using previously? Does the problem still occur with 313.18?

Previously I was using 295.75. I think this issue appeared first in the > 300 driver versions since I see that this is when RandR hotplug events were introduced

As I said in my previous post I have this strange problem with my card that sometimes even when booting (and I mean the BIOS menu here) the wrong output is used (the monitor connected trough DVI reports no input and I don’t want to use RGB). The card has 3 physical outputs DVI, RGB, HDMI (from left to right while looking at the card). Another hint: this usually happens when rebooting and not when booting after a power off. Anyway since using the ‘ConnectedMonitor’ option when X goes up I always have output on the monitor so that makes me think that the connection auto detection has some issues (hardware or software).

I’ll attach the bug report log later since I don’t have access to it now. I don’t have a different graphics card that I could try. Anyway besides this bug the 313.18 driver which I’m using now seems to perform much better then the old 295.75 in everyday use like composited DE, hardware accelerated flash and playing videos using VDPAU.

I’ve attached the nvidia-bug-report.log.gz to the main post of this thread.

Did the data in the bug report provide any hints on what could be wrong with the connection detection?

Your symptoms really sound like there is an electrical problem on your graphics board that is causing these spurious hotplug events. I.e. the fact that the BIOS is confused about what is connected means that it’s not just the driver that thinks things are being plugged and unplugged continuously. The fact that the 295.* drivers didn’t report hotplug events probably explains why it wasn’t causing a problem before.

If you can connect to the system remotely via SSH, do you see the hotplug messages stop if you unplug the monitor?

I ran the following tests:

  1. ssh to the machine and run ‘tail -f /var/log/Xorg.0.log’ (output is a sign that fake connections are detected)
  2. Remove the ‘ConnectedMonitor’ option from xorg.conf
  3. Restart X
  4. Observe the fake connection detection (it does not always start but a good way to trigger the behavior is to start a VDPAU enabled application - in my case mythfrontend)
  5. Switch to text mode (Ctrl+Alt+F1) the connection detection stops
  6. Switch back to X the connection detection starts again (sometimes only after running VDPAU application)
  7. Disconnect the monitor the connection detection stops
  8. Connect the monitor again the connection detection starts again (with the same observation regarding the VDPAU application)

I could agree with you that it could be a hardware issue. Any ideas what I could try to fix this? But anyway since the ‘ConnectedMonitor’ option works for me I’m pleased with this solution. This is a desktop machine so monitor output does not changed that often.

But judging by the fact that this is triggered most often when a VDPAU enabled application is ran I could suspect an issue with the driver itself but only you as a developer could confirm or infirm this.

Anyway thanks for your feedback and if you think I could provide more information feel free to ask.