Why EDID is not trustworthy for DPI

Nicolas Mailhot nicolas.mailhot at laposte.net
Thu Oct 6 15:05:37 UTC 2011


Le Jeu 6 octobre 2011 16:33, Matthew Garrett a écrit :
> On Thu, Oct 06, 2011 at 09:30:50AM -0500, Chris Adams wrote:
>> Once upon a time, Matthew Garrett <mjg59 at srcf.ucam.org> said:
>> > Like I said, that works fine right up until the point where you plug in
>> > a monitor with a different DPI. What do we do then?
>>
>> I would wager that the majority of Fedora systems are single monitor
>> (or, in the case of notebooks, single monitor much of the time); can't
>> we at least try to correct for that case first, and _then_ try to deal
>> with multi-monitor setups?
>
> Changing the current behaviour doesn't make the most common case
> significantly better, but potentially makes a less common (but still
> common) case significantly worse. What's the benefit?

Have the same font size value mean the same thing in gnome and not-gnome apps?

Help people who use several computers calibrate them so they get the same font
sizes on all of them without having to remember size 14 means something on one
computer and another on others?

Support single-screen high-density screen setups by default?

Make network homes work as long as every client uses a display with working EDID?

Really, this focus on not letting people provide simple display sizes when the
EDID is broken¹ is ridiculous. Especially when *at the same time* GNOME 3.2
advertises support for colour correcting displays using ridiculously complex
procedures²

As you've already pointed out, the new heuristic does not solve the complex
cases. So it's no use enumerating them to justify it. It won't make them go
away and they will need handling sooner or later with the heuristic or without
it. In the meanwhile all the heuristic does is introduce inconsistencies in
font handling between GNOME and everyone else.

¹ Which BTW is not the general case, most EDIDs are fine and have been for years
² Which I support (and indeed have packaged argyll for Fedora in the past) but
it is hardly simple

-- 
Nicolas Mailhot



More information about the devel mailing list