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

[Alex Deucher]

On Thu, Feb 5, 2009 at 9:22 PM, Nikolaus Schulz <microschulz at web.de> wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.9.0-1+lenny4
> Severity: normal
>
> Hi,
>
> first, I'm filing this bug against the radeon driver, but I'm not sure if it's
> a driver issue or a problem of the X server.
>
> 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.

Alex