Re: kms howto - is there one?

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

 



On Fri, 2010-03-19 at 08:09 -0400, Felix Miata wrote:

> > In fact, even the Modes line may not be necessary, looking at the X log.
> 
> Without both modes and modelines in xorg.conf, only the anachronistic
> 1024x768 and worse are available modes. Xorg.0.log lies. The "probed" modes
> above 1024x768 are not there unless present in xorg.conf, unless I'm using
> mga, or Factory, Knoppix, Lucid, Cooker or previous Fedora releases.

But the Mode you wind up using is 2048x1536_60.00 , so I don't see where
having 2048x1536 listed in your Modes line helps. *shrug*

> > (Although I note "VertRefresh  56-61" - don't you get headaches?!)
> 
> The only headaches I get are from having to play with the device's physical
> controls every time another driver comes up with yet another set of
> auto-generated mode specifications that haven't been entered in the device's
> memory, resulting in errant sizing and/or positioning of the output. By
> limiting refresh to that narrow range the auto-generation usually matches a
> generic spec that's already in the device's memory, resulting in correct
> centering and sizing of the output.

...at 60Hz. On a CRT. Yikes. 

> To be clear, my displays get subjected to many different gfxcards, and many
> different operating system brands (DOS, Windows & OS/2, in addition to the
> previously mentioned major distros) and versions, from a bunch of different
> computers, pretty much at random. There's no way any of my displays has
> enough memory for every mode it's ever been subjected to. This is good,
> because it tests the desktop environment's ability to cope with a variety of
> hardware, quite unlike modern LCDs with their working DDC/EDID virtually
> forcing their use only with a single native mode.
> 
> > This would not be a problem on any monitor which correctly communicates
> > its correct HorizSync range to the system. In the case where the monitor
> > doesn't have functioning EDID or DDC, *every* choice X can make is
> > 'wrong' in some sense, so it doesn't make much sense to complain about
> > the particular wrongness of the particular choice we go with.
> 
> Again I think you're missing the major point that this is _new_ behavior.
> Only in F13 (so far, using intel & radeon at least, but not when using mga)
> does what worked previously work no longer. Until now, and for those for whom
> lowfi resolution is not acceptable, explicit modelines in xorg.conf hadn't
> been necessary with broken/missing DDC/EDID for many many moons.

And as I said, that behaviour is equally 'wrong'. The other distros
you've tried probably aren't using kernel modesetting, hence the
differing behaviour.

> And BTW, actually switching modes without restarting X must be done by typing
> xrandr commands. Attempting to select another mode from krandrtray corrupts
> everything such that CAD or the reset button (or I suppose remote login) are
> required to recover.

I don't know anything about krandrtray, I use GNOME. Actually I think
krandrtray was written by one of Mandriva's Brazilian guys :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux