On Sat, Feb 07, 2009 at 11:19:24AM -0500, Alex Deucher wrote: > On Fri, Feb 6, 2009 at 9:16 PM, Nikolaus Schulz <microsch...@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 <microsch...@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 > >> > |.........@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
