Bug 875355 - gimp should prefer randr geometry to core X for DPI calculation
Summary: gimp should prefer randr geometry to core X for DPI calculation
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gimp
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-10 19:21 UTC by JanS
Modified: 2013-08-01 05:52 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-08-01 05:52:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Xorg.0.log (37.25 KB, text/x-log)
2012-11-10 19:21 UTC, JanS
no flags Details

Description JanS 2012-11-10 19:21:57 UTC
Created attachment 642307 [details]
Xorg.0.log

Description of problem:
My system knows what is the true screen size through EDID. Intel driver knows this as well (which is confirmed in Xorg.0.log), but still, it is overriding this setting with no good reason (with line: "Setting screen physical size to"). 

This makes fonts too tiny too read. True DPI of the screen should be 130 x 130, while my X server starts with 96 x 96. I couldn't find any way to fix this.
Gimp thinks it is 96 DPI, xdpyinfo thinks the screen size is wrong, hence dpi is wrong - or vice versa. Xrandr knows the good value of the screen size, but is it not used by X server to display fonts and web pages right. I need big glasses to use computer now.

In details. Every time X starts, card recognizes true physical size properly:
  ...
  [    22.820] (II) intel(0): EDID for output LVDS1
  [    22.820] (II) intel(0): Manufacturer: AUO  Model: 213e  Serial#: 0
  [    22.820] (II) intel(0): EDID Version: 1.4
  ...
  [    22.820] (II) intel(0): Max Image Size [cm]: horiz.: 31  vert.: 17
  [    22.820] (II) intel(0): Gamma: 2.20
  ...
(with the ruler I measured it to be exactly 31.1 cm x 17.5 cm)
Then the size is confirmed in this lines:
  ...
  [    22.820] (II) intel(0): Supported detailed timing:
  [    22.820] (II) intel(0): clock: 110.0 MHz   Image Size:  309 x 174 mm
  [    22.820] (II) intel(0): h_active: 1600  h_sync: 1664  h_sync_end 1706 h_blank_end 2010 h_border: 0
  [    22.820] (II) intel(0): v_active: 900  v_sync: 903  v_sync_end 906 v_blanking: 912 v_border: 0
  [    22.820] (II) intel(0): Supported detailed timing:
  ...
  [    22.920] (II) intel(0): Using exact sizes for initial modes
  [    22.920] (II) intel(0): Output LVDS1 using initial mode 1600x900 +0+0
  ...
Next DPI is calculated properly by the intel driver (I am guessing):
  ...
  [    22.920] (**) intel(0): Display dimensions: (310, 170) mm
  [    22.920] (**) intel(0): DPI set to (131, 134)
  ...
Finally, image size is OVERRIDED by the intel driver with no explanation. It is set to wrong value:
  ...
  [    22.968] (II) AIGLX: Loaded and initialized i965
  [    22.968] (II) GLX: Initialized DRI2 GL provider for screen 0
  [    22.969] (II) intel(0): Setting screen physical size to 423 x 238
  [    23.036] (II) XKB: Reusing cached keymap
  ...
And this sucks. I cannot imagine how the X server would look like on a laptop with retina display, because of this bug.

Version-Release number of selected component (if applicable):
Name        : xorg-x11-drv-intel
Arch        : i686
Version     : 2.20.10
Release     : 2.fc17

  
Actual results:
Fonts are too small. Other thinks look tiny as well. Need glasses.

Expected results:
DPI should be set to reflect actual size of the screen

Additional info:
There is similar Bug #840271 reported for xorg-x11 in F16 with Nvidia card. It is possible that the issue is intrinsic to GNOME Shell or Cinnamon, which I am using or X11. There is also similar bug #863669 reported for RHEL's xorg-x11-server with laptop with NVidia card. But these bugs do not mention nor cite the line: "Setting screen physical size to" which I think is essential. They mention only the fact that xrandr and xdpyinfo give different results.

Also, I did corrected the entry in /etc/X11/Xresources
from:
  Xft.dpi: 96
to:
  Xft.dpi: 130
But this did not help at all.

Comment 1 Adam Jackson 2012-11-14 20:00:33 UTC
The log file is not API.  Don't look there for the DPI.  Look at the xrandr output.  What does xrandr report?

Comment 2 JanS 2012-11-15 16:46:21 UTC
XRandR output:

$> xrandr
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1600x900       60.0*+   40.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
--------

xpdyinfo output:
$> xdpyinfo 
name of display:    :0
...
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1600x900 pixels (423x238 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0xb1
  depth of root window:    24 planes
...
--------

Size of the display differs in both cases. 
I do not know how to get the true, current DPI of the system, but Gimp sais is is 96.
Gimp > Preferences > Display is set to "Detect automatically" this sais that currently it is 96 x 96 ppi.
Should be 130 x 130 dpi for this resolution and physical size.

Comment 3 Adam Jackson 2012-11-16 16:15:51 UTC
1600 / (309 / 25.4) == 131.5
900 / (174 / 25.4) == 131.4

So xrandr is telling you the truth, and gimp is simply using the wrong API.

Reassigning to gimp.

Comment 4 Fedora End Of Life 2013-07-04 01:27:15 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Fedora End Of Life 2013-08-01 05:52:36 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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