Hi Florian, <snip> > >> So why should this be a common library? Most kernel code doesn't need >> it. Or is there a serious need for video input to parse EDIDs? > > It's true that most kernel code does not need it as it is only useful for > display output systems (and only the ones that can be connected to something > sending EDID data) but it would be good anyway. > Because sharing code that should fulfill the same purpose is always a good > idea. But of course only if the scope is clearly limited as we don't want to > end up with a mess that nobody dares touching again as it became to complex. > So I totally agree that we should share the common stuff we all need and > adding the extras one needs in the subsystem/driver. > This is good because it looks like we'll have 3 display subsystems within > the kernel for a long future and with a common library the same patch would > not need to be done 3 times but only once. Or even more often if drivers > have there private EDID implementation which I just throw out of mine to > replace it later with a common one. > Precisely my point . Also if there are some bad TV models which doesn't adhere to standard EDID, It would help to add quirks. Anyone out there want to help me split the DRM code ? As i don't want DRMer's to fret over changed code :). Thanks and regards, Mythri. > Regards, > > Florian Tobias Schandinat > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
