[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Minimal X Config File and Compiz

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 appreciate it.

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 [1].

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.

[1] - 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.

- ajax

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]