History

Merge tag 'media/v6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media updates from Mauro Carvalho Chehab: - Removal of some old unused sensor drivers: ad9389b, m5mols, mt9m032, mt9t001, noon010pc30, s5k6aa, sr030pc30 and vs6624 - New i.MX8 image sensor interface driver - Some new RC keymaps - lots of cleanups at atomisp driver to make it support standard features present on other webcam drivers - the cx18 and saa7146 now uses VB2 - lots of cleanups and driver improvements * tag 'media/v6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (460 commits) media: ov5670: Fix probe on ACPI media: nxp: imx8-isi: Remove 300ms sleep after enabling channel media: nxp: imx8-isi: Replace udelay() with fsleep() media: nxp: imx8-isi: Drop partial support for i.MX8QM and i.MX8QXP media: nxp: Add i.MX8 ISI driver media: dt-bindings: media: Add i.MX8 ISI DT bindings media: atomisp: gmin_platform: Add Lenovo Ideapad Miix 310 gmin_vars media: atomisp: gmin_platform: Make DMI quirks take precedence over the _DSM table media: atomisp: Remove struct atomisp_sub_device index field media: atomisp: Drop support for streaming from 2 sensors at once media: atomisp: Remove atomisp_try_fmt() call from atomisp_set_fmt() media: atomisp: Remove unused ATOM_ISP_MAX_WIDTH_TMP and ATOM_ISP_MAX_HEIGHT_TMP media: atomisp: Remove snr_mbus_fmt local var from atomisp_try_fmt() media: atomisp: Remove custom V4L2_CID_FMT_AUTO control media: atomisp: Remove continuous mode related code from atomisp_set_fmt() media: atomisp: Remove duplicate atomisp_[start|stop]_streaming() prototypes media: atomisp: gc0310: Switch over to ACPI powermanagement media: atomisp: gc0310: Use devm_kzalloc() for data struct media: atomisp: gc0310: Add runtime-pm support media: atomisp: gc0310: Delay power-on till streaming is started ...

Linus Torvalds committed 3 years ago

Commit 4ea95692 parents c8cc58e 73b41dc442 files · +15626 −21778Browse files

Showing the changes to Documentation/userspace-api (12 of 442 files). Show all

Unified · Split

12 files
  1. Documentation/userspace-api/media/v4l/dev-overlay.rst +8 −2
  2. Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +25 −0
  3. Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst +28 −0
  4. Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +42 −0
  5. Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +15 −0
  6. Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +94 −0
  7. Documentation/userspace-api/media/v4l/user-func.rst +1 −0
  8. Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +10 −0
  9. Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst +16 −36
  10. Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst +29 −15
  11. Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst +27 −12
  12. Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst +83 −0
