Hi Laurent, On 02/02/2014 10:45 AM, Laurent Pinchart wrote: > Hi Hans, > > Thank you for the patches. > > On Friday 31 January 2014 12:12:04 Hans Verkuil wrote: >> Devices with a simple video pipeline may want to inherit private controls >> of sub-devices and expose them to the video node instead of v4l-subdev >> nodes (which may be inhibit anyway by the driver). >> >> Add support for this. >> >> A typical real-life example of this is a PCI capture card with just a single >> video receiver sub-device. Creating v4l-subdev nodes for this is overkill >> since it is clear which control belongs to which subdev. > > The is_private flag has been introduced to allow subdevs to disable control > inheritance. We're now adding a way for bridges to override that, which makes > me wonder whether private controls are really the best way to express this. > > Shouldn't we think about what we're trying to achieve with controls and places > where they're exposed and then possibly rework the code accordingly ? I think is_private should be renamed to is_protected (as used in C++) and inheriting protected controls is similar to marking a class as 'friend' in C++. That's the mechanism I have in mind. So is_private -> is_protected and the proposed inherit_private_ctrls field becomes inherit_protected_ctrls. There are only a handful of drivers that set is_private today, so it is easy enough to rename. What do you think? Regards, Hans -- 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
