Minimal X Config File and Compiz
ajackson at redhat.com
Wed Sep 13 13:30:50 UTC 2006
David Nielsen wrote:
> tir, 12 09 2006 kl. 14:08 -0400, skrev Jesse Keating:
>> On Tuesday 12 September 2006 13:37, Thomas J. Baker wrote:
>>> Sorry, I should have phrased it better. I know how to enable it by hand.
>>> My question was about the self configuring X and if it was supposed to
>>> be enabling composite/dri/whatever-compiz-needs automatically.
>> A default install for me on i386, I haven't touched xorg.conf other than to
>> change from i810 to intel. I yum installed compiz, restarted X for the intel
>> driver, and used system -> preferences -> more -> Desktop Effects and enabled
>> it. I get compiz goodness.
> Worked entirely out of the box using my r300 based ATI Radeon 9600XT
> card. No changes required. However my monitor isn't correctly detected
> (IBM P92) so there's a slight offset and I believe the resolution is set
> to high, I handled that in the desktop session so it only looks silly
> during boot and gdm.
If you could attach your X log file from startup to a bug, I'd
The issue is that the config file doesn't specify the mode to start in
anymore, so we guess. And the guess ends up being (after some tweaking)
the largest mode advertised by the monitor that matches the monitor's
physical aspect ratio. This is almost always correct for LCDs, but on
CRTs people have widely varying tastes for how large they want a pixel
to be, and CRTs tend to report some pretty huge modes as supported
(1920x1440 has been spotted). Unfortunately there's no way for the X
server to know whether the monitor is a CRT or not .
I'm open to suggestions for better heuristics. Since Gnome is pretty
far from ever having a scalable UI, it might be sensible to modify the
above heuristic to "if multiple advertised modes match the physical
aspect ratio and we're somehow reasonably sure that it's not an LCD,
pick the one that comes closest to 100dpi". It's that reasonably sure
part that's tricky. Alternatively we could get gdm to randr to a
"sensible" size, but that just moves the problem to gdm, plus introduces
a flicker for the resize event.
 - Well, not in base EDID. The DI-EXT extension to E-EDID advertises
a number of factors that, taken together with the base block, could be
used to make a reasonable guess, but the vast majority of CRTs don't
implement E-EDID. I have code to get the full E-EDID info from the
monitor, but no code to parse it out into anything useful, and the one
DI-EXT block I've tested with (Apple 23" cinema display) is almost
completely broken, so I'm not really rushing to get it done.
More information about the fedora-devel-list