Documentation/userspace-api/media/v4l/dev-overlay.rst+8−2
@@ -67,6 +67,7 @@ ioctls must be supported by all video overlay devices. · 66 unmodified lines
67Setup67Setup
68=====68=====
69 69
70*Note: support for this has been removed.*
70Before overlay can commence applications must program the driver with71Before overlay can commence applications must program the driver with
71frame buffer parameters, namely the address and size of the frame buffer72frame buffer parameters, namely the address and size of the frame buffer
72and the image format, for example RGB 5:6:5. The73and the image format, for example RGB 5:6:5. The
@@ -92,11 +93,13 @@ A driver may support any (or none) of five clipping/blending methods: · 19 unmodified lines
921. Chroma-keying displays the overlaid image only where pixels in the931. Chroma-keying displays the overlaid image only where pixels in the
93 primary graphics surface assume a certain color.94 primary graphics surface assume a certain color.
94 95
952. A bitmap can be specified where each bit corresponds to a pixel in962. *Note: support for this has been removed.*
97 A bitmap can be specified where each bit corresponds to a pixel in
96 the overlaid image. When the bit is set, the corresponding video98 the overlaid image. When the bit is set, the corresponding video
97 pixel is displayed, otherwise a pixel of the graphics surface.99 pixel is displayed, otherwise a pixel of the graphics surface.
98 100
993. A list of clipping rectangles can be specified. In these regions *no*1013. *Note: support for this has been removed.*
102 A list of clipping rectangles can be specified. In these regions *no*
100 video is displayed, so the graphics surface can be seen here.103 video is displayed, so the graphics surface can be seen here.
101 104
1024. The framebuffer has an alpha channel that can be used to clip or1054. The framebuffer has an alpha channel that can be used to clip or
@@ -185,6 +188,7 @@ struct v4l2_window · 82 unmodified lines
185 be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.188 be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.
186 189
187``struct v4l2_clip * clips``190``struct v4l2_clip * clips``
191 *Note: support for this has been removed.*
188 When chroma-keying has *not* been negotiated and192 When chroma-keying has *not* been negotiated and
189 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,193 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
190 applications can set this field to point to an array of clipping194 applications can set this field to point to an array of clipping
@@ -201,6 +205,7 @@ struct v4l2_window · 10 unmodified lines
201 are undefined.205 are undefined.
202 206
203``__u32 clipcount``207``__u32 clipcount``
208 *Note: support for this has been removed.*
204 When the application set the ``clips`` field, this field must209 When the application set the ``clips`` field, this field must
205 contain the number of clipping rectangles in the list. When clip210 contain the number of clipping rectangles in the list. When clip
206 lists are not supported the driver ignores this field, its contents211 lists are not supported the driver ignores this field, its contents
@@ -208,6 +213,7 @@ struct v4l2_window · 1 unmodified line
208 supported but no clipping is desired this field must be set to zero.213 supported but no clipping is desired this field must be set to zero.
209 214
210``void * bitmap``215``void * bitmap``
216 *Note: support for this has been removed.*
211 When chroma-keying has *not* been negotiated and217 When chroma-keying has *not* been negotiated and
212 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,218 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
213 applications can set this field to point to a clipping bit mask.219 applications can set this field to point to a clipping bit mask.
Documentation/userspace-api/media/v4l/pixfmt-compressed.rst+25−0
@@ -88,6 +88,11 @@ Compressed Formats · 87 unmodified lines
88 - ``V4L2_PIX_FMT_H263``88 - ``V4L2_PIX_FMT_H263``
89 - 'H263'89 - 'H263'
90 - H263 video elementary stream.90 - H263 video elementary stream.
91 * .. _V4L2-PIX-FMT-SPK:
92
93 - ``V4L2_PIX_FMT_SPK``
94 - 'SPK0'
95 - Sorenson Spark is an implementation of H.263 for use in Flash Video and Adobe Flash files
91 * .. _V4L2-PIX-FMT-MPEG1:96 * .. _V4L2-PIX-FMT-MPEG1:
92 97
93 - ``V4L2_PIX_FMT_MPEG1``98 - ``V4L2_PIX_FMT_MPEG1``
@@ -232,6 +237,26 @@ Compressed Formats · 138 unmodified lines
232 Metadata associated with the frame to decode is required to be passed237 Metadata associated with the frame to decode is required to be passed
233 through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control.238 through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control.
234 See the :ref:`associated Codec Control ID <codec-stateless-fwht>`.239 See the :ref:`associated Codec Control ID <codec-stateless-fwht>`.
240 * .. _V4L2-PIX-FMT-RV30:
241
242 - ``V4L2_PIX_FMT_RV30``
243 - 'RV30'
244 - RealVideo, or also spelled as Real Video, is a suite of
245 proprietary video compression formats developed by
246 RealNetworks - the specific format changes with the version.
247 RealVideo codecs are identified by four-character codes.
248 RV30 corresponds to RealVideo 8, suspected to be based
249 largely on an early draft of H.264
250 * .. _V4L2-PIX-FMT-RV40:
251
252 - ``V4L2_PIX_FMT_RV40``
253 - 'RV40'
254 - RV40 represents RealVideo 9 and RealVideo 10.
255 RealVideo 9, suspected to be based on H.264.
256 RealVideo 10, aka RV9 EHQ, This refers to an improved encoder
257 for the RV9 format that is fully backwards compatible with
258 RV9 players - the format and decoder did not change, only
259 the encoder did. As a result, it uses the same FourCC.
235 260
236.. raw:: latex261.. raw:: latex
237 262
Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst+28−0
@@ -257,6 +257,34 @@ the second byte and Y'\ :sub:`7-0` in the third byte. · 256 unmodified lines
257 - The padding bits contain undefined values that must be ignored by all257 - The padding bits contain undefined values that must be ignored by all
258 applications and drivers.258 applications and drivers.
259 259
260The next table lists the packed YUV 4:4:4 formats with 12 bits per component.
261Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits,
262arranged in little endian order, storing 1 pixel in 6 bytes.
263
264.. flat-table:: Packed YUV 4:4:4 Image Formats (12bpc)
265 :header-rows: 1
266 :stub-columns: 0
267
268 * - Identifier
269 - Code
270 - Byte 1-0
271 - Byte 3-2
272 - Byte 5-4
273 - Byte 7-6
274 - Byte 9-8
275 - Byte 11-10
276
277 * .. _V4L2-PIX-FMT-YUV48-12:
278
279 - ``V4L2_PIX_FMT_YUV48_12``
280 - 'Y312'
281
282 - Y'\ :sub:`0`
283 - Cb\ :sub:`0`
284 - Cr\ :sub:`0`
285 - Y'\ :sub:`1`
286 - Cb\ :sub:`1`
287 - Cr\ :sub:`1`
260 288
2614:2:2 Subsampling2894:2:2 Subsampling
262=================290=================
Documentation/userspace-api/media/v4l/pixfmt-rgb.rst+42−0
@@ -953,6 +953,48 @@ number of bits for each component. · 952 unmodified lines
953 953
954 \endgroup954 \endgroup
955 955
95612 Bits Per Component
957==============================
958
959These formats store an RGB triplet in six or eight bytes, with 12 bits per component.
960Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits,
961arranged in little endian order.
962
963.. raw:: latex
964
965 \small
966
967.. flat-table:: RGB Formats With 12 Bits Per Component
968 :header-rows: 1
969
970 * - Identifier
971 - Code
972 - Byte 1-0
973 - Byte 3-2
974 - Byte 5-4
975 - Byte 7-6
976 * .. _V4L2-PIX-FMT-BGR48-12:
977
978 - ``V4L2_PIX_FMT_BGR48_12``
979 - 'B312'
980
981 - B\ :sub:`15-4`
982 - G\ :sub:`15-4`
983 - R\ :sub:`15-4`
984 -
985 * .. _V4L2-PIX-FMT-ABGR64-12:
986
987 - ``V4L2_PIX_FMT_ABGR64_12``
988 - 'B412'
989
990 - B\ :sub:`15-4`
991 - G\ :sub:`15-4`
992 - R\ :sub:`15-4`
993 - A\ :sub:`15-4`
994
995.. raw:: latex
996
997 \normalsize
956 998
957Deprecated RGB Formats999Deprecated RGB Formats
958======================1000======================
Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst+15−0
@@ -103,6 +103,17 @@ are often referred to as greyscale formats. · 102 unmodified lines
103 - ...103 - ...
104 - ...104 - ...
105 105
106 * .. _V4L2-PIX-FMT-Y012:
107
108 - ``V4L2_PIX_FMT_Y012``
109 - 'Y012'
110
111 - Y'\ :sub:`0`\ [3:0] `0000`
112 - Y'\ :sub:`0`\ [11:4]
113 - ...
114 - ...
115 - ...
116
106 * .. _V4L2-PIX-FMT-Y14:117 * .. _V4L2-PIX-FMT-Y14:
107 118
108 - ``V4L2_PIX_FMT_Y14``119 - ``V4L2_PIX_FMT_Y14``
@@ -146,3 +157,7 @@ are often referred to as greyscale formats. · 37 unmodified lines
146 than 16 bits. For example, 10 bits per pixel uses values in the range 0 to157 than 16 bits. For example, 10 bits per pixel uses values in the range 0 to
147 1023. For the IPU3_Y10 format 25 pixels are packed into 32 bytes, which158 1023. For the IPU3_Y10 format 25 pixels are packed into 32 bytes, which
148 leaves the 6 most significant bits of the last byte padded with 0.159 leaves the 6 most significant bits of the last byte padded with 0.
160
161 For Y012 and Y12 formats, Y012 places its data in the 12 high bits, with
162 padding zeros in the 4 low bits, in contrast to the Y12 format, which has
163 its padding located in the most significant bits of the 16 bit word.
Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst+94−0
@@ -123,6 +123,20 @@ All components are stored with the same number of bits per component. · 122 unmodified lines
123 - Cb, Cr123 - Cb, Cr
124 - Yes124 - Yes
125 - 4x4 tiles125 - 4x4 tiles
126 * - V4L2_PIX_FMT_P012
127 - 'P012'
128 - 12
129 - 4:2:0
130 - Cb, Cr
131 - Yes
132 - Linear
133 * - V4L2_PIX_FMT_P012M
134 - 'PM12'
135 - 12
136 - 4:2:0
137 - Cb, Cr
138 - No
139 - Linear
126 * - V4L2_PIX_FMT_NV16140 * - V4L2_PIX_FMT_NV16
127 - 'NV16'141 - 'NV16'
128 - 8142 - 8
@@ -586,6 +600,86 @@ Data in the 10 high bits, zeros in the 6 low bits, arranged in little endian ord · 457 unmodified lines
586 - Cb\ :sub:`11`600 - Cb\ :sub:`11`
587 - Cr\ :sub:`11`601 - Cr\ :sub:`11`
588 602
603.. _V4L2-PIX-FMT-P012:
604.. _V4L2-PIX-FMT-P012M:
605
606P012 and P012M
607--------------
608
609P012 is like NV12 with 12 bits per component, expanded to 16 bits.
610Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order.
611
612.. flat-table:: Sample 4x4 P012 Image
613 :header-rows: 0
614 :stub-columns: 0
615
616 * - start + 0:
617 - Y'\ :sub:`00`
618 - Y'\ :sub:`01`
619 - Y'\ :sub:`02`
620 - Y'\ :sub:`03`
621 * - start + 8:
622 - Y'\ :sub:`10`
623 - Y'\ :sub:`11`
624 - Y'\ :sub:`12`
625 - Y'\ :sub:`13`
626 * - start + 16:
627 - Y'\ :sub:`20`
628 - Y'\ :sub:`21`
629 - Y'\ :sub:`22`
630 - Y'\ :sub:`23`
631 * - start + 24:
632 - Y'\ :sub:`30`
633 - Y'\ :sub:`31`
634 - Y'\ :sub:`32`
635 - Y'\ :sub:`33`
636 * - start + 32:
637 - Cb\ :sub:`00`
638 - Cr\ :sub:`00`
639 - Cb\ :sub:`01`
640 - Cr\ :sub:`01`
641 * - start + 40:
642 - Cb\ :sub:`10`
643 - Cr\ :sub:`10`
644 - Cb\ :sub:`11`
645 - Cr\ :sub:`11`
646
647.. flat-table:: Sample 4x4 P012M Image
648 :header-rows: 0
649 :stub-columns: 0
650
651 * - start0 + 0:
652 - Y'\ :sub:`00`
653 - Y'\ :sub:`01`
654 - Y'\ :sub:`02`
655 - Y'\ :sub:`03`
656 * - start0 + 8:
657 - Y'\ :sub:`10`
658 - Y'\ :sub:`11`
659 - Y'\ :sub:`12`
660 - Y'\ :sub:`13`
661 * - start0 + 16:
662 - Y'\ :sub:`20`
663 - Y'\ :sub:`21`
664 - Y'\ :sub:`22`
665 - Y'\ :sub:`23`
666 * - start0 + 24:
667 - Y'\ :sub:`30`
668 - Y'\ :sub:`31`
669 - Y'\ :sub:`32`
670 - Y'\ :sub:`33`
671 * -
672 * - start1 + 0:
673 - Cb\ :sub:`00`
674 - Cr\ :sub:`00`
675 - Cb\ :sub:`01`
676 - Cr\ :sub:`01`
677 * - start1 + 8:
678 - Cb\ :sub:`10`
679 - Cr\ :sub:`10`
680 - Cb\ :sub:`11`
681 - Cr\ :sub:`11`
682
589 683
590Fully Planar YUV Formats684Fully Planar YUV Formats
591========================685========================
Documentation/userspace-api/media/v4l/user-func.rst+1−0
@@ -72,6 +72,7 @@ Function Reference · 71 unmodified lines
72 vidioc-subdev-g-frame-interval72 vidioc-subdev-g-frame-interval
73 vidioc-subdev-g-routing73 vidioc-subdev-g-routing
74 vidioc-subdev-g-selection74 vidioc-subdev-g-selection
75 vidioc-subdev-g-client-cap
75 vidioc-subdev-querycap76 vidioc-subdev-querycap
76 vidioc-subscribe-event77 vidioc-subscribe-event
77 func-mmap78 func-mmap
Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst+10−0
@@ -185,6 +185,16 @@ still cause this situation. · 184 unmodified lines
185 - ``p_u32``185 - ``p_u32``
186 - A pointer to a matrix control of unsigned 32-bit values. Valid if186 - A pointer to a matrix control of unsigned 32-bit values. Valid if
187 this control is of type ``V4L2_CTRL_TYPE_U32``.187 this control is of type ``V4L2_CTRL_TYPE_U32``.
188 * - __u32 *
189 - ``p_s32``
190 - A pointer to a matrix control of signed 32-bit values. Valid if
191 this control is of type ``V4L2_CTRL_TYPE_INTEGER`` and
192 ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set.
193 * - __u32 *
194 - ``p_s64``
195 - A pointer to a matrix control of signed 64-bit values. Valid if
196 this control is of type ``V4L2_CTRL_TYPE_INTEGER64`` and
197 ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set.
188 * - struct :c:type:`v4l2_area` *198 * - struct :c:type:`v4l2_area` *
189 - ``p_area``199 - ``p_area``
190 - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is200 - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is
Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst+16−36
@@ -49,6 +49,9 @@ of a graphics card. A non-destructive overlay blends video images into a · 48 unmodified lines
49VGA signal or graphics into a video signal. *Video Output Overlays* are49VGA signal or graphics into a video signal. *Video Output Overlays* are
50always non-destructive.50always non-destructive.
51 51
52Destructive overlay support has been removed: with modern GPUs and CPUs
53this is no longer needed, and it was always a very dangerous feature.
54
52To get the current parameters applications call the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`55To get the current parameters applications call the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`
53ioctl with a pointer to a struct :c:type:`v4l2_framebuffer`56ioctl with a pointer to a struct :c:type:`v4l2_framebuffer`
54structure. The driver fills all fields of the structure or returns an57structure. The driver fills all fields of the structure or returns an
@@ -63,18 +66,12 @@ this structure, the driver prepares for the overlay and returns the · 8 unmodified lines
63framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error66framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error
64code.67code.
65 68
66To set the parameters for a *non-destructive Video Overlay*,69To set the parameters for a *Video Capture Overlay*
67applications must initialize the ``flags`` field, the ``fmt``70applications must initialize the ``flags`` field, the ``fmt``
68substructure, and call :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. Again the driver prepares for71substructure, and call :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. Again the driver prepares for
69the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`72the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`
70does, or it returns an error code.73does, or it returns an error code.
71 74
72For a *destructive Video Overlay* applications must additionally provide
73a ``base`` address. Setting up a DMA to a random memory location can
74jeopardize the system security, its stability or even damage the
75hardware, therefore only the superuser can set the parameters for a
76destructive video overlay.
77
78.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{6.6cm}|75.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{6.6cm}|
79 76
80.. c:type:: v4l2_framebuffer77.. c:type:: v4l2_framebuffer
@@ -100,17 +97,14 @@ destructive video overlay. · 19 unmodified lines
100 - ``base``97 - ``base``
101 -98 -
102 - Physical base address of the framebuffer, that is the address of99 - Physical base address of the framebuffer, that is the address of
103 the pixel in the top left corner of the framebuffer. [#f1]_100 the pixel in the top left corner of the framebuffer.
104 * -101 For :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` this field is no longer supported
105 -102 and the kernel will always set this to NULL.
106 -103 For *Video Output Overlays*
107 - This field is irrelevant to *non-destructive Video Overlays*. For104 the driver will return a valid base address, so applications can
108 *destructive Video Overlays* applications must provide a base
109 address. The driver may accept only base addresses which are a
110 multiple of two, four or eight bytes. For *Video Output Overlays*
111 the driver must return a valid base address, so applications can
112 find the corresponding Linux framebuffer device (see105 find the corresponding Linux framebuffer device (see
113 :ref:`osd`).106 :ref:`osd`). For *Video Capture Overlays* this field will always be
107 NULL.
114 * - struct108 * - struct
115 - ``fmt``109 - ``fmt``
116 -110 -
@@ -136,8 +130,7 @@ destructive video overlay. · 19 unmodified lines
136 * -130 * -
137 -131 -
138 -132 -
139 - For *destructive Video Overlays* applications must initialize this133 - For *Video Output Overlays* the driver must return a valid
140 field. For *Video Output Overlays* the driver must return a valid
141 format.134 format.
142 * -135 * -
143 -136 -
@@ -165,13 +158,6 @@ destructive video overlay. · 21 unmodified lines
165 158
166 This field is irrelevant to *non-destructive Video Overlays*.159 This field is irrelevant to *non-destructive Video Overlays*.
167 160
168 For *destructive Video Overlays* both applications and drivers can
169 set this field to request padding bytes at the end of each line.
170 Drivers however may ignore the requested value, returning
171 ``width`` times bytes-per-pixel or a larger value required by the
172 hardware. That implies applications can just set this field to
173 zero to get a reasonable default.
174
175 For *Video Output Overlays* the driver must return a valid value.161 For *Video Output Overlays* the driver must return a valid value.
176 162
177 Video hardware may access padding bytes, therefore they must163 Video hardware may access padding bytes, therefore they must
@@ -190,9 +176,8 @@ destructive video overlay. · 12 unmodified lines
190 * -176 * -
191 - __u32177 - __u32
192 - ``sizeimage``178 - ``sizeimage``
193 - This field is irrelevant to *non-destructive Video Overlays*. For179 - This field is irrelevant to *non-destructive Video Overlays*.
194 *destructive Video Overlays* applications must initialize this180 For *Video Output Overlays* the driver must return a valid
195 field. For *Video Output Overlays* the driver must return a valid
196 format.181 format.
197 182
198 Together with ``base`` it defines the framebuffer memory183 Together with ``base`` it defines the framebuffer memory
@@ -232,9 +217,11 @@ destructive video overlay. · 33 unmodified lines
232 * - ``V4L2_FBUF_CAP_LIST_CLIPPING``217 * - ``V4L2_FBUF_CAP_LIST_CLIPPING``
233 - 0x0004218 - 0x0004
234 - The device supports clipping using a list of clip rectangles.219 - The device supports clipping using a list of clip rectangles.
220 Note that this is no longer supported.
235 * - ``V4L2_FBUF_CAP_BITMAP_CLIPPING``221 * - ``V4L2_FBUF_CAP_BITMAP_CLIPPING``
236 - 0x0008222 - 0x0008
237 - The device supports clipping using a bit mask.223 - The device supports clipping using a bit mask.
224 Note that this is no longer supported.
238 * - ``V4L2_FBUF_CAP_LOCAL_ALPHA``225 * - ``V4L2_FBUF_CAP_LOCAL_ALPHA``
239 - 0x0010226 - 0x0010
240 - The device supports clipping/blending using the alpha channel of227 - The device supports clipping/blending using the alpha channel of
@@ -342,10 +329,3 @@ EPERM · 101 unmodified lines
342 329
343EINVAL330EINVAL
344 The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` parameters are unsuitable.331 The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` parameters are unsuitable.
345
346.. [#f1]
347 A physical base address may not suit all platforms. GK notes in
348 theory we should pass something like PCI device + memory region +
349 offset instead. If you encounter problems please discuss on the
350 linux-media mailing list:
351 `https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__.
Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst+29−15
@@ -31,18 +31,30 @@ Arguments · 30 unmodified lines
31Description31Description
32===========32===========
33 33
34This ioctl allows applications to enumerate all frame sizes supported by34This ioctl allows applications to access the enumeration of frame sizes
35a sub-device on the given pad for the given media bus format. Supported35supported by a sub-device on the specified pad
36formats can be retrieved with the36for the specified media bus format.
37Supported formats can be retrieved with the
37:ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE`38:ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE`
38ioctl.39ioctl.
39 40
40To enumerate frame sizes applications initialize the ``pad``, ``which``41The enumerations are defined by the driver, and indexed using the ``index`` field
41, ``code`` and ``index`` fields of the struct42of the struct :c:type:`v4l2_subdev_frame_size_enum`.
42:c:type:`v4l2_subdev_mbus_code_enum` and43Each pair of ``pad`` and ``code`` correspond to a separate enumeration.
43call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the44Each enumeration starts with the ``index`` of 0, and
44structure. Drivers fill the minimum and maximum frame sizes or return an45the lowest invalid index marks the end of the enumeration.
45EINVAL error code if one of the input parameters is invalid.46
47Therefore, to enumerate frame sizes allowed on the specified pad
48and using the specified mbus format, initialize the
49``pad``, ``which``, and ``code`` fields to desired values,
50and set ``index`` to 0.
51Then call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the
52structure.
53
54A successful call will return with minimum and maximum frame sizes filled in.
55Repeat with increasing ``index`` until ``EINVAL`` is received.
56``EINVAL`` means that either no more entries are available in the enumeration,
57or that an input parameter was invalid.
46 58
47Sub-devices that only support discrete frame sizes (such as most59Sub-devices that only support discrete frame sizes (such as most
48sensors) will return one or more frame sizes with identical minimum and60sensors) will return one or more frame sizes with identical minimum and
@@ -72,26 +84,28 @@ information about try formats. · 23 unmodified lines
72 84
73 * - __u3285 * - __u32
74 - ``index``86 - ``index``
75 - Number of the format in the enumeration, set by the application.87 - Index of the frame size in the enumeration belonging to the given pad
88 and format. Filled in by the application.
76 * - __u3289 * - __u32
77 - ``pad``90 - ``pad``
78 - Pad number as reported by the media controller API.91 - Pad number as reported by the media controller API.
92 Filled in by the application.
79 * - __u3293 * - __u32
80 - ``code``94 - ``code``
81 - The media bus format code, as defined in95 - The media bus format code, as defined in
82 :ref:`v4l2-mbus-format`.96 :ref:`v4l2-mbus-format`. Filled in by the application.
83 * - __u3297 * - __u32
84 - ``min_width``98 - ``min_width``
85 - Minimum frame width, in pixels.99 - Minimum frame width, in pixels. Filled in by the driver.
86 * - __u32100 * - __u32
87 - ``max_width``101 - ``max_width``
88 - Maximum frame width, in pixels.102 - Maximum frame width, in pixels. Filled in by the driver.
89 * - __u32103 * - __u32
90 - ``min_height``104 - ``min_height``
91 - Minimum frame height, in pixels.105 - Minimum frame height, in pixels. Filled in by the driver.
92 * - __u32106 * - __u32
93 - ``max_height``107 - ``max_height``
94 - Maximum frame height, in pixels.108 - Maximum frame height, in pixels. Filled in by the driver.
95 * - __u32109 * - __u32
96 - ``which``110 - ``which``
97 - Frame sizes to be enumerated, from enum111 - Frame sizes to be enumerated, from enum
Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst+27−12
@@ -31,15 +31,28 @@ Arguments · 30 unmodified lines
31Description31Description
32===========32===========
33 33
34To enumerate media bus formats available at a given sub-device pad34This call is used by the application to access the enumeration
35applications initialize the ``pad``, ``which`` and ``index`` fields of35of media bus formats for the selected pad.
36struct36
37:c:type:`v4l2_subdev_mbus_code_enum` and37The enumerations are defined by the driver, and indexed using the ``index`` field
38call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl with a pointer to this38of struct :c:type:`v4l2_subdev_mbus_code_enum`.
39structure. Drivers fill the rest of the structure or return an ``EINVAL``39Each enumeration starts with the ``index`` of 0, and
40error code if either the ``pad`` or ``index`` are invalid. All media bus40the lowest invalid index marks the end of enumeration.
41formats are enumerable by beginning at index zero and incrementing by41
42one until ``EINVAL`` is returned.42Therefore, to enumerate media bus formats available at a given sub-device pad,
43initialize the ``pad``, and ``which`` fields to desired values,
44and set ``index`` to 0.
45Then call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl
46with a pointer to this structure.
47
48A successful call will return with the ``code`` field filled in
49with a mbus code value.
50Repeat with increasing ``index`` until ``EINVAL`` is received.
51``EINVAL`` means that either ``pad`` is invalid,
52or that there are no more codes available at this pad.
53
54The driver must not return the same value of ``code`` for different indices
55at the same pad.
43 56
44Available media bus formats may depend on the current 'try' formats at57Available media bus formats may depend on the current 'try' formats at
45other pads of the sub-device, as well as on the current active links.58other pads of the sub-device, as well as on the current active links.
@@ -57,14 +70,16 @@ information about the try formats. · 11 unmodified lines
57 70
58 * - __u3271 * - __u32
59 - ``pad``72 - ``pad``
60 - Pad number as reported by the media controller API.73 - Pad number as reported by the media controller API. Filled in by the
74 application.
61 * - __u3275 * - __u32
62 - ``index``76 - ``index``
63 - Number of the format in the enumeration, set by the application.77 - Index of the mbus code in the enumeration belonging to the given pad.
78 Filled in by the application.
64 * - __u3279 * - __u32
65 - ``code``80 - ``code``
66 - The media bus format code, as defined in81 - The media bus format code, as defined in
67 :ref:`v4l2-mbus-format`.82 :ref:`v4l2-mbus-format`. Filled in by the driver.
68 * - __u3283 * - __u32
69 - ``which``84 - ``which``
70 - Media bus format codes to be enumerated, from enum85 - Media bus format codes to be enumerated, from enum
Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst+83−0
@@ -0,0 +1,83 @@
1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
2.. c:namespace:: V4L
3
4.. _VIDIOC_SUBDEV_G_CLIENT_CAP:
5
6************************************************************
7ioctl VIDIOC_SUBDEV_G_CLIENT_CAP, VIDIOC_SUBDEV_S_CLIENT_CAP
8************************************************************
9
10Name
11====
12
13VIDIOC_SUBDEV_G_CLIENT_CAP - VIDIOC_SUBDEV_S_CLIENT_CAP - Get or set client
14capabilities.
15
16Synopsis
17========
18
19.. c:macro:: VIDIOC_SUBDEV_G_CLIENT_CAP
20
21``int ioctl(int fd, VIDIOC_SUBDEV_G_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)``
22
23.. c:macro:: VIDIOC_SUBDEV_S_CLIENT_CAP
24
25``int ioctl(int fd, VIDIOC_SUBDEV_S_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)``
26
27Arguments
28=========
29
30``fd``
31 File descriptor returned by :ref:`open() <func-open>`.
32
33``argp``
34 Pointer to struct :c:type:`v4l2_subdev_client_capability`.
35
36Description
37===========
38
39These ioctls are used to get and set the client (the application using the
40subdevice ioctls) capabilities. The client capabilities are stored in the file
41handle of the opened subdev device node, and the client must set the
42capabilities for each opened subdev separately.
43
44By default no client capabilities are set when a subdev device node is opened.
45
46The purpose of the client capabilities are to inform the kernel of the behavior
47of the client, mainly related to maintaining compatibility with different
48kernel and userspace versions.
49
50The ``VIDIOC_SUBDEV_G_CLIENT_CAP`` ioctl returns the current client capabilities
51associated with the file handle ``fd``.
52
53The ``VIDIOC_SUBDEV_S_CLIENT_CAP`` ioctl sets client capabilities for the file
54handle ``fd``. The new capabilities fully replace the current capabilities, the
55ioctl can therefore also be used to remove capabilities that have previously
56been set.
57
58``VIDIOC_SUBDEV_S_CLIENT_CAP`` modifies the struct
59:c:type:`v4l2_subdev_client_capability` to reflect the capabilities that have
60been accepted. A common case for the kernel not accepting a capability is that
61the kernel is older than the headers the userspace uses, and thus the capability
62is unknown to the kernel.
63
64.. flat-table:: Client Capabilities
65 :header-rows: 1
66
67 * - Capability
68 - Description
69 * - ``V4L2_SUBDEV_CLIENT_CAP_STREAMS``
70 - The client is aware of streams. Setting this flag enables the use
71 of 'stream' fields (referring to the stream number) with various
72 ioctls. If this is not set (which is the default), the 'stream' fields
73 will be forced to 0 by the kernel.
74
75Return Value
76============
77
78On success 0 is returned, on error -1 and the ``errno`` variable is set
79appropriately. The generic error codes are described at the
80:ref:`Generic Error Codes <gen-errors>` chapter.
81
82ENOIOCTLCMD
83 The kernel does not support this ioctl.