Hi Hans, Am Donnerstag, den 28.08.2014, 19:41 +0200 schrieb Hans Verkuil: > On 08/28/2014 07:32 PM, Hans Verkuil wrote: > > On 08/28/2014 07:18 PM, Mauro Carvalho Chehab wrote: > >> I really don't see any gain on applying such patch. If the concern is > >> just about properly naming the pixel formats, it is a way easier to use > >> some defines for the names, and use the defines. > > > > It's not just the names, also the bit depth etc. Most drivers need that information > > and having it in a central place simplifies driver design. Yes, it slightly > > increases the amount of memory, but that is insignificant compared to the huge > > amount of memory necessary for video buffers. And reducing driver complexity is > > always good since that has always been the main problem with drivers, not memory > > or code performance. > > I just want to add that we should try out any core solution with an existing driver > (e.g. saa7134) to see if whatever solution we come up with actually makes drivers > less complex. The saa7134 is from what I've seen fairly representative of most in > that is has additional fields besides the name, fourcc and depth that are driver > specific. So how will that be handled... my main motivation was unification of the format description strings (well, not wanting to come up with possibly new ones for every driver), but reducing driver complexity is a nice side effect. I think saa7134 won't benefit a whole lot. It still needs to keep that list for the custom saa7134_format fields, but at least the common ones can be moved into a struct v4l2_pixfmt_info. The global array mostly has the potential to remove a little boilerplate from a lot of the simple cases that are happy with the per-format info already provided by the array. regards Philipp -- 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
