On Thu, 2010-02-25 at 10:43 +0100, Michel Dänzer wrote: > On Tue, 2010-02-23 at 09:25 -0800, Keith Packard wrote: > > On Tue, 23 Feb 2010 15:02:40 +0100, Brice Goglin > > <[email protected]> wrote: > > > See some debugging in > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554450#31 > > > > > > Does this ring any bell ? > > > > yeah, this makes sense -- the compat_output has recently been redefined > > to be the same as the 'primary' output, and that output may well be > > turned off, in which case you'd get a crash looking for the crtc > > attached to it. > > > > Fixing this will require reviewing all uses of compat_output and > > ensuring that they check for a NULL crtc.
This (that compat and primary are the same) isn't true in xserver master; that patch never got merged, and I kinda want it not to yet. I eventually backed it out of Fedora because it kept exposing nasty crash cases. In particular there are times early in xf86 init where the ScrnInfoRec doesn't yet point back to the ScreenRec, so you can't set DIX state (the primary) when setting DDX state (the compat). Ick ick ick. However, even today, you shouldn't be able to set a disconnected output as primary. > Unfortunately that doesn't seem to work well in all cases either, see > http://bugs.freedesktop.org/show_bug.cgi?id=24532#c3 and following > comments (though maybe the semantics for when there's no compat > output/CRTC could be improved from that patch). > > I think the ideal solution would be to make sure the compat output > always has a CRTC associated with it. Of course if that isn't always > possible, something like the above is needed as a fallback anyway. But I > think at least for scenarios like in the bug report above it should be > possible. Gamma operates on CRTCs, not outputs. The right thing for it to pick is "the CRTC attached to the primary output if it exists, else the first CRTC". - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
