kms howto - is there one?

Felix Miata mrmazda at earthlink.net
Fri Mar 19 20:32:27 UTC 2010


On 2010/03/19 15:25 (GMT-0400) Adam Jackson composed:

> On Fri, 2010-03-19 at 15:22 -0400, Adam Jackson wrote:

>> On Fri, 2010-03-19 at 14:58 -0400, Tom Horsley wrote:

>> > On Fri, 19 Mar 2010 14:01:07 -0400

>> > Adam Jackson wrote:

>> > > Use gtf(1) to generate mode timings for CRTs, and cvt(1) for LCDs.

>> > So here's a presumptuous question :-).

>> > If gtf and cvt ship as part of X, and they can turn a human
>> > meaningful request for size and HZ into a X mode line,
>> > then why on God's green earth can't X accept a mode described
>> > in terms of size and HZ instead of a hieroglyphic mode line?

>> No one's written the code to do it.

I doubt that's true; just that code got left behind in the transition to KMS.
For years I've been running on DDC/EDID absent displays, with xorg.confs with
the following specifications:

1-HorizSync
2-VertRefresh
3-DisplaySize
4-Modes
[No modelines]

Until xrandr was born, usually this was all that was required to achieve up
to 2048x1536, while in some cases NoDDC needed to be added. At some point
after was necessitated adding:

5-PreferredMode

Now as of F13, considerably more preconfiguration is required by those with
no DDC/EDID who are not accepting of a lowfi resolution ceiling necessary
only for _some_ (fixed frequency, and small) displays that are 15 or more
years old.

>  PGA though.

> Also because - and this is truly, truly depressing - there's no
> programmatic way to tell the difference between a CRT and an LCD from
> the host side.  Thanks EDID!

Why should it matter if HorizSync & VertRefresh ranges and a mode catalog are
provided via a config file?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/


More information about the test mailing list