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