1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later 2.. c:namespace:: V4L 3 4.. _rw: 5 6********** 7Read/Write 8********** 9 10Input and output devices support the :c:func:`read()` and 11:c:func:`write()` function, respectively, when the 12``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct 13:c:type:`v4l2_capability` returned by the 14:ref:`VIDIOC_QUERYCAP` ioctl is set. 15 16Drivers may need the CPU to copy the data, but they may also support DMA 17to or from user memory, so this I/O method is not necessarily less 18efficient than other methods merely exchanging buffer pointers. It is 19considered inferior though because no meta-information like frame 20counters or timestamps are passed. This information is necessary to 21recognize frame dropping and to synchronize with other data streams. 22However this is also the simplest I/O method, requiring little or no 23setup to exchange data. It permits command line stunts like this (the 24vidctrl tool is fictitious): 25 26.. code-block:: none 27 28 $ vidctrl /dev/video --input=0 --format=YUYV --size=352x288 29 $ dd if=/dev/video of=myimage.422 bs=202752 count=1 30 31To read from the device applications use the :c:func:`read()` 32function, to write the :c:func:`write()` function. Drivers 33must implement one I/O method if they exchange data with applications, 34but it need not be this. [#f1]_ When reading or writing is supported, the 35driver must also support the :c:func:`select()` and 36:c:func:`poll()` function. [#f2]_ 37 38.. [#f1] 39 It would be desirable if applications could depend on drivers 40 supporting all I/O interfaces, but as much as the complex memory 41 mapping I/O can be inadequate for some devices we have no reason to 42 require this interface, which is most useful for simple applications 43 capturing still images. 44 45.. [#f2] 46 At the driver level :c:func:`select()` and :c:func:`poll()` are 47 the same, and :c:func:`select()` is too important to be optional. 48