Bug 28073

Summary: ati radeon driver does not autodetect displaysize on Radeon RV250 [Mobility FireGL 9000]
Product: xorg Reporter: Glen Ditchfield <gjditchfield>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: ach, mrmazda
Version: unspecifiedKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log
none
xdpyinfo output
none
Xorg log when DisplaySize is set
none
xorg.conf that sets DisplaySize none

Description Glen Ditchfield 2010-05-11 20:47:03 UTC
Created attachment 35581 [details]
Xorg log

This bug goes back to at least October 2007.  For history and more log files, and a reference to a possible patch, see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/575496

The Radeon driver distributed with Ubuntu 10.04 and earlier distributions does not correctly detect monitor sizes.  On Dell Latitude D600s with 14 inch 1400x1050 LCD displays, it incorrectly calculates a panel size of 370x277 mm and a resolution of 96 dpi, instead of the correct 124 dpi. The KDE desktop is misled by this when converting point sizes to pixels, and displays everything in unpleasantly small characters.
Comment 1 Glen Ditchfield 2010-05-11 20:48:55 UTC
Created attachment 35582 [details]
xdpyinfo output

Many more log files for Ubuntu 10.04 at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/575496
Comment 2 Julien Cristau 2010-05-12 04:29:58 UTC
First, xdpyinfo reporting 96dpi by default is expected, see bug 23705.

Also from the xrandr output on the lp bug, it seems we don't get the actual size of your display.  Is there an edid file in /sys/class/drm/card0-LVDS-1/?  If so please attach it.
Comment 3 Alex Deucher 2010-05-12 07:29:07 UTC
Older radeons rarely had edids for the LVDS panel, the vbios lvds table only has the panel modeline, not the physical size.
Comment 4 James Cloos 2010-05-12 10:57:04 UTC
> Older radeons rarely had edids for the LVDS panel, the vbios lvds
> table only has the panel modeline, not the physical size.

The old radeon driver (back in the xfree86 days) did know that my
laptop’s screen was 12”×9”.  I originally added --dpi 133 to my X
startup scripts only because the integer conversions between inch
(for dpi) and mm (for dimensions) led to rounding errors.

To the Reporter:  you may need to add --dpi 124 to your startup
scripts to get accurate sizing with the current X server.
Comment 5 Felix Miata 2010-05-12 12:35:15 UTC
(In reply to comment #4)
> I originally added --dpi 133 to my X
> startup scripts only because the integer conversions between inch
> (for dpi) and mm (for dimensions) led to rounding errors.

> To the Reporter:  you may need to add --dpi 124 to your startup
> scripts to get accurate sizing with the current X server.

Actually, most scalable fonts work best when DPI is a multiple of 12, so 120 (10.0X) or 132 (11.0X) can be expected to work better than 124 (10.33X) or 133 (11.08X).
Comment 6 Alex Deucher 2010-05-12 16:19:27 UTC
(In reply to comment #4)
> > Older radeons rarely had edids for the LVDS panel, the vbios lvds
> > table only has the panel modeline, not the physical size.
> 
> The old radeon driver (back in the xfree86 days) did know that my
> laptop’s screen was 12”×9”.  I originally added --dpi 133 to my X
> startup scripts only because the integer conversions between inch
> (for dpi) and mm (for dimensions) led to rounding errors.

The driver did not even have support for reading edids from LCD panels at that time so it must have been some different behaviour in the xserver rather than the driver.
Comment 7 Glen Ditchfield 2010-05-12 20:30:43 UTC
"ls -l" says that /sys/card/drm/card0-LVDS-1/edid exists, apparently with 128 bytes in it.  However, all other commands I tried say it is empty.

[salver:card0-LVDS-1]$ ls -l /sys/class/drm/card0-LVDS-1/edid
-r--r--r-- 1 root root 128 2010-05-12 22:09 /sys/class/drm/card0-LVDS-1/edid
[salver:card0-LVDS-1]$ wc edid
  0   0   0 edid
Comment 8 Glen Ditchfield 2010-05-12 21:28:38 UTC
I generated an xorg.conf file with "Xorg -configure", and modified it to contain  "DisplaySize 285 215" in the Monitor section. (The generated file had "#DisplaySize 290 210", commented out.)  Xorg.0.log now contains 

  (II) RADEON(0): EXA: Driver will not allow EXA pixmaps in VRAM
  (**) RADEON(0): Display dimensions: (285, 215) mm
  (**) RADEON(0): DPI set to (124, 124)
  (II) Loading sub module "fb"

However, xdpyinfo still says the monitor has 96 dpi, and KDE still uses small lettering.

From bug 23705, I understand that Xorg sets DPI to 96 in the default case (and strongly disagree with the decision!), but when I explicitly set the screen dimensions, you should go along with me.  Adding a "--dpi" option in the KDM start-up scripts is just not right.

Note also that, as mentioned in the Launchpad bug, the vesa driver calculates nearly correct dimensions and DPI.
Comment 9 Glen Ditchfield 2010-05-12 21:30:17 UTC
Created attachment 35605 [details]
Xorg log when DisplaySize is set
Comment 10 Glen Ditchfield 2010-05-12 21:31:16 UTC
Created attachment 35606 [details]
xorg.conf that sets DisplaySize
Comment 11 Alex Deucher 2010-05-13 06:03:05 UTC
This is an issue with the expected xserver behaviour rather than the driver.
Comment 12 James Cloos 2010-05-14 15:33:07 UTC
> The driver did not even have support for reading edids from LCD panels
> at that time so it must have been some different behaviour in the
> xserver rather than the driver.

Appologies for the confusion; I'm sure it was getting the info from
the BIOS.  It even knew that the panel was an IBM ITUX97.

If my box had that info available, it stands to reason that the
Reporter's box may as well.

(It did format the data in the logs as though it had used edid, but it
had to have used the BIOS to get it.)
Comment 13 Adam Jackson 2018-06-12 18:43:57 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.

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.