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.
The log file is not API. Don't look there for the DPI. Look at the xrandr output. What does xrandr report?
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.
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.
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.
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.