Readding intel-gfx. On Wed, Feb 18, 2015 at 5:57 PM, Todd Previte <tprevite@xxxxxxxxx> wrote: > On 12/17/14 1:20 PM, Daniel Vetter wrote: >> Just something random I've spotted while driving by: drm_get_edid does all >> the checksum stuff for you already (it retries up to 4 times if the >> checkusm is off and also checks a few other things). We should never reach >> this case and the checksum function is essentially dead code. >> >> Or do I miss something? >> -Daniel >> > > The data I have is that when connected to the DPR-100, the logs show that > the EDID checksum is incorrect from the DRM routines, which is why I went > and wrote this one. This is most likely a problem with the DPR-100 (that > they won't fix since they're not updating it anymore) and possibly still a > problem with the DPR-120 (which I can't test because I don't have one). So > this code is necessary in order to pass the EDID tests when using the > DPR-100. > > That said, it's also unlikely that the DRM routines are wholly wrong, since > that would result in many, many errors in the logs for all the shipping DP > monitors out there. So this is one case where special code is necessary in > order to pass the tests with a particular test device. If that's the case then we need to add some quirks to the core edid code (we have plenty of those already, shipping hw tends to be broken in all sorts of interesting ways). At least I don't see a point in passing compliance in such an important aspect as validating sink behaviour by adding special-purpose code instead of the code we use for real hw. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
