<p>Thanks for writing this up! It was good info.<br>
On Oct 4, 2011 7:55 PM, "Adam Jackson" <<a href="mailto:ajax@redhat.com">ajax@redhat.com</a>> wrote:<br>
><br>
> On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote:<br>
><br>
> > Grovelling around in the F15 xorg-server sources and reviewing the Xorg<br>
> > log file on my F15 box, I see, with _modern hardware_ at least, that we<br>
> > do have the monitor geometry available from DDC or EDIC, and obviously<br>
> > it is trivial to compute the actual, correct DPI for each screen.<br>
><br>
> I am clearly going to have to explain this one more time, forever.<br>
> Let's see if I can't write it authoritatively once and simply answer<br>
> with a URL from here out. (As always, use of the second person "you"<br>
> herein is plural, not singular.)<br>
><br>
> EDID does not reliably give you the size of the display.<br>
><br>
> Base EDID has at least two different places where you can give a<br>
> physical size (before considering extensions that aren't widely deployed<br>
> so whatever). The first is a global property, measured in centimeters,<br>
> of the physical size of the glass. The second is attached to your (zero<br>
> or more) detailed timing specifications, and reflects the size of the<br>
> mode, in millimeters.<br>
><br>
> So, how does this screw you?<br>
><br>
> a) Glass size is too coarse. On a large display that cm roundoff isn't<br>
> a big deal, but on subnotebooks it's a different game. The 11" MBA is<br>
> 25.68x14.44 cm, so that gives you a range of 52.54-54.64 dpcm horizontal<br>
> and 51.20-54.86 dpcm vertical (133.4-138.8 dpi h and 130.0-139.3 dpi v).<br>
> Which is optimistic, because that's doing the math forward from knowing<br>
> the actual size, and you as the EDID parser can't know which way the<br>
> manufacturer rounded.<br>
><br>
> b) Glass size need not be non-zero. This is in fact the usual case for<br>
> projectors, which don't have a fixed display size since it's a function<br>
> of how far away the wall is from the lens.<br>
><br>
> c) Glass size could be partially non-zero. Yes, really. EDID 1.4<br>
> defines a method of using these two bytes to encode aspect ratio, where<br>
> if vertical size is 0 then the aspect ratio is computed as (horizontal<br>
> value + 99) / 100 in portrait mode (and the obvious reverse thing if<br>
> horizontal is zero). Admittedly, unlike every other item in this list,<br>
> I've never seen this in the wild. But it's legal.<br>
><br>
> d) Glass size could be a direct encoding of the aspect ratio. Base EDID<br>
> doesn't condone this behaviour, but the CEA spec (to which all HDMI<br>
> monitors must conform) does allow-but-not-require it, which means your<br>
> 1920x1080 TV could claim to be 16 "cm" by 9 "cm". So of course that's<br>
> what TV manufacturers do because that way they don't have to modify the<br>
> EDID info when physical construction changes, and that's cheaper.<br>
><br>
> e) You could use mode size to get size in millimeters, but you might not<br>
> have any detailed timings.<br>
><br>
> f) You could use mode size, but mode size is explicitly _not_ glass<br>
> size. It's the size that the display chooses to present that mode.<br>
> Sometimes those are the same, and sometimes they're not. You could be<br>
> scaled or {letter,pillar}boxed, and that's not necessarily something you<br>
> can control from the host side.<br>
><br>
> g) You could use mode size, but it could be an encoded aspect ratio, as<br>
> in case d above, because CEA says that's okay.<br>
><br>
> h) You could use mode size, but it could be the aspect ratio from case d<br>
> multiplied by 10 in each direction (because, of course, you gave size in<br>
> centimeters and so your authoring tool just multiplied it up).<br>
><br>
> i) Any or all of the above could be complete and utter garbage, because<br>
> - and I really, really need you to understand this - there is no<br>
> requirements program for any commercial OS or industry standard that<br>
> requires honesty here, as far as I'm aware. There is every incentive<br>
> for there to _never_ be one, because it would make the manufacturing<br>
> process more expensive.<br>
><br>
> So from this point the suggestion is usually "well come up with some<br>
> heuristic to make a good guess assuming there's some correlation between<br>
> the various numbers you're given". I have in fact written heuristics<br>
> for this, and they're in your kernel and your X server, and they still<br>
> encounter a huge number of cases where we simply _cannot_ know from EDID<br>
> anything like a physical size, because - to pick only one example - the<br>
> consumer electronics industry are cheap bastards, because you the<br>
> consumer demanded that they be cheap.<br>
><br>
> And then your only recourse is to an external database, and now you're<br>
> up the creek again because the identifying information here is a<br>
> vendor/model/serial tuple, and the vendor can and does change physical<br>
> construction without changing model number. Now you get to play the<br>
> guessing game of how big the serial number range is for each subvariant,<br>
> assuming they bothered to encode a serial number - and they didn't. Or,<br>
> if they bothered to encode week/year of manufacturer correctly - and<br>
> they didn't - which weeks meant which models. And then you still have<br>
> to go out and buy one of every TV at Fry's, and that covers you for one<br>
> market, for three months.<br>
><br>
> If someone wants to write something better, please, by all means. If<br>
> it's kernel code, send it to <a href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a> and cc me<br>
> and I will happily review it. Likewise xorg-devel@ for X server<br>
> changes.<br>
><br>
> I gently suggest that doing so is a waste of time.<br>
><br>
> But if there's one thing free software has taught me, it's that you can<br>
> not tell people something is a bad idea and have any expectation they<br>
> will believe you.<br>
><br>
> > Obviously in a multi-screen set-up using Xinerama this has the potential<br>
> > to be a Hard Problem if the monitors differ greatly in their DPI.<br>
> ><br>
> > If the major resistance is over what to do with older hardware that<br>
> > doesn't have this data available, then yes, punt; use a hard-coded<br>
> > default. Likewise, if the two monitors really differ greatly, then punt.<br>
><br>
> I'm going to limit myself to observing that "greatly" is a matter of<br>
> opinion, and that in order to be really useful you'd need some way of<br>
> communicating "I punted" to the desktop.<br>
><br>
> Beyond that, sure, pick a heuristic, accept that it's going to be<br>
> insufficient for someone, and then sit back and wait to get<br>
> second-guessed on it over and over.<br>
><br>
> > And it wouldn't be so hard to to add something like -dpi:0, -dpi:1,<br>
> > -dpi:2 command line options to specify per-screen dpi. I kinda thought I<br>
> > did that a long, long time ago, but maybe I only thought about doing it<br>
> > and never actually got around to it.<br>
><br>
> The RANDR extension as of version 1.2 does allow you to override<br>
> physical size on a per-output basis at runtime. We even try pretty hard<br>
> to set them as honestly as we can up front. The 96dpi thing people<br>
> complain about is from the per-screen info, which is simply a default<br>
> because of all the tl;dr above; because you have N outputs per screen<br>
> which means a single number is in general useless; and because there is<br>
> no way to refresh the per-screen info at runtime, as it's only ever sent<br>
> in the initial connection handshake.<br>
><br>
> - ajax<br>
><br>
> --<br>
> devel mailing list<br>
> <a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
> <a href="https://admin.fedoraproject.org/mailman/listinfo/devel">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
</p>