239 lines · plain
1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later2.. c:namespace:: V4L3 4.. _open:5 6***************************7Opening and Closing Devices8***************************9 10.. _v4l2_hardware_control:11 12Controlling a hardware peripheral via V4L213==========================================14 15Hardware that is supported using the V4L2 uAPI often consists of multiple16devices or peripherals, each of which have their own driver.17 18The bridge driver exposes one or more V4L2 device nodes19(see :ref:`v4l2_device_naming`).20 21There are other drivers providing support for other components of22the hardware, which may also expose device nodes, called V4L2 sub-devices.23 24When such V4L2 sub-devices are exposed, they allow controlling those25other hardware components - usually connected via a serial bus (like26I²C, SMBus or SPI). Depending on the bridge driver, those sub-devices27can be controlled indirectly via the bridge driver or explicitly via28the :ref:`Media Controller <media_controller>` and via the29:ref:`V4L2 sub-devices <subdev>`.30 31The devices that require the use of the32:ref:`Media Controller <media_controller>` are called **MC-centric**33devices. The devices that are fully controlled via V4L2 device nodes34are called **video-node-centric**.35 36Userspace can check if a V4L2 hardware peripheral is MC-centric by37calling :ref:`VIDIOC_QUERYCAP` and checking the38:ref:`device_caps field <device-capabilities>`.39 40If the device returns ``V4L2_CAP_IO_MC`` flag at ``device_caps``,41then it is MC-centric, otherwise, it is video-node-centric.42 43It is required for MC-centric drivers to identify the V4L244sub-devices and to configure the pipelines via the45:ref:`media controller API <media_controller>` before using the peripheral.46Also, the sub-devices' configuration shall be controlled via the47:ref:`sub-device API <subdev>`.48 49.. note::50 51 A video-node-centric may still provide media-controller and52 sub-device interfaces as well.53 54 However, in that case the media-controller and the sub-device55 interfaces are read-only and just provide information about the56 device. The actual configuration is done via the video nodes.57 58.. _v4l2_device_naming:59 60V4L2 Device Node Naming61=======================62 63V4L2 drivers are implemented as kernel modules, loaded manually by the64system administrator or automatically when a device is first discovered.65The driver modules plug into the ``videodev`` kernel module. It provides66helper functions and a common application interface specified in this67document.68 69Each driver thus loaded registers one or more device nodes with major70number 81. Minor numbers are allocated dynamically unless the kernel71is compiled with the kernel option CONFIG_VIDEO_FIXED_MINOR_RANGES.72In that case minor numbers are allocated in ranges depending on the73device node type.74 75The device nodes supported by the Video4Linux subsystem are:76 77======================== ====================================================78Default device node name Usage79======================== ====================================================80``/dev/videoX`` Video and metadata for capture/output devices81``/dev/vbiX`` Vertical blank data (i.e. closed captions, teletext)82``/dev/radioX`` Radio tuners and modulators83``/dev/swradioX`` Software Defined Radio tuners and modulators84``/dev/v4l-touchX`` Touch sensors85``/dev/v4l-subdevX`` Video sub-devices (used by sensors and other86 components of the hardware peripheral)\ [#]_87======================== ====================================================88 89Where ``X`` is a non-negative integer.90 91.. note::92 93 1. The actual device node name is system-dependent, as udev rules may apply.94 2. There is no guarantee that ``X`` will remain the same for the same95 device, as the number depends on the device driver's probe order.96 If you need an unique name, udev default rules produce97 ``/dev/v4l/by-id/`` and ``/dev/v4l/by-path/`` directories containing98 links that can be used uniquely to identify a V4L2 device node::99 100 $ tree /dev/v4l101 /dev/v4l102 ├── by-id103 │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0104 └── by-path105 └── pci-0000:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0106 107.. [#] **V4L2 sub-device nodes** (e. g. ``/dev/v4l-subdevX``) use a different108 set of system calls, as covered at :ref:`subdev`.109 110Many drivers support "video_nr", "radio_nr" or "vbi_nr" module111options to select specific video/radio/vbi node numbers. This allows the112user to request that the device node is named e.g. /dev/video5 instead113of leaving it to chance. When the driver supports multiple devices of114the same type more than one device node number can be assigned,115separated by commas:116 117.. code-block:: none118 119 # modprobe mydriver video_nr=0,1 radio_nr=0,1120 121In ``/etc/modules.conf`` this may be written as:122 123::124 125 options mydriver video_nr=0,1 radio_nr=0,1126 127When no device node number is given as module option the driver supplies128a default.129 130Normally udev will create the device nodes in /dev automatically for131you. If udev is not installed, then you need to enable the132CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to133correctly relate a minor number to a device node number. I.e., you need134to be certain that minor number 5 maps to device node name video5. With135this kernel option different device types have different minor number136ranges. These ranges are listed in :ref:`devices`.137 138The creation of character special files (with mknod) is a privileged139operation and devices cannot be opened by major and minor number. That140means applications cannot *reliably* scan for loaded or installed141drivers. The user must enter a device name, or the application can try142the conventional device names.143 144.. _related:145 146Related Devices147===============148 149Devices can support several functions. For example video capturing, VBI150capturing and radio support.151 152The V4L2 API creates different V4L2 device nodes for each of these functions.153 154The V4L2 API was designed with the idea that one device node could155support all functions. However, in practice this never worked: this156'feature' was never used by applications and many drivers did not157support it and if they did it was certainly never tested. In addition,158switching a device node between different functions only works when159using the streaming I/O API, not with the160:c:func:`read()`/\ :c:func:`write()` API.161 162Today each V4L2 device node supports just one function.163 164Besides video input or output the hardware may also support audio165sampling or playback. If so, these functions are implemented as ALSA PCM166devices with optional ALSA audio mixer devices.167 168One problem with all these devices is that the V4L2 API makes no169provisions to find these related V4L2 device nodes. Some really complex170hardware use the Media Controller (see :ref:`media_controller`) which can171be used for this purpose. But several drivers do not use it, and while some172code exists that uses sysfs to discover related V4L2 device nodes (see173libmedia_dev in the174`v4l-utils <http://git.linuxtv.org/cgit.cgi/v4l-utils.git/>`__ git175repository), there is no library yet that can provide a single API176towards both Media Controller-based devices and devices that do not use177the Media Controller. If you want to work on this please write to the178linux-media mailing list:179`https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__.180 181Multiple Opens182==============183 184V4L2 devices can be opened more than once. [#f1]_ When this is supported185by the driver, users can for example start a "panel" application to186change controls like brightness or audio volume, while another187application captures video and audio. In other words, panel applications188are comparable to an ALSA audio mixer application. Just opening a V4L2189device should not change the state of the device. [#f2]_190 191Once an application has allocated the memory buffers needed for192streaming data (by calling the :ref:`VIDIOC_REQBUFS`193or :ref:`VIDIOC_CREATE_BUFS` ioctls, or194implicitly by calling the :c:func:`read()` or195:c:func:`write()` functions) that application (filehandle)196becomes the owner of the device. It is no longer allowed to make changes197that would affect the buffer sizes (e.g. by calling the198:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl) and other applications are199no longer allowed to allocate buffers or start or stop streaming. The200EBUSY error code will be returned instead.201 202Merely opening a V4L2 device does not grant exclusive access. [#f3]_203Initiating data exchange however assigns the right to read or write the204requested type of data, and to change related properties, to this file205descriptor. Applications can request additional access privileges using206the priority mechanism described in :ref:`app-pri`.207 208Shared Data Streams209===================210 211V4L2 drivers should not support multiple applications reading or writing212the same data stream on a device by copying buffers, time multiplexing213or similar means. This is better handled by a proxy application in user214space.215 216Functions217=========218 219To open and close V4L2 devices applications use the220:c:func:`open()` and :c:func:`close()` function,221respectively. Devices are programmed using the222:ref:`ioctl() <func-ioctl>` function as explained in the following223sections.224 225.. [#f1]226 There are still some old and obscure drivers that have not been227 updated to allow for multiple opens. This implies that for such228 drivers :c:func:`open()` can return an ``EBUSY`` error code229 when the device is already in use.230 231.. [#f2]232 Unfortunately, opening a radio device often switches the state of the233 device to radio mode in many drivers. This behavior should be fixed234 eventually as it violates the V4L2 specification.235 236.. [#f3]237 Drivers could recognize the ``O_EXCL`` open flag. Presently this is238 not required, so applications cannot know if it really works.239