Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

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!)

I've recently updated the same setup to Fedora 8, with :
xorg-x11-server-Xorg-1.3.0.0-33.fc8
xorg-x11-drv-ati-6.7.196-1.fc8

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.

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.

-- 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.