i810: can't set 1680x1050 mode properly on 965G
el at prans.net
Sun Dec 24 23:19:28 PST 2006
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.
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
(II) I810(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1089
> > 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>
More information about the xorg