Lines Matching +full:sub +full:- +full:device
1 .. -*- coding: utf-8; mode: rst -*-
6 Sub-device Interface
13 components as software blocks called sub-devices.
15 V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
16 implements the media device API, they will automatically inherit from
17 media entities. Applications will be able to enumerate the sub-devices
21 In addition to make sub-devices discoverable, drivers can also choose to
23 sub-device driver and the V4L2 device driver support this, sub-devices
24 will feature a character device node on which ioctls can be called to
26 - query, read and write sub-devices controls
28 - subscribe and unsubscribe to events and retrieve them
30 - negotiate image formats on individual pads
32 Sub-device character device nodes, conventionally named
33 ``/dev/v4l-subdev*``, use major number 81.
39 Most V4L2 controls are implemented by sub-device hardware. Drivers
40 usually merge all controls and expose them through video device nodes.
41 Applications can control all sub-devices through a single interface.
48 single device, all but one of the identical controls are hidden.
50 Applications can access those hidden controls through the sub-device
52 behave identically as when issued on V4L2 device nodes, with the
54 sub-device.
57 one (or several) V4L2 device nodes.
63 V4L2 sub-devices can notify applications of events as described in
64 :ref:`event`. The API behaves identically as when used on V4L2 device
66 the sub-device. Depending on the driver, those events might also be
67 reported on one (or several) V4L2 device nodes.
70 .. _pad-level-formats:
72 Pad-level Formats
77 Pad-level formats are only applicable to very complex devices that
78 need to expose low-level format configuration to user space. Generic
96 :ref:`pipeline-scaling`, where image scaling can be performed on both
100 .. _pipeline-scaling:
102 .. kernel-figure:: pipeline.dot
118 Drivers that implement the :ref:`media API <media-controller-intro>`
119 can expose pad-level image format configuration to applications. When
123 negotiate formats on a per-pad basis.
131 Pad-level image format configuration support can be tested by calling
133 0. If the driver returns an ``EINVAL`` error code pad-level format
134 configuration is not supported by the sub-device.
138 ------------------
152 configuration. Modifying those 'try' formats leaves the device state
154 and the hardware state stored in the device itself).
156 While not kept as part of the device state, try formats are stored in
157 the sub-device file handles. A
159 the last try format set *on the same sub-device file handle*. Several
160 applications querying the same sub-device at the same time will thus not
163 To find out whether a particular format is supported by the device,
166 verify and, if needed, change the requested ``format`` based on device
172 guaranteed to be supported by the device. In particular, drivers
174 to an :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` call as-is
178 Drivers automatically propagate formats inside sub-devices. When a try
180 the same sub-device can be modified by the driver. Drivers are free to
181 modify formats as required by the device. However, they should comply
184 - Formats should be propagated from sink pads to source pads. Modifying
188 - Sub-devices that scale frames using variable scaling factors should
194 propagating them from one sub-device file handle to another.
198 different formats matching device requirements as being compatible.
200 :ref:`sample-pipeline-config` shows a sample configuration sequence
201 for the pipeline described in :ref:`pipeline-scaling` (table columns
211 .. _sample-pipeline-config:
213 .. flat-table:: Sample Pipeline Configuration
214 :header-rows: 1
215 :stub-columns: 0
218 * -
219 - Sensor/0 format
220 - Frontend/0 format
221 - Frontend/1 format
222 - Scaler/0 format
223 - Scaler/0 compose selection rectangle
224 - Scaler/1 format
225 * - Initial state
226 - 2048x1536/SGRBG8_1X8
227 - (default)
228 - (default)
229 - (default)
230 - (default)
231 - (default)
232 * - Configure frontend sink format
233 - 2048x1536/SGRBG8_1X8
234 - *2048x1536/SGRBG8_1X8*
235 - *2046x1534/SGRBG8_1X8*
236 - (default)
237 - (default)
238 - (default)
239 * - Configure scaler sink format
240 - 2048x1536/SGRBG8_1X8
241 - 2048x1536/SGRBG8_1X8
242 - 2046x1534/SGRBG8_1X8
243 - *2046x1534/SGRBG8_1X8*
244 - *0,0/2046x1534*
245 - *2046x1534/SGRBG8_1X8*
246 * - Configure scaler sink compose selection
247 - 2048x1536/SGRBG8_1X8
248 - 2048x1536/SGRBG8_1X8
249 - 2046x1534/SGRBG8_1X8
250 - 2046x1534/SGRBG8_1X8
251 - *0,0/1280x960*
252 - *1280x960/SGRBG8_1X8*
285 be applied as-is by the driver without being modified.
288 .. _v4l2-subdev-selections:
291 ---------------------------------------------
293 Many sub-devices support cropping frames on their input or output pads
305 selection targets :ref:`v4l2-selections-common`.
308 The pad format represents the image size as received by the sub-device
310 represents the sub-image that will be transmitted further inside the
311 sub-device for processing.
335 the image size either up or down. :ref:`v4l2-selection-flags`
339 --------------------------
356 pixel array is not rectangular but cross-shaped or round. The maximum
361 ---------------------------------------------
374 rectangle, which refers to the sink compose bounds rectangle --- if it
405 .. _subdev-image-processing-crop:
407 .. kernel-figure:: subdev-image-processing-crop.svg
408 :alt: subdev-image-processing-crop.svg
415 pad. Now the actual crop rectangle can be set on the sink pad --- the
422 .. _subdev-image-processing-scaling-multi-source:
424 .. kernel-figure:: subdev-image-processing-scaling-multi-source.svg
425 :alt: subdev-image-processing-scaling-multi-source.svg
438 .. _subdev-image-processing-full:
440 .. kernel-figure:: subdev-image-processing-full.svg
441 :alt: subdev-image-processing-full.svg
456 subdev-formats