wrong resolution(dpi) - DisplaySize is ignored

[Roland Bless]

Although the DisplaySize is given in the monitor definition,
the resolution is totally wrong and makes the xserver unusable
due to huge fonts that are not displayed anymore.

screen #0:
  dimensions: 1280x960 pixels (1x257 millimeters)
  resolution: 32512x95 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32

output of X server and xdpyinfo is given in the attachment.

[Freebsd (freebsd)]

Created an attachment (id=11619)
xorg.conf

[Freebsd (freebsd)]

Created an attachment (id=11620)
Xorg.0.log

[Freebsd (freebsd)]

Created an attachment (id=11621)
Output of xdpyinfo after starting X

[Freebsd (freebsd)]

Created an attachment (id=11622)
Output of xdpyinfo after manually setting the physical screen size with "xrandr --fbmm 325x203"

[Luka Renko (lure)]

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.

[Freebsd (freebsd)]

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.

[agd5f (agd5f)]

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

[agd5f (agd5f)]

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

[Luka Renko (lure)]

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?

[Jamessp (jamessp)]

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

[agd5f (agd5f)]

(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.

[Arkadiusz Miśkiewicz (arekm)]

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.

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11657)
xdpyinfo output

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11658)
Xorg log

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11659)
xorg.conf

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11726)
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m

[Luka Renko (lure)]

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

[agd5f (agd5f)]

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

[Luka Renko (lure)]

It is vanilla source from git.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

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.

[Arkadiusz Miśkiewicz (arekm)]

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 :-/

[Arkadiusz Miśkiewicz (arekm)]

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?

[Arkadiusz Miśkiewicz (arekm)]

"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.

[agd5f (agd5f)]

(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.

[Felix Miata (mrmazda)]

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

[Arkadiusz Miśkiewicz (arekm)]

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

[Mhopf-suse (mhopf-suse)]

Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.

[Roland Bless (roland-bless)]

Although the DisplaySize is given in the monitor definition,
the resolution is totally wrong and makes the xserver unusable
due to huge fonts that are not displayed anymore.

screen #0:
  dimensions: 1280x960 pixels (1x257 millimeters)
  resolution: 32512x95 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32

output of X server and xdpyinfo is given in the attachment.

[Roland Bless (roland-bless)]

this bug occurred after upgrading from feisty to gutsy.

[Roland Bless (roland-bless)]

this is the xorg.conf

[Roland Bless (roland-bless)]

Strangely enough, the problem disappeared after removing
the problem disappeared after removing the
DefaultDepth 24 entry. The working xorg.conf is now attached.

[Roland Bless (roland-bless)]

I'm not really sure, but it seems that the
      Option "ddc2" "off"
entry made it.

[Bryce Harrington (bryce)]

You probably should comment out these lines:

# HorizSync 28-85
# VertRefresh 43-120

[Tormod Volden (tormodvolden)]

Actually I set this bug to Fix Committed after http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=48ca5961caee62f2980017a6bdc96a1b4c747727 but I do not think that one is in Ubuntu yet.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727