Merge branch 'staging/for_v3.7' into v4l_for_linus

Applied on the top of changeset 782cd9e, as some of those patches
depend on some fixes that went via -arm tree.

* staging/for_v3.7: (109 commits)
  [media] m5mols: Add missing #include <linux/sizes.h>
  [media] stk1160: Add support for S-Video input
  Revert "[media] omap3isp: Replace cpu_is_omap3630() with ISP revision check"
  [media]  dvb: LNA implementation changes
  [media] v4l2-ioctl: fix W=1 warnings
  [media] v4l2-ioctl: add blocks check for VIDIOC_SUBDEV_G/S_EDID
  [media] omap3isp: Fix compilation error in ispreg.h
  [media] rc-msi-digivox-ii: Add full scan keycodes
  [media] cx25821: testing the wrong variable
  [media] tda18271-common: hold the I2C adapter during write transfers
  [media] ds3000: add module parameter to force firmware upload
  [media] drivers/media: Remove unnecessary semicolon
  [media] winbond: remove space from driver name
  [media] iguanair: cannot send data from the stack
  [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check
  [media] dvb-usb: print small buffers via %*ph
  [media] uvc: Add return code check at vb2_queue_init()
  [media] em28xx: Replace memcpy with struct assignment
  [media] bt8xx: Add video4linux control V4L2_CID_COLOR_KILLER
  [media] mem2mem_testdev: Use devm_kzalloc() in probe
  ...
This commit is contained in:
Mauro Carvalho Chehab 2012-10-11 15:07:19 -03:00
commit bf3b202b41
171 changed files with 8076 additions and 3212 deletions

View file

@ -2582,6 +2582,10 @@ ioctls.</para>
<listitem>
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
</listitem>
<listitem>
<para>Vendor and device specific media bus pixel formats.
<xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
</listitem>
</itemizedlist>
</section>

View file

@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is
the decoder is started.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE</constant>&nbsp;</entry>
@ -2269,6 +2268,14 @@ encoder or editing process may produce.".
Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-vbv-delay">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VBV_DELAY</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">Sets the initial delay in milliseconds for
VBV buffer control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder.</entry>
</row><row><entry spanname="descr">vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enable generation of frame packing supplemental enhancement information in the encoded bitstream.
The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Sets current frame as frame0 in frame packing SEI.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-h264-sei-fp-arrangement-type">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_video_h264_sei_fp_arrangement_type</entry>
</row>
<row><entry spanname="descr">Frame packing arrangement type for H264 SEI.
Applicable to the H264 encoder.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD</constant>&nbsp;</entry>
<entry>Pixels are alternatively from L and R.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN</constant>&nbsp;</entry>
<entry>L and R are interlaced by column.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW</constant>&nbsp;</entry>
<entry>L and R are interlaced by row.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE</constant>&nbsp;</entry>
<entry>L is on the left, R on the right.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM</constant>&nbsp;</entry>
<entry>L is on top, R on bottom.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL</constant>&nbsp;</entry>
<entry>One view per frame.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enables flexible macroblock ordering in the encoded bitstream. It is a technique
used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-h264-fmo-map-type">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_video_h264_fmo_map_type</entry>
</row>
<row><entry spanname="descr">When using FMO, the map type divides the image in different scan patterns of macroblocks.
Applicable to the H264 encoder.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES</constant>&nbsp;</entry>
<entry>Slices are interleaved one after other with macroblocks in run length order.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES</constant>&nbsp;</entry>
<entry>Scatters the macroblocks based on a mathematical function known to both encoder and decoder.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER</constant>&nbsp;</entry>
<entry>Macroblocks arranged in rectangular areas or regions of interest.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT</constant>&nbsp;</entry>
<entry>Slice groups grow in a cyclic way from centre to outwards.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN</constant>&nbsp;</entry>
<entry>Slice groups grow in raster scan pattern from left to right.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN</constant>&nbsp;</entry>
<entry>Slice groups grow in wipe scan pattern from top to bottom.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT</constant>&nbsp;</entry>
<entry>User defined map type.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Number of slice groups in FMO.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-h264-fmo-change-direction">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_video_h264_fmo_change_dir</entry>
</row>
<row><entry spanname="descr">Specifies a direction of the slice group change for raster and wipe maps.
Applicable to the H264 encoder.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT</constant>&nbsp;</entry>
<entry>Raster scan or wipe right.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT</constant>&nbsp;</entry>
<entry>Reverse raster scan or wipe left.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Specifies the size of the first slice group for raster and wipe map.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Specifies the number of consecutive macroblocks for the interleaved map.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enables arbitrary slice ordering in encoded bitstream.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">Specifies the slice order in ASO. Applicable to the H264 encoder.
The supplied 32-bit integer is interpreted as follows (bit
0 = least significant bit):</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry>Bit 0:15</entry>
<entry>Slice ID</entry>
</row>
<row>
<entry>Bit 16:32</entry>
<entry>Slice position or order</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enables H264 hierarchical coding.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-h264-hierarchical-coding-type">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_video_h264_hierarchical_coding_type</entry>
</row>
<row><entry spanname="descr">Specifies the hierarchical coding type.
Applicable to the H264 encoder.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B</constant>&nbsp;</entry>
<entry>Hierarchical B coding.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P</constant>&nbsp;</entry>
<entry>Hierarchical P coding.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Specifies the number of hierarchical coding layers.
Applicable to the H264 encoder.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">Specifies a user defined QP for each layer. Applicable to the H264 encoder.
The supplied 32-bit integer is interpreted as follows (bit
0 = least significant bit):</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry>Bit 0:15</entry>
<entry>QP value</entry>
</row>
<row>
<entry>Bit 16:32</entry>
<entry>Layer number</entry>
</row>
</tbody>
</entrytbl>
</row>
</tbody>
</tgroup>
</table>
@ -4267,6 +4533,16 @@ interface and may change in the future.</para>
pixels / second.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN</constant></entry>
<entry>menu</entry>
</row>
<row id="v4l2-test-pattern">
<entry spanname="descr"> Some capture/display/sensor devices have
the capability to generate test pattern images. These hardware
specific test patterns can be used to test if a device is working
properly.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

View file

@ -677,8 +677,10 @@ memory, set by the application. See <xref linkend="userp" /> for details.
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size of the buffer (not the payload) in bytes for the
single-planar API. For the multi-planar API should contain the
number of elements in the <structfield>planes</structfield> array.
single-planar API. For the multi-planar API the application sets
this to the number of elements in the <structfield>planes</structfield>
array. The driver will fill in the actual number of valid elements in
that array.
</entry>
</row>
<row>

View file

@ -1,11 +1,13 @@
<refentry id="V4L2-PIX-FMT-NV12M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV12M ('NM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
<constant>V4L2_PIX_FMT_NV12MT_16X16</constant> is the tiled version of
<constant>V4L2_PIX_FMT_NV12M</constant> with 16x16 macroblock tiles. Here pixels
are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory.
<constant>V4L2_PIX_FMT_NV21M</constant> is the same as <constant>V4L2_PIX_FMT_NV12M</constant>
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,

View file

@ -758,6 +758,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
<entry>'AVC1'</entry>
<entry>H264 video elementary stream without start codes.</entry>
</row>
<row id="V4L2-PIX-FMT-H264-MVC">
<entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
<entry>'MVC'</entry>
<entry>H264 MVC video elementary stream.</entry>
</row>
<row id="V4L2-PIX-FMT-H263">
<entry><constant>V4L2_PIX_FMT_H263</constant></entry>
<entry>'H263'</entry>
@ -793,6 +798,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
<entry>'VC1L'</entry>
<entry>VC1, SMPTE 421M Annex L compliant stream.</entry>
</row>
<row id="V4L2-PIX-FMT-VP8">
<entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
<entry>'VP8'</entry>
<entry>VP8 video elementary stream.</entry>
</row>
</tbody>
</tgroup>
</table>
@ -996,6 +1006,34 @@ the other bits are set to 0.</entry>
<entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
the other bits are set to 0.</entry>
</row>
<row id="V4L2-PIX-FMT-S5C-UYVY-JPG">
<entry><constant>V4L2_PIX_FMT_S5C_UYVY_JPG</constant></entry>
<entry>'S5CI'</entry>
<entry>Two-planar format used by Samsung S5C73MX cameras. The
first plane contains interleaved JPEG and UYVY image data, followed by meta data
in form of an array of offsets to the UYVY data blocks. The actual pointer array
follows immediately the interleaved JPEG/UYVY data, the number of entries in
this array equals the height of the UYVY image. Each entry is a 4-byte unsigned
integer in big endian order and it's an offset to a single pixel line of the
UYVY image. The first plane can start either with JPEG or UYVY data chunk. The
size of a single UYVY block equals the UYVY image's width multiplied by 2. The
size of a JPEG chunk depends on the image and can vary with each line.
<para>The second plane, at an offset of 4084 bytes, contains a 4-byte offset to
the pointer array in the first plane. This offset is followed by a 4-byte value
indicating size of the pointer array. All numbers in the second plane are also
in big endian order. Remaining data in the second plane is undefined. The
information in the second plane allows to easily find location of the pointer
array, which can be different for each frame. The size of the pointer array is
constant for given UYVY image height.</para>
<para>In order to extract UYVY and JPEG frames an application can initially set
a data pointer to the start of first plane and then add an offset from the first
entry of the pointers table. Such a pointer indicates start of an UYVY image
pixel line. Whole UYVY line can be copied to a separate buffer. These steps
should be repeated for each line, i.e. the number of entries in the pointer
array. Anything what's in between the UYVY lines is JPEG data and should be
concatenated to form the JPEG stream. </para>
</entry>
</row>
</tbody>
</tgroup>
</table>

View file

@ -2565,5 +2565,49 @@
</tgroup>
</table>
</section>
<section id="v4l2-mbus-vendor-spec-fmts">
<title>Vendor and Device Specific Formats</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This section lists complex data formats that are either vendor or
device specific.
</para>
<para>The following table lists the existing vendor and device specific
formats.</para>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-vendor-specific">
<title>Vendor and device specific formats</title>
<tgroup cols="3">
<colspec colname="id" align="left" />
<colspec colname="code" align="left"/>
<colspec colname="remarks" align="left"/>
<thead>
<row>
<entry>Identifier</entry>
<entry>Code</entry>
<entry>Comments</entry>
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8">
<entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry>
<entry>0x5001</entry>
<entry>
Interleaved raw UYVY and JPEG image format with embedded
meta-data used by Samsung S3C73MX camera sensors.
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>
</section>

View file

@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set
field. It indicates a non-critical (recoverable) streaming error. In such case
the application may continue as normal, but should be aware that data in the
dequeued buffer might be corrupted. When using the multi-planar API, the
planes array does not have to be passed; the <structfield>m.planes</structfield>
member must be set to NULL in that case.</para>
planes array must be passed in as well.</para>
<para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
buffer is in the outgoing queue. When the

View file

@ -48,8 +48,8 @@
<refsect1>
<title>Description</title>
<para>This ioctl is part of the <link linkend="mmap">memory
mapping</link> I/O method. It can be used to query the status of a
<para>This ioctl is part of the <link linkend="mmap">streaming
</link> I/O method. It can be used to query the status of a
buffer at any time after buffers have been allocated with the
&VIDIOC-REQBUFS; ioctl.</para>
@ -71,6 +71,7 @@ the structure.</para>
<para>In the <structfield>flags</structfield> field the
<constant>V4L2_BUF_FLAG_MAPPED</constant>,
<constant>V4L2_BUF_FLAG_PREPARED</constant>,
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
<structfield>memory</structfield> field will be set to the current
@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory,
the <structfield>length</structfield> field its size. For the multi-planar API,
fields <structfield>m.mem_offset</structfield> and
<structfield>length</structfield> in the <structfield>m.planes</structfield>
array elements will be used instead. The driver may or may not set the remaining
fields and flags, they are meaningless in this context.</para>
array elements will be used instead and the <structfield>length</structfield>
field of &v4l2-buffer; is set to the number of filled-in array elements.
The driver may or may not set the remaining fields and flags, they are
meaningless in this context.</para>
<para>The <structname>v4l2_buffer</structname> structure is
specified in <xref linkend="buffer" />.</para>

View file

@ -136,11 +136,25 @@ Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
Standard menu controls with a driver specific menu are added by calling
v4l2_ctrl_new_std_menu_items:
struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
s32 skip_mask, s32 def, const char * const *qmenu);
These functions are typically called right after the v4l2_ctrl_handler_init:
static const s64 exp_bias_qmenu[] = {
-2, -1, 0, 1, 2
};
static const char * const test_pattern[] = {
"Disabled",
"Vertical Bars",
"Solid Black",
"Solid White",
};
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
@ -156,6 +170,9 @@ These functions are typically called right after the v4l2_ctrl_handler_init:
ARRAY_SIZE(exp_bias_qmenu) - 1,
ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
exp_bias_qmenu);
v4l2_ctrl_new_std_menu_items(&foo->ctrl_handler, &foo_ctrl_ops,
V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0,
0, test_pattern);
...
if (foo->ctrl_handler.error) {
int err = foo->ctrl_handler.error;
@ -185,6 +202,13 @@ v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes
as the last argument an array of signed 64-bit integers that form an exact
menu item list.
The v4l2_ctrl_new_std_menu_items function is very similar to
v4l2_ctrl_new_std_menu but takes an extra parameter qmenu, which is the driver
specific menu for an otherwise standard menu control. A good example for this
control is the test pattern control for capture/display/sensors devices that
have the capability to generate test patterns. These test patterns are hardware
specific, so the contents of the menu will vary from device to device.
Note that if something fails, the function will return NULL or an error and
set ctrl_handler->error to the error code. If ctrl_handler->error was already
set, then it will just return and do nothing. This is also true for