Bug 12474 - DisplaySize overridden and DPI miscalculated by the driver
Summary: DisplaySize overridden and DPI miscalculated by the driver
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.3 (2007.09)
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 12117 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-18 15:06 UTC by Bartosz Fabianowski
Modified: 2007-11-25 08:00 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (1.69 KB, text/plain)
2007-09-18 15:07 UTC, Bartosz Fabianowski
no flags Details
Xorg.0.log (151.63 KB, text/plain)
2007-09-18 15:07 UTC, Bartosz Fabianowski
no flags Details
Output of xdpyinfo after starting X (4.31 KB, text/plain)
2007-09-18 15:08 UTC, Bartosz Fabianowski
no flags Details
Output of xdpyinfo after manually setting the physical screen size with "xrandr --fbmm 325x203" (4.31 KB, text/plain)
2007-09-18 15:08 UTC, Bartosz Fabianowski
no flags Details
xdpyinfo output (6.20 KB, text/plain)
2007-09-20 08:33 UTC, Arkadiusz Miskiewicz
no flags Details
Xorg log (48.24 KB, text/plain)
2007-09-20 08:33 UTC, Arkadiusz Miskiewicz
no flags Details
xorg.conf (3.43 KB, text/plain)
2007-09-20 08:34 UTC, Arkadiusz Miskiewicz
no flags Details
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m (44.01 KB, text/plain)
2007-09-24 11:40 UTC, Arkadiusz Miskiewicz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bartosz Fabianowski 2007-09-18 15:06:55 UTC
I am using version 6.7.192 of the Radeon driver. The machine is a Dell Inspiron 8600C laptop running FreeBSD 6-STABLE with a Radeon M10 graphics card serving the internal LCD panel via LVDS. The screen is 15.4" widescreen with a resolution of 1920x1200.

As the screen appears not to report its physical size to the driver, I manually set it via "DisplaySize 325 203" in the "Monitor" section. This worked correctly in X.org 7.2 and resulted in the correct 150 DPI being calculated. The new driver normally ignores the "Monitor" section. After I set the undocumented "Monitor-LVDS" option, the DisplaySize setting does get read and used, but then gets overridden somehow, resulting in a bogus physical screen size and 96 DPI (see attached Xorg.0.log).

The relevant log lines are:
> Line 508: (==) RADEON(0): X server will not keep DPI constant for all screen sizes
----
> Line 537: (II) RADEON(0): Max desktop size set to 2560x2048
----
> Line 559: (II) RADEON(0): Panel Size from BIOS: 1920x1200
----
> Line 637: (II) RADEON(0): Output LVDS using initial mode 1920x1200
----
> Line 639: (**) RADEON(0): Display dimensions: (325, 203) mm
> Line 640: (**) RADEON(0): DPI set to (200, 256)
----
> Line 787: (II) RADEON(0): Setting screen physical size to 508 x 317

My understanding is as follows:
* Line 508: randr will not fudge the physical screen size to keep the DPI constant
* Line 537: The graphics card can handle up to 2560x2048 resolution
* Line 559: The LCD panel will only do 1920x1200 resolution
* Line 637: The chosen resolution is 1920x1200
* Line 639: The correct physical screen size has been read from xorg.conf
* Line 640: Despite knowing that 1920x1200 will be used, the driver calculates DPI based on 2560x2048, which is wrong
* Line 787: The driver for some reason overrides the correct physical screen size, now again using 1920x1200 resolution and fudging the size so that it results in 96 DPI, which is wrong

I have to manually correct the physical screen size via "xrandr --fbmm 325x203" after every login, which is a pain.
Comment 1 Bartosz Fabianowski 2007-09-18 15:07:18 UTC
Created attachment 11619 [details]
xorg.conf
Comment 2 Bartosz Fabianowski 2007-09-18 15:07:36 UTC
Created attachment 11620 [details]
Xorg.0.log
Comment 3 Bartosz Fabianowski 2007-09-18 15:08:18 UTC
Created attachment 11621 [details]
Output of xdpyinfo after starting X
Comment 4 Bartosz Fabianowski 2007-09-18 15:08:58 UTC
Created attachment 11622 [details]
Output of xdpyinfo after manually setting the physical screen size with "xrandr --fbmm 325x203"
Comment 5 Luka Renko 2007-09-18 15:50:25 UTC
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.
Comment 6 Bartosz Fabianowski 2007-09-18 16:50:41 UTC
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.
Comment 7 Alex Deucher 2007-09-18 18:53:05 UTC
*** Bug 12117 has been marked as a duplicate of this bug. ***
Comment 8 Alex Deucher 2007-09-18 19:27:18 UTC
I think this is something in the server as the driver does not mess with the dpi anywhere.
Comment 9 Luka Renko 2007-09-18 22:44:36 UTC
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?
Comment 10 James Spencer 2007-09-19 08:04:29 UTC
I can confirm comment #9 on Debian. Actually, I can confirm this whole report letter for letter down to the solution. :)
Comment 11 Alex Deucher 2007-09-19 08:20:45 UTC
(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.
Comment 12 Arkadiusz Miskiewicz 2007-09-20 08:32:22 UTC
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.

Comment 13 Arkadiusz Miskiewicz 2007-09-20 08:33:06 UTC
Created attachment 11657 [details]
xdpyinfo output
Comment 14 Arkadiusz Miskiewicz 2007-09-20 08:33:29 UTC
Created attachment 11658 [details]
Xorg log
Comment 15 Arkadiusz Miskiewicz 2007-09-20 08:34:21 UTC
Created attachment 11659 [details]
xorg.conf
Comment 16 Arkadiusz Miskiewicz 2007-09-24 11:40:27 UTC
Created attachment 11726 [details]
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m
Comment 17 Luka Renko 2007-09-25 23:35:59 UTC
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
Comment 18 Alex Deucher 2007-09-26 06:15:29 UTC
does 6.7.194-1ubuntu1tv carry any patches beyond what's in the stock 6.7.194 or ati git?
Comment 19 Luka Renko 2007-09-26 07:53:42 UTC
It is vanilla source from git.
Comment 20 Tormod Volden 2007-09-26 12:10:49 UTC
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.
Comment 21 Arkadiusz Miskiewicz 2007-10-05 17:52:07 UTC
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 :-/
Comment 22 Arkadiusz Miskiewicz 2007-10-05 17:52:59 UTC
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 :-/
Comment 23 Arkadiusz Miskiewicz 2007-10-05 22:31:35 UTC
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?
Comment 24 Arkadiusz Miskiewicz 2007-10-06 03:15:12 UTC
"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.
Comment 25 Alex Deucher 2007-10-06 08:14:51 UTC
(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.
Comment 26 Felix Miata 2007-10-07 13:41:16 UTC
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
Comment 27 Arkadiusz Miskiewicz 2007-10-09 02:44:28 UTC
bug 10304 has fix for xserver (not tested by me but looks fine)
Comment 28 Matthias Hopf 2007-10-24 11:33:43 UTC
Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.
Comment 29 Tormod Volden 2007-11-25 08:00:55 UTC
I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727


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.