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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
