There is a lurking bug in xserver/hw/xfree86/modes/xf86Crtc.c about the use of compat_output. It will show once users start to disconnect crtcs and monitors from outputs.
This stable code is probably unfamiliar to most on the list. Might someone be willing to try these patches ? A summary is here below, a detailed report is in the bugzilla entry. http://bugs.freedesktop.org/show_bug.cgi?id=65210 -------------------------------- There is a lurking bug in xf86Crtc.c about the use of compat_output. The bug is twofold: a use-before-set at initial configuration and a desynchronization of scrn->{monitor, modes} when (re)connecting a monitor. The bug surfaced due to commit 37d956e3ac9513b74078882dff489f9b0a7a5a28 into xserver/hw/xfree86/modes/xf86Crtc.c which presets config->compat_output = -1; This parameter is referenced during initial screen configuration for: 1. scrn->monitor set by xf86SetDDCproperties(scrn, edid_mon), 2. config->compat_output set by SetCompatOutput(config), 3. scrn->modes set by xf86SetScrnInfoModes(scrn). The use-before-set for case 1 results from the video driver callback: xf86InitialConfiguration() calls xf86ProbeOutputModes() which calls into the video driver via (*output->funcs->get_modes)() which callbacks xf86OutputSetEDID() where xf86CompatOutput() dereferences config->output[config->compat_output] with compat_output == -1. Since at this initial stage the compat output can't be known a NULL return from xf86Crtc.h xf86CompatOutput() is a logical solution. Also, xf86SetDDCproperties() must be called after each SetCompatOutput() compat_output change for scrn->monitor and scrn->modes consistency. The first two patches try to stay as close as possible to the code. The third patch guarantees a compat_output in the range of [ -1 .. num_output-1 ] by reorganizing the if-then-else fallback logic. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
