Hello, On Tue, Jan 16, 2024 at 07:09:59PM +0000, Sakari Ailus wrote: > 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. I'm working on patches that implement an internal image pad, as part of the work to add embedded data support. I hope to post this in the near future. > 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, Laurent Pinchart
