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@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
