DPI is set incorrectly by new driver, even when DisplaySize is set in xorg.conf

[Martijn vdS]

Binary package hint: xserver-xorg-video-ati

I have an ATi X700 in my laptop, and since the new "randr 1.2" driver, the DPI for my monitor isn't set correctly anymore.

I'm using 1:6.7.192-4ubuntu1 currently.

My screen is 33cm x 21cm, at 1920x1200, which used to be calculated correctly at 148x149dpi (or something close). Now it seems forced to 96, which breaks font sizes severely.

Even adding "DisplaySize 330 210" to the Monitor section in the Xorg config file doesn't help.

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

[Martijn vdS (martijn)]

Binary package hint: xserver-xorg-video-ati

I have an ATi X700 in my laptop, and since the new "randr 1.2" driver, the DPI for my monitor isn't set correctly anymore.

I'm using 1:6.7.192-4ubuntu1 currently.

My screen is 33cm x 21cm, at 1920x1200, which used to be calculated correctly at 148x149dpi (or something close). Now it seems forced to 96, which breaks font sizes severely.

Even adding "DisplaySize 330 210" to the Monitor section in the Xorg config file doesn't help.

[Tormod Volden (tormodvolden)]

Can you please attach Xorg.0.log ?

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

[Martijn vdS (martijn)]

The log file shows the correct DPI values

[Martijn vdS (martijn)]

But xdpyinfo does not

[Tormod Volden (tormodvolden)]

Did you try without any xorg.conf? It seems like the new driver calculates the dpi correctly, but the server does not pick it up.

[Tormod Volden (tormodvolden)]

What happens if you set DPI with xrandr --dpi ?

[Martijn vdS (martijn)]

On Thu, 27 Sep 2007, Tormod Volden wrote:

> What happens if you set DPI with xrandr --dpi ?

Then xdpyinfo shows a new (better, not yet quite correct) DPI:

screen #0:
  dimensions: 1920x1200 pixels (334x208 millimeters)
  resolution: 146x147 dots per inch

(the X log (and my measurements) claim it's 332x210mm, but this is close)

Also, the fonts return to their proper size.

Martijn
--
Sorry isn't an excuse when you do something stupid on purpose.

[Martijn vdS (martijn)]

On Thu, 27 Sep 2007, Tormod Volden wrote:

> Did you try without any xorg.conf? It seems like the new driver
> calculates the dpi correctly, but the server does not pick it up.

I've tried both with DisplaySize and without. I haven't tried without a
config file at all.

Martijn
--
Sorry isn't an excuse when you do something stupid on purpose.

[Rudd-O (rudd-o)]

I have the same problem. Here is my xdpyinfo output AFTER setting xrandr --dpi 125

screen #0:
  dimensions: 1280x900 pixels (260x182 millimeters)
  resolution: 125x126 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32
  root window id: 0x54
  depth of root window: 24 planes
  number of colormaps: minimum 1, maximum 1
  default colormap: 0x20
  default number of colormap cells: 256
  preallocated pixels: black 0, white 16777215
  options: backing-store NO, save-unders NO

it's REALLY screwed up, and Kaffeine refuses to play video except for a sliver, since the original resolution calls for something like 32000 DPI vertically multiplied by 80 horizontally or something.

To be perfectly clear: for some reason DDC EDID retrievals retrieve the RIGHT Display Size from the monitor, yet X seems to munge it somehow. If I specify a manual DisplaySize, the log shows that X picks the manual size up, nonetheless the DPI gets absurdly distorted (121x188 or something, when it should be more like 121x122).

Please help!

[Rudd-O (rudd-o)]

Apparently displaysize isn't even being heeded anymore if you turn the NoDDC option on (actually required over here on my side since the damn X insists of giving me a dpi of 32000something x 148something, and OBVIOUSLY KDE doesn't work like that because it shows EXTREMELY huge fonts).

I'm also at 96 dpi with NoDDC on, a correct DisplaySize (I used a ruler!!! :-) ), and I can also confirm that xrandr --dpi 125 returns my font sizes to normal.

Otoh I'm happy because for some odd reason I can now manufacture odd modelines that have given my 14 incher new life (1280 x 900 at the expense of some refresh rate, and I just squash the screen vertically to produce something like a widescreen aspect to compensate).

[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

[Timo Aaltonen (tjaalton)]

I'll put a test package available soon. This is fixed in upstream git.

[Timo Aaltonen (tjaalton)]

Please test the latest package (1ubuntu1tja2) available here:

http://ppa.launchpad.net/tepsipakki/ubuntu/pool/main/x/xserver-xorg-video-ati/

once it is built..

[Rudd-O (rudd-o)]

Didn't solve the problem

screen #0:
  dimensions: 1280x848 pixels (1x257 millimeters)
  resolution: 32512x84 dots per inch

That is with NoDDC turned off (default behavior) and no DisplaySize.

I'm attaching the logfile as well

[Timo Aaltonen (tjaalton)]

Hmm, ok.. I won't be pushing that change for gutsy then :/

[Timo Aaltonen (tjaalton)]

That upstream bug is not a dupe after all, I think. It was about an "unknown DDCType 6", and the patch added support for that. You should use NoDDC for the time being.

[Rudd-O (rudd-o)]

Any way I can quickly see a diff from the source of this module?

You mean the DPI will now be correctly calculated if I use noddc on and I specify a DisplaySize?

[Timo Aaltonen (tjaalton)]

Rudd-O, sorry, I misunderstood your situation :) Using NoDDC means you get 96dpi, so there is no change regarding that. Here you can see the upstream change to add support for DDCType 6 (different bug, really)

