On Thu, Aug 05, 2021 at 06:49:33PM +0300, Laurent Pinchart wrote: > Hi Sakari, > > On Thu, Aug 05, 2021 at 06:40:42PM +0300, Sakari Ailus wrote: > > On Thu, Aug 05, 2021 at 06:22:32PM +0300, Laurent Pinchart wrote: > > > On Thu, Jul 22, 2021 at 01:12:48PM +0100, David Plowman wrote: > > > > We add new controls, one for each of the four usual Bayer channels: > > > > > > > > V4L2_CID_NOTIFY_GAIN_RED > > > > V4L2_CID_NOTIFY_GAIN_GREENR > > > > V4L2_CID_NOTIFY_GAIN_BLUE > > > > V4L2_CID_NOTIFY_GAIN_GREENB > > > > > > This will effectively limit the API to Bayer patterns. I wonder if we > > > should instead implement it as a single array control, with one element > > > per CFA component. > > > > There are other raw patterns, too. Supporting them would likely require one > > or a few more controls. > > > > That said, as the values change often it's more efficient to use a single > > control. But each colour combination (not each pattern) would require its > > own control in this case, eventually requiring more controls. > > I'm not sure to follow you. My idea is to define a single control, with > a number of elements that depends on the pattern being used, and the > order specified in the native sensor pattern. I don't think each colour > combination would then require its own control. Ah, I guess that would work, too. Then we'll need to define what kind of pixel orders are supported for that single control (and for which formats). -- Sakari Ailus
