how to disable gathering Display dimensions in xorg 7.3

Nicolas Mailhot nicolas.mailhot at
Mon Mar 10 15:54:17 PDT 2008

Le lundi 10 mars 2008 à 21:55 +0000, Magnus Kessler a écrit :

> Maybe we should first define what a "big display" is. I believe Alek has the 
> no longer uncommon case in mind where you try to display on a HDTV screen. 
> Typically these screens export their size in the EDID, and the X-server 
> will use these values by default.
> A plasma TV could have e.g. 1920x1080 pixels on a 42 inch screen. This would 
> correspond to approximately 52 dpi. With this resolution, a 10pt font would 
> be displayed about 7 pixels high, which is close to the limit of 
> readability.

TV screens are not able to display text properly, that was true in the
past and that's true today. A digital input does not change the fact
that TV manufacturers optimise for video that does not need the pixel
density of computer text.

So yes, it's true (HD)TV needs special treatment. But this treatment
does not limit itself to font scaling — when you've scaled fonts enough
they do not take a ridiculous number of pixels you quickly notice you do
not have the space left to display the quantity of text a
general-purpose app expects. (HD)TV requires specialised apps. Those
apps should never specify text size in points but always in pixels,
since anyway (HD)TV resolution is fixed and well known.

At this point the value of DPI as computed by xorg has no influence
whatsoever, be it in old or new xorg.

> I believe that for most use cases the user will be interested in the 
> apparent (angular) size rather than the absolute size in the plane of the 
> monitor.

The angular size is a nice theory but in practice it is absolutely
useless. Someday displays may acquire a viewing distance sensor, and may
distinguish between people looking at them and people passing by, and
someone may explain the heuristic to use to scale when the viewer moves
with respect to the screen or there are several viewers at different
distances. Till this happy time, angular size is the argument of people
who just want a 100% manual configuration but can not ask it directly
(as it would not withstand scrutinity).

Me, I prefer to consider that a computer screen is always in practice at
about the same distance from reader eyes (because space contraints mean
that moving it too far costs too much of desk space, moving too close is
not possible because of radiation/luminosity and the need to put the
keyboard somewhere). Since it's always at about the same distance using
a physical text size invariant (that the new xorg gives you) is a nice
way to adapt to differences in display pixel densities. The previous
"users will know the right dpi to select" proved that indeed they did
not. Newspapers and other oldtech media OTOH show people are perfectly
able to adapt to fixed physical size text in everyday life.

The exception are small embedded gadgets and projectors. The first
category needs a special UI just like HDTVs (with probably the same use
of pixel sizes, which is fine on high volume low variability specialized
hardware). The second category needs not a fine tunable like the dpi
level was, but a set of use-case models (long distance video projection,
medium distance presentation, close-up computer screen projection) from
which a fake level of usual dpi equivalence is derived. And a nice UI
for the user to select the right model on projector plug-in.

> In order to calculate this angular size one has to know both the 
> physical size of a pixel as well as the viewing distance. Maybe we should 
> allow to provide the viewing distance for an automatic calculation of the 
> angular size. 

No one will do it and this will be the return of the 96dpi mess.

> Until we have this capability it is probably a good compromise for most 
> setups to use a dpi setting of around 96 dpi (which happens to be the new 
> default setting).

It's not. Please do not revert to old-style fixed dpi value f-up. It's
highly adapted and favoured by young hackers with good eyes, and hated
by everyone else. The move to EDID-based actual DPI calculation is the
only sane thing to do. Yes it's painful but only because :
A. using a fixed dpi for tool long has made broken apps assume a fixed
pt/px ratio
B. DisplaySize autodetection needs to get more reliable (in other words,
bugs that will only be fixed if the facility is exercised)
Since the hardware and this ratio is changing, forcing it is no
future-proof solution.


Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <>

More information about the xorg mailing list