http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commitdiff;h=0b03a73b7dcb4aa192c42f2a4c842d324c358122

so, _this_ bug needs to be forwarded upstream.

[Arkadiusz Miśkiewicz (arekm)]

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

[Jonathan Rogers (jonner)]

I can confirm this bug. I've been using Xorg's "radeon" driver from xserver-xorg-video-ati in Feisty to display on an LCD TV. My situation is complicated by two things. First, like a lot TVs (as opposed to monitors), mine reports incorrect EDID information over VGA and DVI. It claims to have a size of 4cm x 3cm, with is not only impossibly small, but the wrong aspect ratio, since it's a 16:9 TV. Second, since I'm running MythTV, which misuses the DPI information and always wants 100x100 DPI regardless of actual display size, I had to manufacture a DisplaySize that is different from both the actual dimensions and what the TV reports.

Just yesterday, I upgraded to Gutsy and discovered that text in a terminal emulator was unreadably small (about 1 to 2 pixels high) and video was scaled to a narrow strip an inch or two high in the middle of the screen. Though X still reported that it was using 100x100 DPI in "/var/log/Xorg.0.log", xdpyinfo reported 52x6 DPI. So, apparently, X lies about the DPI in the log, ignoring the explicitly set DisplaySize for the DPI reported to clients. If I use the same /etc/X11/xorg.conf, but run "X -dpi 100", both the log and xdpyinfo report 100x100 DPI.

[Tormod Volden (tormodvolden)]

Ok, back to Martiijn's bug:
Xorg.0.log:
(II) RADEON(0): Output LVDS using initial mode 1920x1200
after xf86InitialConfiguration
(**) RADEON(0): Display dimensions: (332, 210) mm
(**) RADEON(0): DPI set to (146, 145)

xdpyinfo:
  resolution: 96x96 dots per inch

The radeon driver calculates the right dpi, but the server does not use it.

The other people here who do not have the exact same issue should file/find another bug report.

[Tormod Volden (tormodvolden)]

>> Did you try without any xorg.conf? It seems like the new driver
>> calculates the dpi correctly, but the server does not pick it up.
>
>I've tried both with DisplaySize and without. I haven't tried without a
>config file at all.

Martijn, can you try without an xorg.conf please? And attach Xorg.0.log from that.

[Rudd-O (rudd-o)]

I have the same problem -- X does not use the RADEON calculated DPI info. But I also have a DIFFERENT problem -- the RADEON driver calculates the wrong vertical DPI.

For that, I have opened a second bug report. I don't recall the bug number :-(.

[Jonathan Rogers (jonner)]

I am seeing the same bug as Martijn AFAIK.

[Tormod Volden (tormodvolden)]

Jonathan, your log is apparently from running X -dpi 100. Please attach the log from running without any xorg.conf or options.

Rudd-O, your bug report is bug #154390 (not so difficult to find - click your name in launchpad).

[Martijn vdS (martijn)]

WIthout a xorg.conf, xdpyinfo reports 147x147dpi (correctly). It also works _with_ a config file now, so this bug seems fixed to me...

[Tormod Volden (tormodvolden)]

Thanks Martijn, I'll close this bug report then.

[Rudd-O (rudd-o)]

Let's hope the other bug report I logged gets its fix as well :-).

[Jonathan Rogers (jonner)]

Actually, I'm pretty sure I was running "X" with no options to get that previous output. Now, I've done the same with no config file.

[Jonathan Rogers (jonner)]

And here's my xdpyinfo output. Notice that while Xorg.0.log reports that it has set itself to the default 100x100 DPI, xdpyinfo reports 52x8 dots per inch. The current behavior is different from what it did on Feisty. Now, I have to use -dpi 100 to force it, but I never had to do that before. I'm not sure what changed for Martijn, but I'm still seeing the same bug.

[Tormod Volden (tormodvolden)]

Jonathan, this looks interesting in your log:
> (II) RADEON(0): Setting screen physical size to 628 x 3433

> I'm not sure what changed for Martijn, but I'm still seeing the same bug.
Which maybe is a hint that it is not the same bug? ;)

[Jonathan Rogers (jonner)]

The title of the bug "DPI is set incorrectly by new driver, even when DisplaySize is set in xorg.conf" and that's exactly what I'm observing. I can just make a new one with exactly the same description, but that seems stupid.

[Tormod Volden (tormodvolden)]

The bug title is often not very precise. Yes, please a file new bug with a new description corresponding to your issue. You can use the same title if you want :)

[Mhopf-suse (mhopf-suse)]

Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.

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

I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727