In message <16860.26586.372916.963882@bonnet.wsrcc.com>, "Wolfgang S. Rupprecht
" writes:
>
>Steven M. Bellovin writes:
>> Yes, it has 1600x1200 resolution; it's a 20.1" display.
>> ... sku=320-1578
>
>http://accessories.us.dell.com/sna/ProductDetail.aspx?TabPage=techspecs&sku=32
>0-1578&c=us&l=en&cs=19&page=external
>
>I just love the marketing phrase "up to XXX" and a long list of
>resolutions.  LCD's have one and only one pixel pitch.  The fact that
>they list all those other resolutions leaves me wondering which one is
>real and which ones are interpolated.

Ah, marketing...
>
>> What I don't understand is the phrae "Supported Future Video Modes".
>> Does that mean that VESA is considering the mode, but hasn't endorsed 
>> it yet?  And what, if anything, in the X suite should know about it?
>
>My two CRT monitors here both run in the resolutions mentioned in the
>"future modes".  I don't think the "future" tag in and of itself is
>the kiss of death.
>
>(II) MGA(0): Manufacturer's mask: 0
>(II) MGA(0): Supported Future Video Modes:
>(II) MGA(0): #0: hsize: 640  vsize 480  refresh: 85  vid: 22833
>(II) MGA(0): #1: hsize: 800  vsize 600  refresh: 85  vid: 22853
>(II) MGA(0): #2: hsize: 1024  vsize 768  refresh: 85  vid: 22881
>(II) MGA(0): #3: hsize: 1280  vsize 1024  refresh: 85  vid: 39297
>(II) MGA(0): #4: hsize: 1600  vsize 1200  refresh: 75  vid: 20393
>...
>
>
>What I needed to do at one point was widen the default V and H clock
>ranges (after hunting them down in the manufacturer's manuals).  After
>that X had no qualms about using the future modes.  The reluctance was
>simply caused by it not wanting to exceed the compiled-in default H
>and V frequency ranges.
>
>        Section "Monitor"
>        ...
>	# Sony 20seII
>        HorizSync       30-96
>        VertRefresh     48-160
>	# # hitachi Superscan Supreme 803
>	# HorizSync       31-115
>	# VertRefresh     50-160
>
>And yes, I agree X really needs to do better automating this.  One
>shouldn't have to become an XF86Config file expert just to get X
>working correctly.  Luckily Xorg does a much better job of
>autoconfig-ing things (it even managed to squeeze a few more pixels
>out of my Hitachi monitor, cranking it up to 1920x1440.)

I haven't found any detailed manual; the Dell web page says that this 
monitor can handle "Max Sync Rate (V x H): 76 Hz x 80 kHz".  X 
recognized that.  (Another page gives the minimum and maximum for those 
values; again, X found them properly.)  The X log says

	"Not using mode "1600x1200" (no mode of this name)"

Where does it get the table of modes?

Poking through the X source, I see a file etc/vesamodes which  
does list 1600x1200 @60 Hz, with hsync of 75 Khz.  That's certainly 
compatible with what the log file already knew about the monitor.  
(Btw, that file refers to VESA standards from 1998 -- hardly new!)
There's another file xf86cfg/vidmode.c that lists a table modes; that 
mode is listed there, too.  So I don't understand where the problem is 
coming from...  Is the problem the vesa driver?  If so, why, given that 
this is an old VESA mode.

I said earlier that X confused me.  That's part of it -- more, I think, 
is that graphics hardware confuses me terribly.  I understand some of 
the physical realities of scans on CRTs and an analog cable.  I would 
think that LCD monitors with DVI cables could behave more -- well, 
"rationally" is the word I'd use, from my perspective as a software 
guy...

X has made a lot of progress; 4.4.0 is much easier to configure than 
older releases.  Most of the last few systems I've built have just 
worked, without the arcana that used to be necessary.  But I never know 
when I'm going to run into something like this...  (When I configured 
the system, I worried about the SATA controller and the Ethernet 
controller.  I thought that X with an ATI controller would just 
work....)

It sounds like what I should try is (a) the ModeLine that Christos 
suggested, but with 162 for that first magic number, and then (b) try 
Xorg.  (Query: if i do use xorg, do I need to rebuild anything in 
pkgsrc?  Why is X11_TYPE=xorg necessary?)

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb