Why EDID is not trustworthy for DPI

Matthew Garrett 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 
wouldn't.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list