Bug#514301: xserver-xorg-video-radeon: ignores existing EDID from ACPI BIOS even when DDC fails
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@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@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..@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
Reply to: