Bug 678800 - Intel driver reports incorrect DPI (regression)
Summary: Intel driver reports incorrect DPI (regression)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-19 19:41 UTC by Robert Clark
Modified: 2018-04-11 17:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-01 15:10:37 UTC
Type: ---


Attachments (Terms of Use)
Log file showing monitor DPI being detected (79.39 KB, text/plain)
2011-02-19 19:41 UTC, Robert Clark
no flags Details
Output from xdpyinfo (9.66 KB, text/plain)
2011-02-19 19:43 UTC, Robert Clark
no flags Details

Description Robert Clark 2011-02-19 19:41:09 UTC
Created attachment 479721 [details]
Log file showing monitor DPI being detected

I have an Acer Aspire One netbook with an ~134DPI monitor. Under Fedora 11, this was correctly detected and reported. With Fedora 14, while the Intel driver initially seems to correctly detect the resolution, it then reports the wrong value.

I've attached the Xorg.0.log file, but here are the interesting bits:

[    18.539] (**) intel(0): Display dimensions: (200, 110) mm
[    18.539] (**) intel(0): DPI set to (130, 138)
...
[    18.664] (II) intel(0): Setting screen physical size to 270 x 158

The monitor is 200mm x 110mm, 1024px x 600px, 130DPI x 138DPI. The size 270mm x 158mm is wrong.

I've set the DPI in Gnome's font settings to 134, which has fixed the font sizes for a lot of programs, but some are still selecting fonts that are too small (e.g. Epiphany).

Comment 1 Robert Clark 2011-02-19 19:43:46 UTC
Created attachment 479722 [details]
Output from xdpyinfo

Attaching the output from xdpyinfo showing the wrong display dimensions & DPI.

Comment 2 Matěj Cepl 2011-02-25 17:12:28 UTC
Just noting here IMHO relevant part of xdpyinfo:

jakoubek:~ $ curl -s 'https://bugzilla.redhat.com/attachment.cgi?id=479722'|grep -E '(resolution|dimensions)'
  dimensions:    1024x600 pixels (270x158 millimeters)
  resolution:    96x96 dots per inch
jakoubek:~ $

Comment 3 Martin Sourada 2011-02-28 20:20:20 UTC
Just FYI I have the same problem in Rawhide. 

$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm

$ xdpyinfo | grep -E '(resolution|dimensions)'
  dimensions:    1280x800 pixels (337x210 millimeters)
  resolution:    96x97 dots per inch

# cat /var/log/Xorg.0.log | grep DPI
[   227.349] (**) intel(0): DPI set to (98, 96)

The values from xrandr are correct and the DPI counted from them is (after rounding) 98x98, so where the other values came from?


00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

xorg-x11-drv-intel-2.14.0-2.fc15.i686

Comment 4 Martin Sourada 2011-02-28 20:22:13 UTC
Oh, and forgot to add, Xorg.0.log reports yet another different dimensions...


[   227.349] (**) intel(0): Display dimensions: (330, 210) mm

Comment 5 Adam Jackson 2011-03-01 15:10:37 UTC
The DPI and physical size as reported by xdpyinfo (and, for the most part, the X log) is a lie.  They are properties of the X screen, but X screens do not map 1:1 to monitors, thanks to RANDR.  So in general you can't trust them, and anything doing font sizing based on them is broken.  If you want that you need to look at the EDID block for each RANDR output, and even then you really can't win because what do you do if one output is 60dpi and one is 130dpi.

Which is why the server tends to report the screen dpi as 96, and to compute physical size backwards from that and the number of pixels.


Note You need to log in before you can comment on or make changes to this bug.