Bug 20545 - For God's sake, please ignore EDID DPI and just default to 96!
Summary: For God's sake, please ignore EDID DPI and just default to 96!
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: high enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-08 13:56 UTC by Tom Horsley
Modified: 2015-04-23 17:52 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Tom Horsley 2009-03-08 13:56:14 UTC
I've never found a monitor where 96 DPI fonts were not readable. I've frequently
found monitors where slavish adherence to EDID computed DPI info resulted in
hopelessly unusable font sizes. Either to small to even tell what they say
(so you have great difficulty navigating to a font settings page to change
them), or so large that the font settings dialog won't fit on the screen, so you
still have great difficulty changing them.

Having defaulted to 96, you should also provide a way for users to set their
preferred DPI on a per-monitor/user basis (I can easily imagine a multi-display
setup where I want 96DPI on one monitor and 75 on another).

Some video drivers support per-driver parameters to override DPI (nvidia
for instance), but it is absurd for this to be a hardware specific driver
setting, everyone needs to be able change this no matter which video driver
they are using.

Both GNOME and KDE have font setting dialogs where you can override DPI, but
those only work for apps in written in specific toolkits and then apply across
all displays even if different DPI would be better for different displays,
and apps in other toolkits are just out of luck.

Once upon a time, before X got all anal about using EDID in preference to
user settings, you could simply lie about the display dimensions and
induce it to calculate the desired DPI, now the pursuit of readable fonts
has gotten infinitely more difficult.

For more tales of DPI horror, read: http://braindump.home.att.net/dpi.html

Of course, DPI, may not be the only thing wrong with slavish adherence
to EDID. Maybe what is really needed is an EdidFilter module which could
tweak EDID info based on which monitor provided it before it ever gets
to the rest of the X server.
Comment 1 James Cloos 2009-03-10 12:26:58 UTC
Personally, I always set dpi at the startx command line.

My startup script looks essentially like:

startx -- -dpi 133 -retro -nolisten tcp "${*}"
Comment 2 Tom Horsley 2009-03-10 16:24:59 UTC
Yea, I used to be able to do that until GDM "improved" so much that you
can't control the server options. And a global setting probably isn't
as good as a per-monitor setting for a multi-monitor setup (since the
monitors might have radically different resolutions).
Comment 3 Adam Williamson 2009-05-19 18:59:50 UTC
"I've never found a monitor where 96 DPI fonts were not readable."

I own one. It's called a Sony Vaio P. 1600x768, 8" monitor. Its natural DPI is around 180. Set to 96, fonts at normal sizes (9-12pt range) are so small as to be more or less unreadable (if you look for reviews of the Vaio P, this is a common complaint from reviewers, who are apparently unaware of the intricacies of resolution dependence in font sizing).

There are other similarly high-resolution displays for which 96dpi is a terrible setting, and they will only become more common over time. Particularly where X is deployed on e-ink displays...
Comment 4 Felix Miata 2009-05-19 19:51:42 UTC
Seems to me DPI ought to be directly configurable on a per display basis via xorg.conf to the exclusion of all other methods. DPI can be defaulted to the greater of 96 or DDC/EDID provided display characteristics, but overriding either directly (for those wanting some particular DPI, e.g. 'Option "DPI" "132x132"') or indirectly (e.g. 'DisplaySize 495 310') should be enforced regardless of gfxchip or driver.

Those who want to use some GUI tool to handle the configuration it can have some GUI tool change a local xorg.conf, with a possible option as superuser to change it globally.

The current DPI customization settings elsewhere in X, Gnome, KDE & anywhere else should be abandoned.

Xrandr could be used to make changes to an active session, but this/these should not survive a session restart without being integrated into xorg.conf, if then, so that control of any global non-default setting can be found in one single FHS location, or non-globally in one single location in the user's home tree (e.g. ~/.config/xorg.conf).

Alternatively, /etc/X11/Xresources & ~/.xresources could be be used instead of xorg.conf, but it/they would have to be enforced by Xorg as the only valid place(s) for overriding DDC/EDID calculated or 96 DPI defaults.
Comment 5 Stanislav Brabec 2009-08-28 08:47:54 UTC
Idea in the bug 23577 is partially related to this issue.
Comment 6 Adam Jackson 2010-08-09 13:27:18 UTC
Yawn.
Comment 7 Michael Shigorin 2015-04-23 17:52:18 UTC
(In reply to Tom Horsley from comment #0)
> I've never found a monitor where 96 DPI fonts were not readable.
It's because you're cheapskate buying junk to look at.  And if you had any brains you'd probably understand that it's not gonna help to shoot the messenger (suppress DPI) but there might be a need to provide a UI magnification knob which is *completely* irrelevant to the physical DPI question.

And your fanatical/idiotical/younameit "rationale" at https://home.comcast.net/~tomhorsley/game/dpi.html#Rationale doesn't even get that it's the COMMON case that should be optimized for, not the CORNER (aye I've worked with X11 on several large plasma displays and tuned things up a bit, but that was expected as the setup was quite custom anyways).

Ah, and the disclaimer: I can testify for each word *characterizing* you, no need to even feel offended by someone grumpy over there looking at a 166dpi :0.


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.