Bug 6004 - Xorg.log and xdpyinfo report different real screen size (in mm)
Summary: Xorg.log and xdpyinfo report different real screen size (in mm)
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.0.0
Hardware: All Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on: 15865
  Show dependency treegraph
Reported: 2006-02-23 02:42 UTC by Matthias Saou
Modified: 2018-12-13 22:16 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Matthias Saou 2006-02-23 02:42:00 UTC
This is a bug report copied over from here :

I've got FC development on an x86_64, with an ATI Radeon 9200SE card, connected
to a 37" LCD TV through DVI.

In my Xorg.log file, I can see :
(--) RADEON(0): Display dimensions: (820, 460) mm
(--) RADEON(0): DPI set to (31, 42)

Which is the correct real size (yes, it's big!). But in X, xdpyinfo reports :
screen #0:
  print screen:    no
  dimensions:    1024x768 pixels (839x464 millimeters)
  resolution:    31x42 dots per inch

The reported size differs slightly, and the calculated aspect ratio too. This
doesn't make much sense to me, since people forcing the screen size in
xorg.conf would probably expect to get the same values from xdpyinfo. Or is
there an explanation for this difference in values?
Comment 1 Daniel Stone 2007-02-27 01:30:37 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 2 Matthias Saou 2007-02-27 02:14:24 UTC
I've opened this bug report over a year ago. Does someone at least know if it's really a bug or of it is something to be expected? It's just plain confusing having different physical sizes, but who knows... (not me!)
Comment 3 Matthias Saou 2007-11-26 00:22:05 UTC
I've recently updated the same setup to Fedora 8, with :

Now the behavior is different. In Xorg.log :
(II) RADEON(0): Manufacturer: BNQ  Model: 7511  Serial#: 130
(II) RADEON(0): Year: 2005  Week: 51
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max H-Image Size [cm]: horiz.: 82  vert.: 46
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) RADEON(0): Default color space is primary color space
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.636 redY: 0.346   greenX: 0.271 greenY: 0.589
(II) RADEON(0): blueX: 0.139 blueY: 0.062   whiteX: 0.294 whiteY: 0.311
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): 720x400@70Hz
(II) RADEON(0): 640x480@60Hz
(II) RADEON(0): 640x480@72Hz
(II) RADEON(0): 640x480@75Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@72Hz
(II) RADEON(0): 800x600@75Hz
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): 1024x768@70Hz
(II) RADEON(0): 1024x768@75Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported Future Video Modes:
(II) RADEON(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  338 x 270 mm
(II) RADEON(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) RADEON(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 v_border: 0
(II) RADEON(0): Monitor name: BenQ
(II) RADEON(0): Monitor name: DV3750
(II) RADEON(0): Ranges: V min: 50  V max: 75 Hz, H min: 31  H max: 64 kHz, PixClock max 110 MHz
(II) RADEON(0): EDID (in hex):

And xdpyinfo now reports :
screen #0:
  dimensions:    1280x1024 pixels (338x270 millimeters)
  resolution:    96x96 dots per inch

So the reported screen size is consistent, unfortunately the 338x270mm is probably the size of the 1280x1024 output when centered on the TV's 1980x1080 pixels, and since I have the TV stretch the image to fill the screen, I need to have X use the 82x46cm size it detects as the maximum size. It used to use it, but not anymore. (this TV doesn't support any resolution higher than 1280x1024 through the DVI port, unfortunately!)

I've tried adding "DisplaySize 820 460" to the Monitor section of xorg.conf, but it didn't help. I've also looked at the ati/radeon driver specific options, but found none which would allow me to force the size.

So right now, with the display stretched to fill the screen, applications like totem and xine have a wrong aspect ratio since they use what X reports. They used to work fine before, when the biggest size was used.
Comment 4 Felix Miata 2015-01-17 06:12:30 UTC
What is happening when there is an observed difference is that xdpyinfo (and when it appears, "Display dimensions") is presenting size ostensibly "accurate" to nearest mm integers, while the differing sizes are derived from "Max Image Size" presented in cm integers, thus producing (usually) errant mm sizes that end in 0. Such differences remain in openSUSE 13.2 running 3.16 kernel and server 1.16.1 e.g.:

[  2391.354] (II) RADEON(0): Max Image Size [cm]: horiz.: 41  vert.: 31
$ xdpyinfo | egrep 'dimen|ution'
  dimensions:    1600x1200 pixels (409x307 millimeters)
  resolution:    99x99 dots per inch

The display used for above is a Dell 2000FP, advertised as 20.1" in marketing literature. The openSUSE monitor-edid utility reports as follows for this device:
	# Monitor preferred modeline (60.0 Hz vsync, 75.0 kHz hsync, ratio 4/3, 99 dpi)
	ModeLine "1600x1200" 162 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

In order to achieve the 409x307 that xdpyinfo reported it is/was necessary to force the server to use 409 and 307, either through xrandr --dpi 96 or xrandr --fbmm 409x307 or "DisplaySize 409 307". Otherwise the server forces DPI to 96, in which case the following are reported:

[  3577.254] (II) RADEON(0): Max Image Size [cm]: horiz.: 41  vert.: 31
$ xdpyinfo | egrep 'dimen|ution'
  dimensions:    1600x1200 pixels (423x317 millimeters)
  resolution:    96x96 dots per inch

423x317 millimeters is the size required to achieve 96 logical DPI, the density assumed by default on Windows and Mac. That assumption enables web sites in browsers run in Xorg to have high similarity to how they display and work on those other platforms. Those are not the physical display dimensions, no matter how accurately they are measured or by whom. When I measure with a meter stick, I get a plastic bezel opening of 410mm by 308mm, but an LCD mask (visible image) opening of 409mm by 307mm.

The disparity between measured and reported grows as displays forced to 96 DPI grow in size, such as the 37" screen of comment 0. For most using a more recent model screen that size, the force to 96 would produce dimensions (in 1920x1080 mode) of 508 by 285, a far cry from either set in that comment, same as does an XVT323SV TV screen via default server automagic:

Screen size: 69.8 cm x 39.3 cm (31.54 inches, aspect ratio 16/9 = 1.78)
	# Monitor preferred modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 69 dpi)
	ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
[    74.241] (II) RADEON(0): Max Image Size [cm]: horiz.: 70  vert.: 39
$ xdpyinfo | egrep 'dimen|ution'
  dimensions:    1920x1080 pixels (508x285 millimeters)
  resolution:    96x96 dots per inch

Forced to its 69 DPI specification via manual configuration:

[  1306.539] (II) RADEON(0): Max Image Size [cm]: horiz.: 70  vert.: 39
$ xdpyinfo | egrep 'dimen|ution'
  dimensions:    1920x1080 pixels (702x395 millimeters)
  resolution:    69x69 dots per inch

And to its 698mm by 393mm specification via manual configuration:

[  1727.460] (II) RADEON(0): Max Image Size [cm]: horiz.: 70  vert.: 39
$ xdpyinfo | egrep 'dimen|ution'
  dimensions:    1920x1080 pixels (698x393 millimeters)
  resolution:    70x70 dots per inch

Since the server began forcing 96 DPI by default (after this report was filed), dimensions reported have been logical rather than physical. So, whatever numbers are reported could be said to amount to fiction in every case in which both the display does not have a physical density of 96 DPI, and manual configuration has not been applied to change display dimensions or DPI. That makes it hard to say which, if any, are correct, or wrong. Thus IMO, as long as 96 DPI continues to be forced by default, it would hardly be worth anyone's time to synchronize them even if doing so could be deemed viable.
Comment 5 GitLab Migration User 2018-12-13 22:16:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/340.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.