Bug 19854

This looks like http://bugs.gentoo.org/249680 , where xscreensaver does the wrong thing on outputs without a crtc.  Try the patch to xscreensaver in that bug and if it fixes it, take it up with the xscreensaver maintainer.

Yep, the bug seems the same (I haven't had the time to compile xscreensaver yet), however I think that nouveau may be at fault here:

1) X starts whith only LVDS connected
2) XrandR reports no CRTCs for VGA-0 output. I'd expect it to report CRTCs 0 and 1, as both of them can drive the output when it is connected (and this is what it did before, IIRC)
3) xscreensaver fails.

If at this point one runs xrandr --addmode VGA-0 640x480, the server crashes with
Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4ebd56]
1: /usr/bin/X(xf86SigHandler+0x39) [0x47f949]
2: /lib/libc.so.6 [0x7f637896ef80]
3: /usr/lib/xorg/modules/drivers//nouveau_drv.so [0x7f63773c2fe6]
4: /usr/bin/X [0x4adfbb]
5: /usr/bin/X(RROutputAddUserMode+0xa4) [0x525d64]
6: /usr/bin/X(Dispatch+0x364) [0x44c2d4]
7: /usr/bin/X(main+0x45d) [0x432bcd]
8: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f637895b1a6]
9: /usr/bin/X(FontFileCompleteXLFD+0x269) [0x431fa9]

Fatal server error:
Caught signal 11.  Server aborting

inside nv_output_mode_valid (I think nv_encoder is NULL at this point).

When a display is connected to VGA-0, xrandr reports CRTCs: 0 1 for VGA-0, and everything works as it should (xscreensaver included). If the display is disconnected, everything keeps working (and xrandr --addmode no longer crashes the server), the CRTCs: 0 1 line remains in the VGA-0 output of xrandr.

So, I don't know for sure if it is wrong to report no CRTCs for a disconnected output, but the fact that the reported CRTCs change after an external display is plugged and unplugged again, and the related crash of the Xserver seems to imply that there is a bug with this. I've changed the description accordingly.

(In reply to comment #2)
> Yep, the bug seems the same (I haven't had the time to compile xscreensaver
> yet), however I think that nouveau may be at fault here:
> 
> 1) X starts whith only LVDS connected
> 2) XrandR reports no CRTCs for VGA-0 output. I'd expect it to report CRTCs 0
> and 1, as both of them can drive the output when it is connected (and this is
> what it did before, IIRC)
> 3) xscreensaver fails.
> 
> If at this point one runs xrandr --addmode VGA-0 640x480, the server crashes
> with

...
 
> inside nv_output_mode_valid (I think nv_encoder is NULL at this point).
> 
> When a display is connected to VGA-0, xrandr reports CRTCs: 0 1 for VGA-0, and
> everything works as it should (xscreensaver included). If the display is
> disconnected, everything keeps working (and xrandr --addmode no longer crashes
> the server), the CRTCs: 0 1 line remains in the VGA-0 output of xrandr.
> 
> So, I don't know for sure if it is wrong to report no CRTCs for a disconnected
> output, but the fact that the reported CRTCs change after an external display
> is plugged and unplugged again, and the related crash of the Xserver seems to
> imply that there is a bug with this. I've changed the description accordingly.

Agreed that the crash is a bug, and the <never plugged> vs <plugged>,<unplugged> inconsistency is an issue.  Can you confirm the following patch resolves both these problems?

As for 2) above, while in the VGA-0 case listing CRTCs when disconnected is possible, it really isn't for DVI-I until a monitor is plugged (as the available CRTCs vary depending on whether it's an analogue or digital connection).  I think I'd prefer to retain a consistent approach across all connector types, and get other things that make bad assumptions get fixed sooner :-) (is there any real-world case where the usefulness of providing a crtc list for unused connectors exceeds the problem that it won't work half the time (DVI)?)

Created attachment 22665 [details] [review]
Patch against addmode crash, add consistency for outputs unplugged at runtime

(In reply to comment #3)
Sorry for the delay...

> Agreed that the crash is a bug, and the <never plugged> vs
> <plugged>,<unplugged> inconsistency is an issue.  Can you confirm the following
> patch resolves both these problems?
> 
It solves the crash, but I can't test with an external display unless I carry the laptop to work, which I'd prefer not to do again... maybe there is someone else who can reproduce the bug and test the fix?. If not, I'll try to do it when I can.

> As for 2) above, while in the VGA-0 case listing CRTCs when disconnected is
> possible, it really isn't for DVI-I until a monitor is plugged (as the
> available CRTCs vary depending on whether it's an analogue or digital
> connection).  I think I'd prefer to retain a consistent approach across all
> connector types, and get other things that make bad assumptions get fixed
> sooner :-) (is there any real-world case where the usefulness of providing a
> crtc list for unused connectors exceeds the problem that it won't work half the
> time (DVI)?)
> 
I don't know, the only known problem is with xscreensaver which is arguably buggy. OTOH if there are cases where a CRTC can't drive some displays, it is correct to simply return an error at modesetting time, no? (I took a look at the randr spec, but may be misremembering it). In other words, I'm fine with whatever you decide to do, I don't know better. :-)

So, I've pushed the crash fix, but not the state resetting thing.  After testing it, it seems xrandr gets very upset (even just running xrandr --verbose) with CRTCs disappearing (although this is probably valid behaviour) and dies with a fatal error of "cannot find crtc 0x..", so I'll stick with the crap lingering CRTC behaviour, rather than break xrandr whenever someone disconnects an output.

As for bailing out at modeset time, yes, this might be possible, but it relies on the xserver failing gracefully, and the user app coping with a failure for which it can determine no good reason, which I think is a higher standard to expect than getting the application to query what display is connected before it sets out on its modesetting journey.

Happy for this bug to be resolved as fixed?

(In reply to comment #6)
> So, I've pushed the crash fix, but not the state resetting thing.  After
> testing it, it seems xrandr gets very upset (even just running xrandr
> --verbose) with CRTCs disappearing (although this is probably valid behaviour)
> and dies with a fatal error of "cannot find crtc 0x..", so I'll stick with the
> crap lingering CRTC behaviour, rather than break xrandr whenever someone
> disconnects an output.
> 
> As for bailing out at modeset time, yes, this might be possible, but it relies
> on the xserver failing gracefully, and the user app coping with a failure for
> which it can determine no good reason, which I think is a higher standard to
> expect than getting the application to query what display is connected before
> it sets out on its modesetting journey.
> 
> Happy for this bug to be resolved as fixed?
> 
Yes, thank you. If it turns out this is not really correct it can be reopened again.