mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 02:32:09 -04:00
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:
commit
bf3b202b41
171 changed files with 8076 additions and 3212 deletions
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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> </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> </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> </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> </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> </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> </entry>
|
||||
<entry>enum 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> </entry>
|
||||
<entry>Pixels are alternatively from L and R.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN</constant> </entry>
|
||||
<entry>L and R are interlaced by column.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW</constant> </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> </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> </entry>
|
||||
<entry>L is on top, R on bottom.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL</constant> </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> </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> </entry>
|
||||
<entry>enum 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> </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> </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> </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> </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> </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> </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> </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> </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> </entry>
|
||||
<entry>enum 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> </entry>
|
||||
<entry>Raster scan or wipe right.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT</constant> </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> </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> </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> </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> </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> </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> </entry>
|
||||
<entry>enum 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> </entry>
|
||||
<entry>Hierarchical B coding.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P</constant> </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> </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> </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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue