media/v4l/open.rst

12 Controlling a hardware peripheral via V4L2
15 Hardware that is supported using the V4L2 uAPI often consists of multiple
18 The bridge driver exposes one or more V4L2 device nodes
22 the hardware, which may also expose device nodes, called V4L2 sub-devices.
24 When such V4L2 sub-devices are exposed, they allow controlling those
29 :ref:`V4L2 sub-devices <subdev>`.
33 devices. The devices that are fully controlled via V4L2 device nodes
36 Userspace can check if a V4L2 hardware peripheral is MC-centric by
43 It is required for MC-centric drivers to identify the V4L2
60 V4L2 Device Node Naming
63 V4L2 drivers are implemented as kernel modules, loaded manually by the
98       links that can be used uniquely to identify a V4L2 device node::
107 .. [#] **V4L2 sub-device nodes** (e. g. ``/dev/v4l-subdevX``) use a different
152 The V4L2 API creates different V4L2 device nodes for each of these functions.
154 The V4L2 API was designed with the idea that one device node could
162 Today each V4L2 device node supports just one function.
168 One problem with all these devices is that the V4L2 API makes no
169 provisions to find these related V4L2 device nodes. Some really complex
172 code exists that uses sysfs to discover related V4L2 device nodes (see
184 V4L2 devices can be opened more than once. [#f1]_ When this is supported
188 are comparable to an ALSA audio mixer application. Just opening a V4L2
202 Merely opening a V4L2 device does not grant exclusive access. [#f3]_
211 V4L2 drivers should not support multiple applications reading or writing
219 To open and close V4L2 devices applications use the
234    eventually as it violates the V4L2 specification.