Comment 24 for bug 589485

(In reply to comment #23)
> IMO Xorg has no business making that inane assumption. Nevertheless, there is
> some rationale to do it that results in some distros doing it, e.g.
> http://wiki.mandriva.com/en/2009.0_Notes#Font_size_and_physical_DPI

While I cannot complain about the decisions of a distribution that I
don't use (maybe Mandriva users appreciate this), I must address some of
the points on that wiki page:

| ... bizarre results when the DPI detection system fails

Indeed, such as when it decides for some reason to set the DPI to 96
instead of 130+ like it should.

| no desktop environment's interface is yet fully resolution independent

Agreed: Things like the cover art images in my music player are rendered
at a fixed pixel size and are therefore somewhat small. Of course,
lying about the DPI doesn't actually fix this, but it does make it
impossible to correct the problem at the source (e.g. make my music
player display a 3x3 centimetre image instead of a 120x120 pixel image).

| characters could be much larger than the interface elements they are
| supposed to match

I have never, ever seen this. It certainly isn't a problem in any of
the GTK+, Qt, Open Motif or other applications that I use daily
(including applications that don't use any toolkit at all).

| Similar problems often occur on websites

I concede this point. Of course, as hinted above, this could be solved
by setting layout.css.dpi to 96 and disabling any minimum font size in
the default firefox configuration (I don't know if other browsers have
similar parameters). On a high resolution display, the price of this
configuration is that you only get to gawk at pretty layouts instead of
actually reading any information.

Personally, I find the "back" feature of my web browser to be a suitable
means of navigating websites which do not work on my computer.

| ... as many users are accustomed to in Microsoft Windows and Apple OS X

A serious question: How are high resolution displays usable at all on
these operating systems, considering how bad things look on a 135 DPI
when Xorg assumes it's a 96 DPI display? What do they do differently?

| ... can still adjust the DPI value in the KDE or GNOME Control Center,
| or simply increase the default font sizes.

There are two obvious problems with this solution:

1) With hundreds of applications, with different mechanisms for setting
their font sizes, one literally needs to edit dozens of config files to
increase the default font sizes for all programs. In an ideal world,
one would say "I like 9pt fonts for most text" and every program would
use that, but this is sadly not the case today.

2) Even if you fix all the default font sizes, or adjust the DPI value
in the KDE or GNOME Control Center, or with xrandr --fbmm for those who
don't use KDE or GNOME, such that everything's perfect: you have to do
it all over again when you change display devices. It also makes it
impossible to share config files between computers (e.g. an NFS-mounted
home directory).

I don't actually care if the *default* behaviour for Xorg is to use 96
DPI unconditionally. My gripe is that there is no (documented) way to
restore the autodetection (without patching the server): a config option
such as the one introduced by my patch solves this issue 100% for me.
And while the xrandr --fbmm hack posted above (that parses the xrandr
output to get the physical size to pass to xrandr) works without
patching Xorg, it's just too absurd to have to do that, and seems likely
to fail in the future.