40 lines · plain
1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later2 3.. _selection-vs-crop:4 5********************************6Comparison with old cropping API7********************************8 9The selection API was introduced to cope with deficiencies of the10older :ref:`CROP API <crop>`, that was designed to control simple11capture devices. Later the cropping API was adopted by video output12drivers. The ioctls are used to select a part of the display were the13video signal is inserted. It should be considered as an API abuse14because the described operation is actually the composing. The15selection API makes a clear distinction between composing and cropping16operations by setting the appropriate targets.17 18The CROP API lacks any support for composing to and cropping from an19image inside a memory buffer. The application could configure a20capture device to fill only a part of an image by abusing V4L221API. Cropping a smaller image from a larger one is achieved by setting22the field ``bytesperline`` at struct :c:type:`v4l2_pix_format`.23Introducing an image offsets could be done by modifying field24``m_userptr`` at struct :c:type:`v4l2_buffer` before calling25:ref:`VIDIOC_QBUF <VIDIOC_QBUF>`. Those operations should be avoided26because they are not portable (endianness), and do not work for27macroblock and Bayer formats and mmap buffers.28 29The selection API deals with configuration of buffer30cropping/composing in a clear, intuitive and portable way. Next, with31the selection API the concepts of the padded target and constraints32flags are introduced. Finally, struct :c:type:`v4l2_crop` and struct33:c:type:`v4l2_cropcap` have no reserved fields. Therefore there is no34way to extend their functionality. The new struct35:c:type:`v4l2_selection` provides a lot of place for future36extensions.37 38Driver developers are encouraged to implement only selection API. The39former cropping API would be simulated using the new one.40