Bug#514301: xserver-xorg-video-radeon: ignores existing EDID from ACPI BIOS even when DDC fails

[Nikolaus Schulz]

On Sat, Feb 07, 2009 at 11:19:24AM -0500, Alex Deucher wrote:
> On Fri, Feb 6, 2009 at 9:16 PM, Nikolaus Schulz <microschulz at web.de> wrote:
> > 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.
> 
> You can specify the display size in your config.

That's what I did.

> I'll ask the bios guys if there is a better way of getting the display
> size info for panels without an edid.

Thanks.  IIUIC, the APCI BIOS may offer the _DDC method to retrieve the
EDID, and it seems to me that on my machine, it's the only way to get
it.  (Disclaimer: I only learned about this whole DDC and video BIOS
thing while examing my problem, so forgive me if I'm talking pure BS
here. :-)  So I think X should check if that _DDC method is present in
the BIOS, or just parse /proc/acpi/video/VID/LCD0/EDID, or whatever, but
not miss a complete and valid EDID like it apparently does right now.

Nikolaus