i810: can't set 1680x1050 mode properly on 965G

[Elvis Pranskevichus]

On Monday December 25 2006 01:35, Keith Packard wrote:
> On Sun, 2006-12-24 at 18:27 -0500, Elvis Pranskevichus wrote:
> > As I said. I can set 1024x768, even 1280x1024. But 1680x1050 on
> > non-modesetting emits clocks or frequencies that monitor can't handle. I
> > use gtf to generate modelines.
>
> You shouldn't need to use GTF; the driver should auto-detect the monitor
> and use DDC to acquire the EDID information which should include the
> native panel resolution. However, I have one 1680x1050 panel in which
> the EDID data is actually wrong -- the sync polarities are incorrect and
> so the monitor does not automatically recognise the mode it asked for.
>
> You should look in the log file for the EDID information and see if it
> detected any.
>

Here's the log for non-modesetting xf86-video-i810-1.7.3 for 1280x1024.

http://el.prans.net/xorg/Xorg.0.log.txt

The interesting part is

(II) I810(0): Currently active displays on Pipe A:
(II) I810(0): 	CRT
(II) I810(0): No active displays on Pipe B.
(==) I810(0): Display is using Pipe A
(--) I810(0): Maximum frambuffer space: 98136 kByte
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/lib/xorg/modules/libddc.so
(II) Module ddc: vendor="X.Org Foundation"
	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Video Driver, version 1.0
(II) I810(0): VESA VBE DDC supported
(II) I810(0): VESA VBE DDC Level 2
(II) I810(0): VESA VBE DDC transfer in appr. 1 sec.
(II) I810(0): VESA VBE DDC read failed
(II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs.

It fails to actually read EDID through DDC! Latest git:modesetting, however, 
does it just fine:

(II) I810(0): EDID for output VGA
(II) I810(0): Manufacturer: VSC  Model: e51d  Serial#: 16843009
(II) I810(0): Year: 2006  Week: 19
(II) I810(0): EDID Version: 1.3
(II) I810(0): Analog Display Input,  Input Voltage Level: 0.700/0.300 V
(II) I810(0): Sync:  Separate  Composite  SyncOnGreen
(II) I810(0): Max H-Image Size [cm]: horiz.: 43  vert.: 27
(II) I810(0): Gamma: 2.20
(II) I810(0): DPMS capabilities: Off; RGB/Color Display
(II) I810(0): Default color space is primary color space
(II) I810(0): First detailed timing is preferred mode
(II) I810(0): redX: 0.640 redY: 0.352   greenX: 0.288 greenY: 0.628
(II) I810(0): blueX: 0.144 blueY: 0.076   whiteX: 0.313 whiteY: 0.329
(II) I810(0): Supported VESA Video Modes:
.....
(II) I810(0): Supported Future Video Modes:
(II) I810(0): #0: hsize: 1680  vsize 1050  refresh: 75  vid: 4019
(II) I810(0): #1: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) I810(0): #2: hsize: 1280  vsize 960  refresh: 60  vid: 16513
(II) I810(0): #3: hsize: 1152  vsize 864  refresh: 75  vid: 20337
(II) I810(0): Supported additional Video Mode:
(II) I810(0): clock: 146.2 MHz   Image Size:  433 x 271 mm
(II) I810(0): h_active: 1680  h_sync: 1784  h_sync_end 1960 h_blank_end 2240 
h_border: 0
(II) I810(0): v_active: 1050  v_sync: 1053  v_sync_end 1059 v_blanking: 1089 
v_border: 0

> > The SAREA width is two times larger than needed (1680 * 2) and that
> > causes output cropping. I don't know where this and the blanks on the
> > sides come from.
>
> no, the sarea data is just the maximum size of the screen, and we make
> it large to allow for RandR resize.

Strange, on 1280x1024 on non-modesetting it gives me

(II) I810(0): [drm] init sarea width,height = 1280 x 1024 (pitch 2048)

-- 
Elvis Pranskevichus <el at prans dot net>