Current Xorg behavior is unfriendly at best

[Adam Jackson]

On Mon, 2007-09-17 at 18:52 -0500, Arthur Pemberton wrote:
> On 9/17/07, Adam Jackson <ajackson at redhat.com> wrote:
> > On Sat, 2007-09-15 at 01:46 -0500, Arthur Pemberton wrote:
> > > Ever since the behavior of having Xorg guess resolutions has been
> > > implemented, I have little to no luck with it.
> > >
> > > Of at least 6 fedora installs I've done since then it has never
> > > guessed a resolution that is comfortable (for lack of a better word)
> > > and on some occasions it has required rebooting into runlevel 3 - not
> > > exactly a problem, but not very friendly. That ranges from desktop to
> > > laptops, native to VM ( Parallels ) and standard to widescreen
> > > displays.
> >
> > I'm missing some details here.  You say it guesses wrong, but don't say
> > what it guesses, or what you would prefer.
> 
> For lack of me knowing how to get the current resolution at the
> console level, coupled with bad memory, I can't say that I remember
> the exact values that it gets wrong. What it gets wrong, is the
> attempted screen resolutions, often using out of range (for LCDs) or
> extreme ( very small or very large) resolutions.

xrandr or xdpyinfo will tell you.

> > I do have an idea for choosing better, but it's really hard to heuristic
> > this properly.  Partly because the X drivers are still limited and can't
> > resize _up_ from whatever it chooses initially.
> 
> I'm not sure that I understand what you're saying here.

I have to guess at an initial screen size.  I can't _know_ what the
physical size in pixels is, because the monitor does not tell me.  It
doesn't even tell me whether "physical size in pixels" is a meaningful
concept for the monitor type, or whether it's a CRT or an LCD, or lots
of other things that would be useful information.  It merely tells me
some modes and sync ranges that it claims it can support, and a hint
about which mode it prefers.

The hint about which mode it prefers is often garbage.  1280x1024 is not
a good mode for a 4:3 monitor.  Your shiny new HDTV will claim to be
1280x720 even though it's physically 1360x768.  And so forth.  So what I
do instead is try to deduce the aspect ratio of the screen, and then go
for the largest mode that will match, preferring the mode the monitor
reports as "preferred" if it matches aspect ratio.  This happens to pick
some really huge resolutions on CRTs sometimes, but I'd rather guess too
large than too small.

The reason I'd rather guess too large is, for any given run of the X
server, the initial mode is also the largest mode in the mode pool, and
is the largest mode you can get for that instance of the X server.  So
the user can RANDR down to the resolution they want - and gdm will
remember it, and set that mode the next time they log in - but you can't
RANDR up.  Also because, really, you can make the UI bigger quite
easily, but shrinking things smaller than a pixel is sort of tricky.

So, like, if I had some heuristic for guessing "oh yeah, that's a CRT",
then I could try to clamp the upper bound of resolutions to, say, no
more than 130dpi or something.  But I'd hate to implement that and then
find someone with a 150dpi LCD that we don't set the native panel size
on just because we don't think pixels get that small.

Does this clarify the tradeoffs at all?

> Still, why does xorg _not_ use what's in xorg.conf just because the
> monitor is off?

If the monitor is off, I can't talk to it, so I can't ask it what it can
do.  Note that this is something of a lie, most monitors made since, oh,
2000, will merely look like they're asleep but will still respond over
DDC if they have a power cord plugged in.

But if I can't talk to it, I'll use what's in the config file.  Do you
have an example of X not doing so?

- ajax