Hi Jacopo, On Mon, Jan 08, 2024 at 10:19:35AM +0100, Jacopo Mondi wrote: > Hi Sakari, Vinay, > > a more foundamental question is how this usage of the crop/compose > API plays with the fact we enumerate only a limited set of frame > sizes, and now you can get an arbitrary output size. We could get away > by modifying enum_frame_sizes to return a size range (or ranges) but I > wonder if it wouldn't be better to introduce an internal pad to > represent the pixel array where to apply TGT_CROP in combination with > a source pad where we could apply TGT_COMPOSE and an output format. My earlier review wasn't focussed on the interface at all... To depart from the current restrictions on single-subdev sensor drivers, this is one option. Sensors implement various steps in different orders and different drivers have different capabilities, too. Mainly there are two classes: freely configurable drivers such cas CCS and then register list based drivers where virtually any dependencies between configurations are possible. We probably can't support both classes with the same API semantics and due to hardware differencies. The sensor UAPI will be less than uniform it has been in the past but I don't think this should be an issue. I wonder how much common understanding we have at this point on how this API would look like. Probably not much? -- Regards, Sakari Ailus
