Why EDID is not trustworthy for DPI

Simo Sorce simo at redhat.com
Wed Oct 5 19:44:24 UTC 2011


On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote:
> On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote:
> 
> > 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.
> 
> There's no _magic_ way to fix anything, no. Things get fixed by code
> writers writing code. That would seem to be the obvious thing to do...
> 
> Like I replied to ajax, I suspect when the problem of assuming
> everything's 96dpi becomes simply too acute, instead of fixing
> everything really properly so that all displays correct report their
> size and all desktops actually do resolution independence perfectly so
> it doesn't _matter_ if one of your displays is 98dpi and the other is
> 215dpi, everything still looks perfect, the industry will just wind up
> with a slightly more sophisticated bodge where we have a few 'standard'
> resolutions and just figure out which one your displays are closest to.
> But that's still going to require some kind of sensible handling of the
> case where one monitor is roughly 100dpi and the other is roughly
> 200dpi, unless we simply say 'you can't do that, all your displays have
> to be in the same DPI Category'.

Are you saying fonts should change on the fly when I move an app between
2 monitors that have different DPIs ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list