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.
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
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.
Older radeons rarely had edids for the LVDS panel, the vbios lvds table only has the panel modeline, not the physical size.
> 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.
(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).
(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.
"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
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.
Created attachment 35605 [details] Xorg log when DisplaySize is set
Created attachment 35606 [details] xorg.conf that sets DisplaySize
This is an issue with the expected xserver behaviour rather than the driver.
> 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.)
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.