Bug 12474

Created attachment 11619 [details]
xorg.conf

Created attachment 11620 [details]
Xorg.0.log

Created attachment 11621 [details]
Output of xdpyinfo after starting X

Created attachment 11622 [details]
Output of xdpyinfo after manually setting the physical screen size with "xrandr --fbmm 325x203"

This bug is very similar (same?) as the bug 12117 that I reported some time ago. I have alos workaround the issue by running xrandr -fbmm in Xsession.

Yes, this is a dup of 12117. Feel free to consolidate the two. However, this bug (12474) has additional information and a clearer summary line which should not be lost.

*** Bug 12117 has been marked as a duplicate of this bug. ***

I think this is something in the server as the driver does not mess with the dpi anywhere.

Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is running xserver 1.3, panel size (and consequently DPI) is properly detected with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati driver with xrandr (this was regression identified with my early testing of xrandr branch and is still there in 1:6.7.192-1ubuntu2). 
Since it looks like driver is reporting proper size in log file, but later does not use it properly, is it possible that this get somehow mangled in the driver before passing further?

I can confirm comment #9 on Debian. Actually, I can confirm this whole report letter for letter down to the solution. :)

(In reply to comment #9)
> Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is
> running xserver 1.3, panel size (and consequently DPI) is properly detected
> with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati
> driver with xrandr (this was regression identified with my early testing of
> xrandr branch and is still there in 1:6.7.192-1ubuntu2). 
> Since it looks like driver is reporting proper size in log file, but later does
> not use it properly, is it possible that this get somehow mangled in the driver
> before passing further?
> 

The old driver implemented it's own dualhead system (mergedfb) right in the driver.  The old driver DID mess with the dpi because it handled the randr type functionality itself.  With randr all of that moved to the server.  The server should be doing the right thing.  If it's broken for radeon, it's also broken for intel or mga or whatever other randr driver you are using.  The drivers shouldn't be duplicating dpi fixups.

New driver is out but doesn't fix this issue.

Linux 2.6.23git, glibc 2.6.1, i686, Thinkpad Z60m with ATI Mobile X600,
xorg-xserver-server 1.4-3, xorg-driver-video-ati 6.7.193, Mesa 7.0.1.

By default driver calculates very wrong panel size:
  dimensions:    1680x1050 pixels (444x277 millimeters)
  resolution:    96x96 dots per inch

The correct one is  DisplaySize       330   210 (mm).

I'm attaching my config, x log and xdpyinfo output.

Created attachment 11657 [details]
xdpyinfo output

Created attachment 11658 [details]
Xorg log

Created attachment 11659 [details]
xorg.conf

Created attachment 11726 [details]
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m

This is fixed for me with recent uprage to 6.7.194-1ubuntu1tv version of ati driver.
SW: Kubuntu Gutsy
HW: HP nw8240 with ATI FireGL V5000 PCIE

does 6.7.194-1ubuntu1tv carry any patches beyond what's in the stock 6.7.194 or ati git?

It is vanilla source from git.

The "tv" package is practically the same as the Debian 6.7.194-1 package, which has no changes to the source files (only packaging and makefiles etc).

OTOH the xorg-server in Ubuntu Gutsy is a bastard 1.3 with lots of 1.4 backports.

Doesn't work with newly released ati driver 6.7.195. Alex Deucher tells that this is probably xserver issue and not ati driver one: http://lists.freedesktop.org/archives/xorg/2007-September/028627.html. Unfortunately xserver devs didn't respond to that so this is still unknown.

If you are xserver dev and could help to track down this I'm ready to test your ideas, debug things and so on. Very nasty issue preventing any few randr 1.2 drivers from being usable :-/

Doesn't work with newly released ati driver 6.7.195. Alex Deucher tells that this is probably xserver issue and not ati driver one: http://lists.freedesktop.org/archives/xorg/2007-September/028627.html. Unfortunately xserver devs didn't respond to that so this is still unknown.

If you are xserver dev and could help to track down this I'm ready to test your ideas, debug things and so on. Very nasty issue preventing any few randr 1.2 drivers from being usable :-/

In my case resolution is 1680x1050 and this code in hw/xfree86/modes/xf86RandR12.c is executed:
                /*
                 * Otherwise, just set the screen to 96dpi
                 */
                mmWidth = width * 25.4 / 96;
                mmHeight = height * 25.4 / 96;

width is 1680, height 1050 and that ends up as   dimensions:    1680x1050 pixels (444x277 millimeters).

I assume that the standard code path that this driver shoud follow is:
if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)

Unfortunately the problem is that mm_width and mm_height are zero so that code path is never executed. Don't know yet where these come from - I assume radeon driver fills these. Digging.

I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6 found" like not found => no ddc query => panel dimensions unknown. Is my guessing correct?

"Unknown DDCType 6 found" was the main problem here. Without handling it DDC/EDID didn't work so X didn't know panel dimensions and other stuff. Thanks to airlied git commit 0b03a73b7dcb4aa192c42f2a4c842d324c358122 the isue is solved for me.

Bartosz logs also show the same issue so I guess he will be fine with this patch, too.

(In reply to comment #23)

> 
> I assume that the standard code path that this driver shoud follow is:
> if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)
> 
> Unfortunately the problem is that mm_width and mm_height are zero so that code
> path is never executed. Don't know yet where these come from - I assume radeon
> driver fills these. Digging.

mm_width and mm_height should be filled in either by the edid (xf86OutputSetEDID()), or by hardcoding them in a monitor section in your config.  If you hardcode the settings, the server should parse the monitor section of your config assigned to that output and fill in the values, but it does not.  That's the bug.

> 
> I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6
> found" like not found => no ddc query => panel dimensions unknown. Is my
> guessing correct?
> 

In your case, yes, but lots of laptops do not provide an edid for the panel.  Without an edid, there is no way to know what the physical size of the screen is.  We are able to determine the size of the panel in pixels based on the panel bios tables, but not the physical size.

I'm bothered by seeing this kind of thing in Xorg.0.log using 845G on Mandriva 2008 and OpenSUSE 10.3 (where DPI always comes out to 96 no matter what resolution or screen size is used):

...
(**) intel(0): Display dimensions: (361, 270) mm
(**) intel(0): DPI set to (144, 192)
...

See:
https://bugzilla.novell.com/show_bug.cgi?id=331609
http://qa.mandriva.com/show_bug.cgi?id=33935

bug 10304 has fix for xserver (not tested by me but looks fine)

Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.

I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727