Hello, On 04/08/2011 02:53 PM, Hans Verkuil wrote: > Hi Tomasz! > > Some comments below... > > On Wednesday, April 06, 2011 10:44:17 Tomasz Stanislawski wrote: >> Hello everyone, >> >> This patch-set introduces new ioctls to V4L2 API. The new method for >> configuration of cropping and composition is presented. >> >> This is the second version of extcrop RFC. It was enriched with new features >> like additional hint flags, and a support for auxiliary crop/compose >> rectangles. >> >> There is some confusion in understanding of a cropping in current version of >> V4L2. For CAPTURE devices cropping refers to choosing only a part of input >> data stream and processing it and storing it in a memory buffer. The buffer is >> fully filled by data. It is not possible to choose only a part of a buffer for >> being updated by hardware. >> >> In case of OUTPUT devices, the whole content of a buffer is passed by hardware >> to output display. Cropping means selecting only a part of an output >> display/signal. It is not possible to choose only a part for a memory buffer >> to be processed. >> >> The overmentioned flaws in cropping API were discussed in post: >> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/28945 >> >> A solution was proposed during brainstorming session in Warsaw. >> ... >> - merge v4l2_selection::target and v4l2_selection::flags into single field >> - allow using VIDIOC_S_EXTCROP with target type V4L2_SEL_TARGET_BOUNDS to >> choose a resolution of a sensor Assuming here that the "resolution of a sensor" refers to the output resolution of a sensor with embedded ISP as seen by a bridge. Otherwise if it refers to the active pixel matrix resolution VIDIOC_S_EXTCROP(V4L2_SEL_TARGET_BOUNDS) would only make sense for sensors that support different pixel matrix layout, e.g. portrait/landscape. Something that Laurent brought to our attention during the Warsaw meeting, i.e. where actual sensor matrix contour is square but there are square polygons of dark pixels at each corner of the contour. > > Too obscure IMHO. That said, it would be nice to have a more explicit method > of selecting a sensor resolution. You can enumerate them, but you choose it > using VIDIOC_S_FMT, which I've always thought was very dubious. This prevents > any sensor-built-in scalers from being used. For video you have S_STD and IMHO sensor-built-in scalers can be used by means of the VIDIOC_[S/G]_CROP ioctls, which allows to select not only width/height of the part of a sensor matrix to be fed to the sensor's scaler but also a position of a pixel crop rectangle. > S_DV_PRESET that select a particular input resolution, but a similar ioctl is > missing for sensors. Laurent, what are your thoughts? > I suppose new ioctls like [G/S]_FRAMESIZE could be useful for selecting sensor's output resolution, those could then call sensor's pad set_fmt/get_fmt ops. Please note there are image sensors that support any resolution in their nominal range with some alignment requirements. For a maximum resolution 1024x1280 and 2 pixels alignment those would yield 327680 different resolutions. Does enum_framesizes make sense in such cases? There is currently no way to configure a scaler built in in the bridge with the regular V4L2 API though. Only the final output buffer resolution can be set with VIDIOC_S_FMT. We can select an active pixel array area with S_CROP. Depending where the cropping is actually performed - in an image sensor or in a bridge we are able to use sensor-built-in scaler OR bridge-built-in scaler, never both. Would setting sensor's output and bridge's input resolution with new VIDIOC_S_FRAMESIZE ioctl make sense? ......................................... ..................................... . . . . . G/S_CROP G/S_FRAMESIZE G/S_FMT . . (x,y) w1 x h1 . w2 x h2 . w3 x h3 . . +-------------+ +------------+ . . +------------+ +---------+ . . | | | | . . | | | | . . | Pixel | | ISP | . . | SCALER | | DMA | . . | matrix |_______| (scaler) |_______________| |_______| eng. | . . | | | | . . | (color | | | . . | | | | . . | converter) | | | . . | | | | . . | | | | . . +-------------+ +------------+ . . +------------+ +---------+ . . . . . . SENSOR PAD S0 PAD S1. . PAD B0 BRIDGE . ........................................ ..................................... Also how could one enumerate what media bus formats are supported at bridge input pad (PAD B0 in the ascii diagram above) if the bridge does not support the v4l2 subdev user space API and the application needs to match formats at pads PAD S1 and PAD B0 ? -- Regards, Sylwester Nawrocki -- 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
