On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K <mythripk@xxxxxx> wrote: > Adding support for common EDID parsing in kernel. > > EDID - Extended display identification data is a data structure provided by > a digital display to describe its capabilities to a video source, This a > standard supported by CEA and VESA. > > There are several custom implementations for parsing EDID in kernel, some > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > parsing of EDID should be done in a library, which is agnostic of the > framework (V4l2, DRM, FB) which is using the functionality, just based on > the raw EDID pointer with size/segment information. > > With other RFC's such as the one below, which tries to standardize HDMI API's > It would be better to have a common EDID code in one place.It also helps to > provide better interoperability with variety of TV/Monitor may be even by > listing out quirks which might get missed with several custom implementation > of EDID. > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > > This patch tries to add functions to parse some portion EDID (detailed timing, > monitor limits, AV delay information, deep color mode support, Audio and VSDB) > If we can align on this library approach i can enhance this library to parse > other blocks and probably we could also add quirks from other implementation > as well. > If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
