Red Hat Bugzilla – Bug 433123
dpi is incorrect for physical size
Last modified: 2018-04-11 07:53:13 EDT
Description of problem: The radeon driver reports an incorrect DPI. This causes huge firefox/minefield to produce really huge icons and screen images. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.7.197-1.fc9.i386 firefox-3.0-0.beta3.21.nightly20080214.fc9.i386 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: xrdb -query | grep dpi Xft.dpi: 120 xdpyinfo screen #0: dimensions: 1920x1200 pixels (300x230 millimeters) resolution: 163x133 dots per inch Expected results: Physical size of the screen is 14.5 inches (368 mm) by 9 inches, so dpi should be 133/134 in both dimensions. Additional info: 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Mobility Radeon X300]
Upstream Gecko issues: https://bugzilla.mozilla.org/show_bug.cgi?id=378927 Mailing list thread: https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01342.html What reporter is describing is 17" WUXGA display, about the highest available DPI in currently marketed mainstream hardware.
Created attachment 295078 [details] Xorg.0.log
Somebody please change attachment to a valid type. It won't let me do it.
Hmm, I'm seeing something similar with vmware driver and I have a much lower resolution display (1280x800). I noticed that the system->preferences->appearance dialog now includes a dpi selector which changes the xft.dpi setting dynamically. My display was showing what I thought was 'normal' dpi until I opened the appearance tool today and then suddenly my fonts all got much bigger (it had chosen to change to 140dpi). This was for the entire gnome interface, not just firefox, just so we are clear. I have previously set the firefox dpi to be 120 manually in about:config because of the issues with it detecting dpi. My screen should be 113x112 dpi by its dimensions... and xdpyinfo is reporting 153x128 dpi because the dimensions are wrong; it reports 212x159mm (8.34"x6.26") while my screen size is really 11.25"x7.1". This is a black 13" macbook. The xorg log shows selecting 96x96 dpi but it is starting in a different resolution, which changes when I login (set to 1280x800 for this user). So, it looks like either the vmware driver has a bug as well, or something is effecting both these drivers (and only recently). That new dialog option to set the dpi is recent if I'm not mistaken.
I am not sure whether component is right, but passing to developers.
Just so we're clear here: The DPI setting for xft is simply a scale factor. It is not inferred from the physical DPI. It is specified as DPI for historical reasons only. I assume this is because the radeon driver is guessing wildly at your display size (since you don't seem to have an EDID block for your internal panel), and is doing the guessing wrong. The physical size it's guessing is 4:3 even though the display is 16:10. So this is likely to be a bug in the radeon driver, but just to be sure, please attach your xorg.conf so we can check if you're accidentally setting a display size there.
Created attachment 295172 [details] xorg.conf
Right, definitely a radeon bug then.
I have two Dell 2001FP 21" LCD panels connected to a Radeon X600. The panels are each 408x306mm as I measured myself. Xorg.0.log says: (II) RADEON(0): EDID vendor "DEL", prod id 40968 (II) RADEON(0): Output DVI-1 connected (II) RADEON(0): Output DVI-0 connected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output DVI-1 using initial mode 1600x1200 (II) RADEON(0): Output DVI-0 using initial mode 1600x1200 after xf86InitialConfiguration (**) RADEON(0): Display dimensions: (410, 310) mm (**) RADEON(0): DPI set to (198, 131) xrandr says: DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm and the same for DVI-1.
Everytime I log in, I have to "xrandr -dpi 100" and then restart Firefox to get it to a normal size.
@Charles, not a fix, but you could add this to .bashrc to ease the pain: if [ $DISPLAY ]; then xrandr --dpi 100; fi
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can't reproduce on Fedora 10. Darrell, could you confirm that this is fixed on current, fully patched F10 ? If you have trouble booting, please use nomodeset in the kernel command line. Thanks in advance.
This is fixed in F10.