Why EDID is not trustworthy for DPI
mjg59 at srcf.ucam.org
Wed Oct 5 17:49:05 UTC 2011
On Wed, Oct 05, 2011 at 09:26:59AM -0700, Adam Williamson wrote:
> You just did, sorry. ;) Hardware sucks. We know this. Fedora generally
> takes the position that it's correct to engineer things properly and
> regretfully explain that the hardware sucks when this causes problems,
> not engineer hacks and bodges to account for broken hardware.
Really? Because honestly if that's the position we generally hold then
I'm just closing most of my bugs WONTFIX from here on out.
There are multiple issues here. The first is that X reports a 96dpi
value because X can only report one value, so it might as well pick
something that at least roughly matches user expectations. But like Adam
says, randr gives you the per head measurements and you could work
things out from there.
But then things get awkward. That information is often lies. So we can
add a heuristic that clamps the DPI to something in-between 72 and 250
and we probably won't exclude any real displays right now, but we do
know that even by absolute standards some people are suddenly going to
have tiny fonts and some people are suddenly going to have huge fonts
because the hardware lies. But we'll write that off as broken hardware.
(You've also changed expected behaviour, because lots of people *want*
small fonts on high-DPI screens, but again let's just chalk that up to
incorrect expectations and make sure there's an easy UI that lets them
change their global font size)
So, ok, now you have some belief about the DPI. But which DPI? If you're
dual head, you've got two. Unless they match you're screwed - there's no
magic way to get applications to reflow text just because you've moved
the window between screens, and what would you do with a window that's
halfway between? You can argue that this is a corner case and obviously
yes it's a corner case but if you can't even pretend to fix the corner
case then your solution isn't a solution any more than 96dpi is.
But what about the single monitor case? Let's go back to your Vaio. It's
got a high DPI screen, so let's adjust to that. Now you're happy. Right
up until you plug in an external monitor and now when you run any
applications on the external display your fonts are twice the size they
should be. WOOHOO GO TEAM of course that won't make us look like
amateurs at all. So you need another heuristic to handle that, and of
course "heuristic" is an ancient african word meaning "maybe bonghits
will make this problem more tractable".
We have no technological solution for dealing with the fact that
applications may move from one DPI to another at runtime, and may even
be displaying on both displays at once. All of which doesn't matter, of
course, because we don't even have a well-defined problem statement.
What are we actually trying to solve here?
Honestly, it's valuable for applications to be able to identify the DPI
of the screen they're running on. For certain design purposes it may
well be helpful for an application to have "100%" map to "this is what a
sheet of paper the same distance away would look like", and so the fact
that this is available to applications is a good thing.
But is it valuable for "My fonts and icons look different on different
displays"? Sure, if you only ever use a single display, which is no
longer the ubiquitous situation that it used to be. Or, in other words,
no. It's not valuable.
How about "My fonts are too small on my high-DPI laptop"? Well, yes,
that's a problem. And we should ensure that there's a usable way for you
to fix that. But really in that situation my first port of call would be
to search the font settings for a button that says "Make my fonts
bigger", not to look in display settings for something that lets me drag
a bar across the screen to line up with a ruler.
In summary: Accurate DPI measurement is a means to an end, not an
end in itself. Define the problem you're trying to solve, and then work
out whether figuring out the real DPI would solve it. Unless your
problem statement is unrealistically narrow, the answer is that it
Matthew Garrett | mjg59 at srcf.ucam.org
More information about the devel