Bug#514301: xserver-xorg-video-radeon: ignores existing EDID from ACPI BIOS even when DDC fails
Nikolaus Schulz
microschulz at web.de
Fri Feb 6 18:16:09 PST 2009
On Fri, Feb 06, 2009 at 08:22:11PM -0500, Alex Deucher wrote:
> On Thu, Feb 5, 2009 at 9:22 PM, Nikolaus Schulz <microschulz at web.de> wrote:
> > On my Thinkpad T42 laptop, the builtin LCD display apparently doesn't support
> > DDC, see:
> >
> > luigi[tmp] sudo get-edid
> > get-edid: get-edid version 1.4.1
> >
> > Performing real mode VBE call
> > Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
> > Function supported
> > Call successful
> >
> > VBE version 200
> > VBE string at 0x11110 "ATI MOBILITY RADEON 7500"
> >
> > VBE/DDC service about to be called
> > Report DDC capabilities
> >
> > Performing real mode VBE call
> > Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
> > Function supported
> > Call successful
> >
> > Monitor and video card combination does not support DDC1 transfers
> > Monitor and video card combination does not support DDC2 transfers
> > 0 seconds per 128 byte EDID block transfer
> > Screen is not blanked during DDC transfer
> >
> > Reading next EDID block
> >
> > VBE/DDC service about to be called
> > Read EDID
> >
> > Performing real mode VBE call
> > Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
> > Function supported
> > Call failed
> >
> > The EDID data should not be trusted as the VBE call failed
> > Error: output block unchanged
> > luigi[tmp]$ sudo ddcprobe
> > vbe: VESA 2.0 detected.
> > oem: ATI MOBILITY RADEON 7500
> > memory: 32704kb
> > mode: 320x200x32k
> > mode: 320x200x64k
> > mode: 320x200x16m
> > mode: 1600x1200x256
> > mode: 640x400x256
> > mode: 640x480x256
> > mode: 640x480x32k
> > mode: 640x480x64k
> > mode: 640x480x16m
> > mode: 1600x1200x32k
> > mode: 800x600x256
> > mode: 800x600x32k
> > mode: 800x600x64k
> > mode: 800x600x16m
> > mode: 1600x1200x64k
> > mode: 1024x768x256
> > mode: 1024x768x32k
> > mode: 1024x768x64k
> > mode: 1024x768x16m
> > mode: 1280x1024x256
> > mode: 1280x1024x32k
> > mode: 1280x1024x64k
> > mode: 1280x1024x16m
> > edid:
> > edidfail
> > luigi[tmp]$
> >
> > I have tried get-edid with various controller numbers because, if I read
> > Xorg.0.log correctly, the LVDS doesn't map to controller #0, but to no
> > avail.
> >
> > However, there *is* a valid EDID available from the ACPI BIOS,
> > accessible in /proc/acpi/video/VID/LCD0/EDID, but it is ignored:
> >
> > luigi[tmp]$ hd /proc/acpi/video/VID/LCD0/EDID
> > 00000000 00 ff ff ff ff ff ff 00 24 4d 55 0a 00 00 00 00 |........$MU.....|
> > 00000010 00 0e 01 03 80 1e 17 78 ee ee 91 a3 54 4c 99 26 |.......x....TL.&|
> > 00000020 0f 50 54 21 08 00 01 01 01 01 01 01 01 01 01 01 |.PT!............|
> > 00000030 01 01 01 01 01 01 64 19 00 40 41 00 26 30 18 88 |......d.. at A.&0..|
> > 00000040 36 00 30 e4 10 00 00 18 00 00 00 fc 00 54 68 69 |6.0..........Thi|
> > 00000050 6e 6b 50 61 64 20 4c 43 44 20 00 00 00 fc 00 31 |nkPad LCD .....1|
> > 00000060 30 32 34 78 37 36 38 0a 20 20 20 20 00 00 00 00 |024x768. ....|
> > 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa |................|
> > 00000080
> > luigi[tmp]$
> >
> > I see no reason why the X server (or the driver, who ever is responsible)
> > shouldn't check the ACPI BIOS if DDC fails, especially as DDC failures seem to
> > be not uncommon with laptop panels.
> >
> > I have worked around my problem by manually feeding the ACPI EDID to parse-edid
> > and copying the result to xorg.conf, see below. xrandr still thinks the
> > display has zero width and height, but xdpyinfo and Xorg.0.log look fine
> > AFAICT. Let me know if you need more information.
>
> The driver is able to to get the panel timings out of the bios lcd
> info table, so even if there is no panel edid, the panel will still
> work properly. I suspect the ACPI edid is generated from the lcd info
> table anyway.
Hmm, I guess that depends on how you define "properly working". It was
working, yes, but properly? At least it didn't get the display size and
dpi right, but defaulted to standard 96 dpi. Which wasn't a horrible
failure, but still.
Nikolaus
More information about the xorg-driver-ati
mailing list