On my Acer TravelMate 8100 laptop with Mobility X700 the display dimensions are not detected by the X server, and the DPI is therefore not set correctly (if I not manually specify DisplaySize). However, ddcprobe lists the dimensions.
Created attachment 12143 [details] Xorg.0.log (using DDCMode and IgnoreEDID)
Created attachment 12144 [details] output from ddcprobe
We aren't yet able to extract the physical size info from the bios tables for LVDS panels yet. I'm hoping we will be able to get this sorted out with ATI/AMD soon now that they are more receptive to open source.
I'd like to add that Xorg 7.3 doesn't even respect me setting the display sizes via the xorg.conf. I've always had DisplaySize set in my xorg.conf for both of my monitors but since the upgrade to 7.3 I have to force Xorg to using 130dpi, else it'll use its default of 96dpi and calculate ridiculous monitor sizes based on that.
(In reply to comment #4) > I'd like to add that Xorg 7.3 doesn't even respect me setting the display sizes > via the xorg.conf. I've always had DisplaySize set in my xorg.conf for both of > my monitors but since the upgrade to 7.3 I have to force Xorg to using 130dpi, > else it'll use its default of 96dpi and calculate ridiculous monitor sizes > based on that. > This is fixed in xserver git. See bug 12474. You can also use xrandr --fbmm to override the dpi.
(In reply to comment #3) > We aren't yet able to extract the physical size info from the bios tables for > LVDS panels yet. Perhaps I am misunderstanding, but why is it necessary to extract the physical size from the bios tables when it is being correctly reported in the monitor EDID information? Might it make sense to use the EDID information until it is possible to read the size from the bios tables? (Depending on the predicted time to get that working, of course)
(In reply to comment #6) > > Perhaps I am misunderstanding, but why is it necessary to extract the physical > size from the bios tables when it is being correctly reported in the monitor > EDID information? Might it make sense to use the EDID information until it is > possible to read the size from the bios tables? (Depending on the predicted > time to get that working, of course) > If it's available in the EDID, we use it, but not all laptop panels provide an EDID. In cases without an EDID, we may be able to get the physical size out of the bios tables, in other cases we have no physical size information period.
(In reply to comment #7) > If it's available in the EDID, we use it, but not all laptop panels provide an > EDID. Should I file a separate bug then, because the EDID on my laptop seems to be getting ignored (which is also how I interpreted the description of this particular bug). In my case it is using the latest ati (radeon) driver from git on top of a 1.3.0.0 Xorg running on a ATI Mobility FireGL V5200 (M56GL) in a Thinkpad. I can also verify that the physical size is reported correctly in the EDID output (using both get-edid and through the xrandr output), but it is incorrectly determined during X startup and is incorrectly reported in xdpyinfo.
Created attachment 13781 [details] get-edid through parse-edid output Whereas ddcprobe sees the physical size, it seems like get-edid doesn't.
Created attachment 13782 [details] updated Xorg.0.log (minimal xorg.conf, xorg-server 1.4.1~git20080105 and -ati from today)
Created attachment 13793 [details] [review] possible fix I'm not sure what the vbe get edid calls do. The bios may construct a fake edid on the fly based on the panel data table. There are some cases where the atombios has a non-DDC edid, and this path will expose that if available. Let me know if this helps. Patch is against ati git master.
Created attachment 13796 [details] log from patched driver and server 1.3 Thanks for the patch. However, I get this: (II) RADEON(0): Query for AtomBIOS Get Panel EDID: failed
(In reply to comment #12) > Created an attachment (id=13796) [details] > log from patched driver and server 1.3 > > Thanks for the patch. However, I get this: > > (II) RADEON(0): Query for AtomBIOS Get Panel EDID: failed > Well, it appears your laptop doesn't have a built-in EDID. The vbe call must be constructing a fake one somehow.
(In reply to comment #8) > Should I file a separate bug then, because the EDID on my laptop seems to be > getting ignored (which is also how I interpreted the description of this > particular bug). In my case it is using the latest ati (radeon) driver from > git on top of a 1.3.0.0 Xorg running on a ATI Mobility FireGL V5200 (M56GL) in > a Thinkpad. I can also verify that the physical size is reported correctly in > the EDID output (using both get-edid and through the xrandr output), but it is > incorrectly determined during X startup and is incorrectly reported in > xdpyinfo. > Can you post your xorg log?
> The vbe call must be constructing a fake one somehow. Well, the numbers are suspiciously correct, I verified it with a ruler :) So, when you do VBE calls for ddc info, the video bios pretends these values were probed over edid but in fact it got the numbers some other way (like hardcoded)?
(In reply to comment #15) > > The vbe call must be constructing a fake one somehow. > > Well, the numbers are suspiciously correct, I verified it with a ruler :) So, > when you do VBE calls for ddc info, the video bios pretends these values were > probed over edid but in fact it got the numbers some other way (like > hardcoded)? > The vbe edid call just returns an edid. Only the bios knows whether that edid was build by some code in the bios actually pulled from a monitor.
(In reply to comment #9) > Created an attachment (id=13781) [details] > get-edid through parse-edid output > > Whereas ddcprobe sees the physical size, it seems like get-edid doesn't. I'm not sure that parse-edid would output anything related to the screen size. The hack that I was using to check it was: sudo get-edid 2>/dev/null | perl -e 'use bytes; my $edid; read STDIN, $edid, 1024; my @bytes = unpack("C128", $edid); die "Not supported" if ($bytes[54] == 0 and $bytes[55] == 0); print "Width:\t".((($bytes[68]&0xF0) << 4) + $bytes[66])." (mm)\nHeight:\t".((($bytes[68]&0xF) << 8)+$bytes[67])." (mm)\n"'
Created attachment 13804 [details] Xorg.0.log - ATI Mobility FireGL V5200 - ati git master unpatched Xorg log using ati git master with no patches applied. Running on an ATI Mobility FireGL V5200 (M56GL) in a Thinkpad T60p. Note that (II) RADEON(0): Setting screen physical size to 370 x 277 Disagrees with the (correct) physical size of the panel reported by EDID (II) RADEON(0): clock: 108.0 MHz Image Size: 287 x 215 mm The physical size appears to be set such that the DPI is 96 with the native resolution of the panel.
Created attachment 13805 [details] Xorg.0.log - ATI Mobility FireGL V5200 - ati git master w/ patch from comment 11 Xorg log using ati git master with the patch from comment 11 applied. Running on an ATI Mobility FireGL V5200 (M56GL) in a Thinkpad T60p.
(In reply to comment #18) > Created an attachment (id=13804) [details] > Xorg.0.log - ATI Mobility FireGL V5200 - ati git master unpatched > Your panel has an edid. so the patch doesn't matter in your case. > Xorg log using ati git master with no patches applied. Running on an ATI > Mobility FireGL V5200 (M56GL) in a Thinkpad T60p. Note that > > (II) RADEON(0): Setting screen physical size to 370 x 277 this is from the xserver not the driver. > > Disagrees with the (correct) physical size of the panel reported by EDID > > (II) RADEON(0): clock: 108.0 MHz Image Size: 287 x 215 mm > > The physical size appears to be set such that the DPI is 96 with the native > resolution of the panel. > In your case it's an X server issue as the driver is just passing the physical size to the xserver which is doing something weird with it (maybe some distro hack). I'd be interested to see if vanilla xserver 1.4 or git made a difference.
Kevin, yes, you're right, it was just parse-edid that didn't show it. When I use your get-edid perl hack, I get the correct: Width: 331 (mm) Height: 207 (mm)
After much pain and anguish, I was able to compile X git master and I can confirm that the problem is indeed present in the latest sources. However, I also found the source of the problem. It turns out that there was an erroneous "-dpi 96" being added to the X invocation in my gdm.conf... Now all I need is a brown paper bag. Sorry for all of the noise.
With the latest ati driver, it works fine: (II) RADEON(0): Setting screen physical size to 331 x 207 which is correct.
this seems to be resolved.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.