On Tue, Dec 08, 2009 at 03:52:27PM -0800, Peter Hutterer wrote: > Xorg +xinerama crashes immediately due to whacky dependency between Xinerama > and RandR12. The latter doesn't initialize if Xinerama is enabled, but if > only one screen is found, Xinerama is disabled again and RandR12 tries to > access data it never initialized. > > Dependency chain is: > - ProcessCommandLine sets noPanoramiXExtension to FALSE > - xf86RandR12Init() is a noop > - PanoramiXExtensionInit sets noPanoramiXExtension to TRUE > - xf86RandR12CreateScreenResources tries to use the devPrivates key it never > initialized. > > This hack checks if the key was initialized if noPanoramiXExtension is TRUE. > If not, re-initialize RandR12, this time for reals. > > X.Org Bug 24627 <http://bugs.freedesktop.org/show_bug.cgi?id=24627> > > Signed-off-by: Peter Hutterer <[email protected]> > --- > > Don't know if there are any side-effects of doing this. > > hw/xfree86/modes/xf86RandR12.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c > index 6ea9d26..dd80ee0 100644 > --- a/hw/xfree86/modes/xf86RandR12.c > +++ b/hw/xfree86/modes/xf86RandR12.c > @@ -767,6 +767,8 @@ xf86RandR12CreateScreenResources (ScreenPtr pScreen) > /* XXX disable RandR when using Xinerama */ > if (!noPanoramiXExtension) > return TRUE; > + else if (!xf86RandR12Key) > + xf86RandR12Init(pScreen);
This makes me nervous because it starts calling a big chain of ScreenInit-style functions at CreateScreenResources time. I can't find any concrete examples of things that would fail, but it perturbs the init order pretty drastically, but only in obscure Xinerama cases. Would it be acceptable to just bail out without doing anything if (!xf86RandR12Key)? > #endif > > config = XF86_CRTC_CONFIG_PTR(pScrn); > -- > 1.6.5.2 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
