Hi all, Hugues wants to add cropping support to the stm32-dcmi driver. The problem he encountered is that the sensor driver has a list of discrete framesizes and that causes problems with the API. Currently S_FMT is used to select which framesize to use. Which works fine as long as there is no crop or compose support. With that in the mix it is no longer clear whether S_FMT should change the crop rectangle or select the framesize. This is not a new problem, it's been discussed before 4 years (!) ago: http://www.spinics.net/lists/linux-media/msg65381.html But apparently it has never been an issue until now. Note that v4l2-compliance detects this specific case and complains about it. I propose that we close this API hole by requiring that such sensors support the V4L2_SEL_TGT_NATIVE_SIZE selection target: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/v4l2-selection-targets.html and set the V4L2_IN_CAP_NATIVE_SIZE input capability: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enuminput.html The application called S_SELECTION(V4L2_SEL_TGT_NATIVE_SIZE) to select which frame size to use. It will act the same as S_STD and S_DV_TIMINGS for video receivers: it resets the format and crop/compose rectangles to the native size. After that everything works normally. This is only needed for sensors that have multiple frame sizes and support cropping, composing and/or scaling. If it doesn't support any of this, then there is no need for this selection target since S_FMT is unambiguous in that case. All the ingredients are already in place, all that is needed is to update the documentation and v4l2-compliance. I looked at some of the sensors that appear to support both multiple framesizes and cropping and those that I looked at are at best dubious implementations. It is totally unclear which rectangle is cropped. Comments are welcome. Regards, Hans
