Bug 28073

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.