Why EDID is not trustworthy for DPI

[Adam Jackson]

On Tue, 2011-10-04 at 21:03 +0100, Camilo Mesias wrote:
> Hi,
> 
> On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson <ajax at redhat.com> wrote:
> > I am clearly going to have to explain this one more time, forever.
> > Let's see if I can't write it authoritatively once and simply answer
> > with a URL from here out.  (As always, use of the second person "you"
> > herein is plural, not singular.)
> 
> Thanks for the explanation... There is an alternative to endless
> explanation - roll out your best effort at a heuristic and let the
> crowd contribute to an ever growing set of exceptions.

I think you missed the part where I said I already had done so, that
you're already running them, and that I take patches.

I think building the giant database for DPI is a losing battle, and I
don't intend to work on it myself.  The bright line for the kernel's
current quirks list has so far been that we take quirks for fixing mode
setup, only.  Ancillary data like physical size just isn't something the
kernel needs to know.

But if people do insist on it, there's some points of implementation
that really should be considered, and I'm happy to discuss them.
Overriding EDID is a subtle problem once you get past wanting to make
just one permanently-connected display work on one machine.  If the
future being designed looks like "play with this complicated expert tool
until it works for you" then that's not really finished solving the
problem.  The next person who uses a sufficiently similar monitor with
the same set of EDID problems should never have to touch that tool.

How people use that information is entirely not my concern.  I have an
opinion and it's probably wrong in some cases and I am neither
advocating nor defending any such choices here.  I'm just here to tell
you that the hardware _is_ out to get you, and that the current
behaviour is in fact a considered choice and not simply willful malice.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111004/b6b087ca/attachment.bin