A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-30 11:41:38 -04:00
Code Issues Projects Releases Packages Wiki Activity

Linus 5.3-rc1

Browse source 
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl0006weHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGaDUIAJ4oTyVWpMRZkfG6
 vVY8qVMU3zlzEqRiyLYjkXoe/mGpuU/UVTyyStllxZ+Gg9da0mGwlugScKriPJof
 4KRUDDTGX5DrfEOo+0brKvM+PYh9uGViPgKXzyv7i6BrnX2z3JdBR4bKNuEYlAJ9
 N93Qg7v05SBHIq2Gfp3klrdWbsTTW2EaDTLbcgifXLnfKyFr47kwsmXAHPlTFP0p
 dYsZHHmf14Y9n1+ToZeVINgjQFr6mFn6ygY/PqTnd6vCgEEfP9eENJ4BZCtN1ZL/
 V0BO9MyJ5iZV0AfwSEKydk+kDEvO16TG/nyDrECVuur7AXsBx18ZplVc787f6GK+
 dyCQJ3U=
 =XLAF
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXTYRHQAKCRDj7w1vZxhR
 xY5IAQC0H/r62rlFq+JpbmksutMqvIferowP7HUk6yOaAKdVawD/c1qsTk/xxI0x
 StrxRCDqeGA7D2R/ZNb/4sobnn7+oAM=
 =k9CF
 -----END PGP SIGNATURE-----

Merge v5.3-rc1 into drm-misc-next

Noralf needs some SPI patches in 5.3 to merge some work on tinydrm.

Signed-off-by: Maxime Ripard <[email protected]>
This commit is contained in:
Maxime Ripard 2019-07-22 21:24:10 +02:00
commit 03b0f2ce73
16695 changed files with 979813 additions and 436034 deletions
Download patch file Download diff file Expand all files Collapse all files

6
Documentation/media/kapi/dtv-core.rst
View file

@ -11,12 +11,12 @@ Digital TV devices are implemented by several different drivers:
- Frontend drivers that are usually implemented as two separate drivers:
- A tuner driver that implements the logic with commands the part of the
hardware with is responsible to tune into a digital TV transponder or
- A tuner driver that implements the logic which commands the part of
the hardware responsible for tuning into a digital TV transponder or
physical channel. The output of a tuner is usually a baseband or
Intermediate Frequency (IF) signal;
- A demodulator driver (a.k.a "demod") that implements the logic with
- A demodulator driver (a.k.a "demod") that implements the logic which
commands the digital TV decoding hardware. The output of a demod is
a digital stream, with multiple audio, video and data channels typically
multiplexed using MPEG Transport Stream [#f1]_.

208
Documentation/media/kapi/v4l2-controls.rst
View file

@ -26,8 +26,9 @@ The control framework was created in order to implement all the rules of the
V4L2 specification with respect to controls in a central place. And to make
life as easy as possible for the driver developer.
Note that the control framework relies on the presence of a struct v4l2_device
for V4L2 drivers and struct v4l2_subdev for sub-device drivers.
Note that the control framework relies on the presence of a struct
:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for
sub-device drivers.
Objects in the framework
@ -35,12 +36,13 @@ Objects in the framework
There are two main objects:
The v4l2_ctrl object describes the control properties and keeps track of the
control's value (both the current value and the proposed new value).
The :c:type:`v4l2_ctrl` object describes the control properties and keeps
track of the control's value (both the current value and the proposed new
value).
v4l2_ctrl_handler is the object that keeps track of controls. It maintains a
list of v4l2_ctrl objects that it owns and another list of references to
controls, possibly to controls owned by other handlers.
:c:type:`v4l2_ctrl_handler` is the object that keeps track of controls. It
maintains a list of v4l2_ctrl objects that it owns and another list of
references to controls, possibly to controls owned by other handlers.
Basic usage for V4L2 and sub-device drivers
@ -48,33 +50,15 @@ Basic usage for V4L2 and sub-device drivers
1) Prepare the driver:
.. code-block:: c
#include <media/v4l2-ctrls.h>
1.1) Add the handler to your driver's top-level struct:
.. code-block:: none
For V4L2 drivers:
struct foo_dev {
...
struct v4l2_ctrl_handler ctrl_handler;
...
};
struct foo_dev *foo;
1.2) Initialize the handler:
.. code-block:: none
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
The second argument is a hint telling the function how many controls this
handler is expected to handle. It will allocate a hashtable based on this
information. It is a hint only.
1.3) Hook the control handler into the driver:
1.3.1) For V4L2 drivers do this:
.. code-block:: none
.. code-block:: c
struct foo_dev {
...
@ -84,18 +68,9 @@ information. It is a hint only.
...
};
foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler;
For sub-device drivers:
Where foo->v4l2_dev is of type struct v4l2_device.
Finally, remove all control functions from your v4l2_ioctl_ops (if any):
vidioc_queryctrl, vidioc_query_ext_ctrl, vidioc_querymenu, vidioc_g_ctrl,
vidioc_s_ctrl, vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls.
Those are now no longer needed.
1.3.2) For sub-device drivers do this:
.. code-block:: none
.. code-block:: c
struct foo_dev {
...
@ -105,39 +80,60 @@ Those are now no longer needed.
...
};
foo->sd.ctrl_handler = &foo->ctrl_handler;
1.2) Initialize the handler:
Where foo->sd is of type struct v4l2_subdev.
.. code-block:: c
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
The second argument is a hint telling the function how many controls this
handler is expected to handle. It will allocate a hashtable based on this
information. It is a hint only.
1.3) Hook the control handler into the driver:
For V4L2 drivers:
.. code-block:: c
foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler;
For sub-device drivers:
.. code-block:: c
foo->sd.ctrl_handler = &foo->ctrl_handler;
1.4) Clean up the handler at the end:
.. code-block:: none
.. code-block:: c
v4l2_ctrl_handler_free(&foo->ctrl_handler);
2) Add controls:
You add non-menu controls by calling v4l2_ctrl_new_std:
You add non-menu controls by calling :c:func:`v4l2_ctrl_new_std`:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl *v4l2_ctrl_new_std(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 min, s32 max, u32 step, s32 def);
Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu:
Menu and integer menu controls are added by calling
:c:func:`v4l2_ctrl_new_std_menu`:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 skip_mask, s32 def);
Menu controls with a driver specific menu are added by calling
v4l2_ctrl_new_std_menu_items:
:c:func:`v4l2_ctrl_new_std_menu_items`:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
struct v4l2_ctrl_handler *hdl,
@ -145,17 +141,18 @@ v4l2_ctrl_new_std_menu_items:
s32 skip_mask, s32 def, const char * const *qmenu);
Integer menu controls with a driver specific menu can be added by calling
v4l2_ctrl_new_int_menu:
:c:func:`v4l2_ctrl_new_int_menu`:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
These functions are typically called right after the v4l2_ctrl_handler_init:
These functions are typically called right after the
:c:func:`v4l2_ctrl_handler_init`:
.. code-block:: none
.. code-block:: c
static const s64 exp_bias_qmenu[] = {
-2, -1, 0, 1, 2
@ -192,33 +189,34 @@ These functions are typically called right after the v4l2_ctrl_handler_init:
return err;
}
The v4l2_ctrl_new_std function returns the v4l2_ctrl pointer to the new
control, but if you do not need to access the pointer outside the control ops,
then there is no need to store it.
The :c:func:`v4l2_ctrl_new_std` function returns the v4l2_ctrl pointer to
the new control, but if you do not need to access the pointer outside the
control ops, then there is no need to store it.
The v4l2_ctrl_new_std function will fill in most fields based on the control
ID except for the min, max, step and default values. These are passed in the
last four arguments. These values are driver specific while control attributes
like type, name, flags are all global. The control's current value will be set
to the default value.
The :c:func:`v4l2_ctrl_new_std` function will fill in most fields based on
the control ID except for the min, max, step and default values. These are
passed in the last four arguments. These values are driver specific while
control attributes like type, name, flags are all global. The control's
current value will be set to the default value.
The v4l2_ctrl_new_std_menu function is very similar but it is used for menu
controls. There is no min argument since that is always 0 for menu controls,
and instead of a step there is a skip_mask argument: if bit X is 1, then menu
item X is skipped.
The :c:func:`v4l2_ctrl_new_std_menu` function is very similar but it is
used for menu controls. There is no min argument since that is always 0 for
menu controls, and instead of a step there is a skip_mask argument: if bit
X is 1, then menu item X is skipped.
The v4l2_ctrl_new_int_menu function creates a new standard integer menu
control with driver-specific items in the menu. It differs from
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 :c:func:`v4l2_ctrl_new_int_menu` function creates a new standard
integer menu control with driver-specific items in the menu. It differs
from 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.
The :c:func:`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
@ -233,7 +231,7 @@ a bit faster that way.
3) Optionally force initial control setup:
.. code-block:: none
.. code-block:: c
v4l2_ctrl_handler_setup(&foo->ctrl_handler);
@ -242,9 +240,9 @@ initializes the hardware to the default control values. It is recommended
that you do this as this ensures that both the internal data structures and
the hardware are in sync.
4) Finally: implement the v4l2_ctrl_ops
4) Finally: implement the :c:type:`v4l2_ctrl_ops`
.. code-block:: none
.. code-block:: c
static const struct v4l2_ctrl_ops foo_ctrl_ops = {
.s_ctrl = foo_s_ctrl,
@ -252,7 +250,7 @@ the hardware are in sync.
Usually all you need is s_ctrl:
.. code-block:: none
.. code-block:: c
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
@ -305,7 +303,7 @@ Accessing Control Values
The following union is used inside the control framework to access control
values:
.. code-block:: none
.. code-block:: c
union v4l2_ctrl_ptr {
s32 *p_s32;
@ -317,7 +315,7 @@ values:
The v4l2_ctrl struct contains these fields that can be used to access both
current and new values:
.. code-block:: none
.. code-block:: c
s32 val;
struct {
@ -330,7 +328,7 @@ current and new values:
If the control has a simple s32 type type, then:
.. code-block:: none
.. code-block:: c
&ctrl->val == ctrl->p_new.p_s32
&ctrl->cur.val == ctrl->p_cur.p_s32
@ -354,7 +352,7 @@ exception is for controls that return a volatile register such as a signal
strength read-out that changes continuously. In that case you will need to
implement g_volatile_ctrl like this:
.. code-block:: none
.. code-block:: c
static int foo_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
@ -372,7 +370,7 @@ changes.
To mark a control as volatile you have to set V4L2_CTRL_FLAG_VOLATILE:
.. code-block:: none
.. code-block:: c
ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...);
if (ctrl)
@ -393,7 +391,7 @@ not to introduce deadlocks.
Outside of the control ops you have to go through to helper functions to get
or set a single control value safely in your driver:
.. code-block:: none
.. code-block:: c
s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
@ -404,7 +402,7 @@ will result in a deadlock since these helpers lock the handler as well.
You can also take the handler lock yourself:
.. code-block:: none
.. code-block:: c
mutex_lock(&state->ctrl_handler.lock);
pr_info("String value is '%s'\n", ctrl1->p_cur.p_char);
@ -417,7 +415,7 @@ Menu Controls
The v4l2_ctrl struct contains this union:
.. code-block:: none
.. code-block:: c
union {
u32 step;
@ -445,7 +443,7 @@ Custom Controls
Driver specific controls can be created using v4l2_ctrl_new_custom():
.. code-block:: none
.. code-block:: c
static const struct v4l2_ctrl_config ctrl_filter = {
.ops = &ctrl_custom_ops,
@ -499,7 +497,7 @@ By default all controls are independent from the others. But in more
complex scenarios you can get dependencies from one control to another.
In that case you need to 'cluster' them:
.. code-block:: none
.. code-block:: c
struct foo {
struct v4l2_ctrl_handler ctrl_handler;
@ -523,7 +521,7 @@ composite control. Similar to how a 'struct' works in C.
So when s_ctrl is called with V4L2_CID_AUDIO_VOLUME as argument, you should set
all two controls belonging to the audio_cluster:
.. code-block:: none
.. code-block:: c
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
@ -545,7 +543,7 @@ all two controls belonging to the audio_cluster:
In the example above the following are equivalent for the VOLUME case:
.. code-block:: none
.. code-block:: c
ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == state->audio_cluster[AUDIO_CL_VOLUME]
ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE]
@ -553,7 +551,7 @@ In the example above the following are equivalent for the VOLUME case:
In practice using cluster arrays like this becomes very tiresome. So instead
the following equivalent method is used:
.. code-block:: none
.. code-block:: c
struct {
/* audio cluster */
@ -565,7 +563,7 @@ The anonymous struct is used to clearly 'cluster' these two control pointers,
but it serves no other purpose. The effect is the same as creating an
array with two control pointers. So you can just do:
.. code-block:: none
.. code-block:: c
state->volume = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
state->mute = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
@ -621,7 +619,7 @@ changing that control affects the control flags of the manual controls.
In order to simplify this a special variation of v4l2_ctrl_cluster was
introduced:
.. code-block:: none
.. code-block:: c
void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
u8 manual_val, bool set_volatile);
@ -676,7 +674,7 @@ of another handler (e.g. for a video device node), then you should first add
the controls to the first handler, add the other controls to the second
handler and finally add the first handler to the second. For example:
.. code-block:: none
.. code-block:: c
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
@ -690,7 +688,7 @@ all controls.
Or you can add specific controls to a handler:
.. code-block:: none
.. code-block:: c
volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...);
@ -699,7 +697,7 @@ Or you can add specific controls to a handler:
What you should not do is make two identical controls for two handlers.
For example:
.. code-block:: none
.. code-block:: c
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_AUDIO_MUTE, ...);
@ -720,7 +718,7 @@ not own. For example, if you have to find a volume control from a subdev.
You can do that by calling v4l2_ctrl_find:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl *volume;
@ -729,7 +727,7 @@ You can do that by calling v4l2_ctrl_find:
Since v4l2_ctrl_find will lock the handler you have to be careful where you
use it. For example, this is not a good idea:
.. code-block:: none
.. code-block:: c
struct v4l2_ctrl_handler ctrl_handler;
@ -738,7 +736,7 @@ use it. For example, this is not a good idea:
...and in video_ops.s_ctrl:
.. code-block:: none
.. code-block:: c
case V4L2_CID_BRIGHTNESS:
contrast = v4l2_find_ctrl(&ctrl_handler, V4L2_CID_CONTRAST);
@ -760,7 +758,7 @@ not when it is used in consumer-level hardware. In that case you want to keep
those low-level controls local to the subdev. You can do this by simply
setting the 'is_private' flag of the control to 1:
.. code-block:: none
.. code-block:: c
static const struct v4l2_ctrl_config ctrl_private = {
.ops = &ctrl_custom_ops,
@ -797,7 +795,7 @@ Sometimes the platform or bridge driver needs to be notified when a control
from a sub-device driver changes. You can set a notify callback by calling
this function:
.. code-block:: none
.. code-block:: c
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);

2
Documentation/media/uapi/cec/cec-api.rst
View file

@ -39,7 +39,7 @@ Revision and Copyright
**********************
Authors:
- Verkuil, Hans <h[email protected]>
- Verkuil, Hans <h[email protected]>
- Initial version.

3
Documentation/media/uapi/cec/cec-ioc-g-mode.rst
View file

@ -294,7 +294,8 @@ EINVAL
The requested mode is invalid.
EPERM
Monitor mode is requested without having root permissions
Monitor mode is requested, but the process does have the ``CAP_NET_ADMIN``
capability.
EBUSY
Someone else is already an exclusive follower or initiator.

15
Documentation/media/uapi/cec/cec-ioc-receive.rst
View file

@ -223,6 +223,18 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
result of the :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`, and once via
:ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`.
* .. _`CEC-MSG-FL-RAW`:
- ``CEC_MSG_FL_RAW``
- 2
- Normally CEC messages are validated before transmitting them. If this
flag is set when :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` is called,
then no validation takes place and the message is transmitted as-is.
This is useful when debugging CEC issues.
This flag is only allowed if the process has the ``CAP_SYS_RAWIO``
capability. If that is not set, then the ``EPERM`` error code is
returned.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
@ -358,7 +370,8 @@ ENOTTY
EPERM
The CEC adapter is not configured, i.e. :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`
has never been called.
has never been called, or ``CEC_MSG_FL_RAW`` was used from a process that
did not have the ``CAP_SYS_RAWIO`` capability.
ENONET
The CEC adapter is not configured, i.e. :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`

7
Documentation/media/uapi/mediactl/media-ioc-enum-links.rst
View file

@ -84,6 +84,11 @@ returned during the enumeration process.
- Pointer to a links array allocated by the application. Ignored if
NULL.
* - __u32
- ``reserved[4]``
- Reserved for future extensions. Drivers and applications must set
the array to zero.
.. c:type:: media_pad_desc
@ -135,7 +140,7 @@ returned during the enumeration process.
- Link flags, see :ref:`media-link-flag` for more details.
* - __u32
- ``reserved[4]``
- ``reserved[2]``
- Reserved for future extensions. Drivers and applications must set
the array to zero.

30
Documentation/media/uapi/rc/rc-tables.rst
View file

@ -54,7 +54,7 @@ the remote via /dev/input/event devices.
- .. row 3
- ``KEY_0``
- ``KEY_NUMERIC_0``
- Keyboard digit 0
@ -62,7 +62,7 @@ the remote via /dev/input/event devices.
- .. row 4
- ``KEY_1``
- ``KEY_NUMERIC_1``
- Keyboard digit 1
@ -70,7 +70,7 @@ the remote via /dev/input/event devices.
- .. row 5
- ``KEY_2``
- ``KEY_NUMERIC_2``
- Keyboard digit 2
@ -78,7 +78,7 @@ the remote via /dev/input/event devices.
- .. row 6
- ``KEY_3``
- ``KEY_NUMERIC_3``
- Keyboard digit 3
@ -86,7 +86,7 @@ the remote via /dev/input/event devices.
- .. row 7
- ``KEY_4``
- ``KEY_NUMERIC_4``
- Keyboard digit 4
@ -94,7 +94,7 @@ the remote via /dev/input/event devices.
- .. row 8
- ``KEY_5``
- ``KEY_NUMERIC_5``
- Keyboard digit 5
@ -102,7 +102,7 @@ the remote via /dev/input/event devices.
- .. row 9
- ``KEY_6``
- ``KEY_NUMERIC_6``
- Keyboard digit 6
@ -110,7 +110,7 @@ the remote via /dev/input/event devices.
- .. row 10
- ``KEY_7``
- ``KEY_NUMERIC_7``
- Keyboard digit 7
@ -118,7 +118,7 @@ the remote via /dev/input/event devices.
- .. row 11
- ``KEY_8``
- ``KEY_NUMERIC_8``
- Keyboard digit 8
@ -126,7 +126,7 @@ the remote via /dev/input/event devices.
- .. row 12
- ``KEY_9``
- ``KEY_NUMERIC_9``
- Keyboard digit 9
@ -196,7 +196,7 @@ the remote via /dev/input/event devices.
- ``KEY_PAUSE``
- Pause sroweam
- Pause stream
- PAUSE / FREEZE
@ -220,7 +220,7 @@ the remote via /dev/input/event devices.
- ``KEY_STOP``
- Stop sroweam
- Stop stream
- STOP
@ -228,7 +228,7 @@ the remote via /dev/input/event devices.
- ``KEY_RECORD``
- Start/stop recording sroweam
- Start/stop recording stream
- CAPTURE / REC / RECORD/PAUSE
@ -577,7 +577,7 @@ the remote via /dev/input/event devices.
- ``KEY_CLEAR``
- Stop sroweam and return to default input video/audio
- Stop stream and return to default input video/audio
- CLEAR / RESET / BOSS KEY
@ -593,7 +593,7 @@ the remote via /dev/input/event devices.
- ``KEY_FAVORITES``
- Open the favorites sroweam window
- Open the favorites stream window
- TV WALL / Favorites

9
Documentation/media/uapi/v4l/biblio.rst
View file

@ -122,6 +122,15 @@ ITU BT.1119
:author: International Telecommunication Union (http://www.itu.ch)
.. _h264:
ITU-T Rec. H.264 Specification (04/2017 Edition)
================================================
:title: ITU-T Recommendation H.264 "Advanced Video Coding for Generic Audiovisual Services"
:author: International Telecommunication Union (http://www.itu.ch)
.. _jfif:
JFIF

625
Documentation/media/uapi/v4l/ext-ctrls-codec.rst
View file

@ -759,6 +759,32 @@ enum v4l2_mpeg_video_h264_level -
.. _v4l2-mpeg-video-mpeg2-level:
``V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL``
(enum)
enum v4l2_mpeg_video_mpeg2_level -
The level information for the MPEG2 elementary stream. Applicable to
MPEG2 codecs. Possible values are:
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - ``V4L2_MPEG_VIDEO_MPEG2_LEVEL_LOW``
- Low Level (LL)
* - ``V4L2_MPEG_VIDEO_MPEG2_LEVEL_MAIN``
- Main Level (ML)
* - ``V4L2_MPEG_VIDEO_MPEG2_LEVEL_HIGH_1440``
- High-1440 Level (H-14)
* - ``V4L2_MPEG_VIDEO_MPEG2_LEVEL_HIGH``
- High Level (HL)
.. _v4l2-mpeg-video-mpeg4-level:
``V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL``
@ -845,6 +871,36 @@ enum v4l2_mpeg_video_h264_profile -
.. _v4l2-mpeg-video-mpeg2-profile:
``V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE``
(enum)
enum v4l2_mpeg_video_mpeg2_profile -
The profile information for MPEG2. Applicable to MPEG2 codecs.
Possible values are:
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_SIMPLE``
- Simple profile (SP)
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_MAIN``
- Main profile (MP)
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_SNR_SCALABLE``
- SNR Scalable profile (SNR)
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_SPATIALLY_SCALABLE``
- Spatially Scalable profile (Spt)
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_HIGH``
- High profile (HP)
* - ``V4L2_MPEG_VIDEO_MPEG2_PROFILE_MULTIVIEW``
- Multi-view profile (MVP)
.. _v4l2-mpeg-video-mpeg4-profile:
``V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE``
@ -1395,6 +1451,575 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
- Layer number
.. _v4l2-mpeg-h264:
``V4L2_CID_MPEG_VIDEO_H264_SPS (struct)``
Specifies the sequence parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.1.1 "Sequence Parameter Set Data
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_sps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_sps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``profile_idc``
-
* - __u8
- ``constraint_set_flags``
- See :ref:`Sequence Parameter Set Constraints Set Flags <h264_sps_constraints_set_flags>`
* - __u8
- ``level_idc``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``chroma_format_idc``
-
* - __u8
- ``bit_depth_luma_minus8``
-
* - __u8
- ``bit_depth_chroma_minus8``
-
* - __u8
- ``log2_max_frame_num_minus4``
-
* - __u8
- ``pic_order_cnt_type``
-
* - __u8
- ``log2_max_pic_order_cnt_lsb_minus4``
-
* - __u8
- ``max_num_ref_frames``
-
* - __u8
- ``num_ref_frames_in_pic_order_cnt_cycle``
-
* - __s32
- ``offset_for_ref_frame[255]``
-
* - __s32
- ``offset_for_non_ref_pic``
-
* - __s32
- ``offset_for_top_to_bottom_field``
-
* - __u16
- ``pic_width_in_mbs_minus1``
-
* - __u16
- ``pic_height_in_map_units_minus1``
-
* - __u32
- ``flags``
- See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
.. _h264_sps_constraints_set_flags:
``Sequence Parameter Set Constraints Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_CONSTRAINT_SET0_FLAG``
- 0x00000001
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET1_FLAG``
- 0x00000002
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET2_FLAG``
- 0x00000004
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET3_FLAG``
- 0x00000008
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET4_FLAG``
- 0x00000010
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET5_FLAG``
- 0x00000020
-
.. _h264_sps_flags:
``Sequence Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE``
- 0x00000001
-
* - ``V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS``
- 0x00000002
-
* - ``V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO``
- 0x00000004
-
* - ``V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED``
- 0x00000008
-
* - ``V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY``
- 0x00000010
-
* - ``V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD``
- 0x00000020
-
* - ``V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE``
- 0x00000040
-
``V4L2_CID_MPEG_VIDEO_H264_PPS (struct)``
Specifies the picture parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.2 "Picture Parameter Set RBSP
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_pps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_pps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``pic_parameter_set_id``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``num_slice_groups_minus1``
-
* - __u8
- ``num_ref_idx_l0_default_active_minus1``
-
* - __u8
- ``num_ref_idx_l1_default_active_minus1``
-
* - __u8
- ``weighted_bipred_idc``
-
* - __s8
- ``pic_init_qp_minus26``
-
* - __s8
- ``pic_init_qs_minus26``
-
* - __s8
- ``chroma_qp_index_offset``
-
* - __s8
- ``second_chroma_qp_index_offset``
-
* - __u16
- ``flags``
- See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
.. _h264_pps_flags:
``Picture Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
- 0x00000001
-
* - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
- 0x00000002
-
* - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
- 0x00000004
-
* - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
- 0x00000008
-
* - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
- 0x00000010
-
* - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
- 0x00000020
-
* - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
- 0x00000040
-
* - ``V4L2_H264_PPS_FLAG_PIC_SCALING_MATRIX_PRESENT``
- 0x00000080
-
``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX (struct)``
Specifies the scaling matrix (as extracted from the bitstream) for
the associated H264 slice data. The bitstream parameters are
defined according to :ref:`h264`, section 7.4.2.1.1.1 "Scaling
List Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_scaling_matrix
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``scaling_list_4x4[6][16]``
-
* - __u8
- ``scaling_list_8x8[6][64]``
-
``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS (struct)``
Specifies the slice parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
documentation, refer to the above specification, unless there is
an explicit comment stating otherwise.
.. note::
This compound control is not yet part of the public kernel API
and it is expected to change.
This structure is expected to be passed as an array, with one
entry for each slice included in the bitstream buffer.
.. c:type:: v4l2_ctrl_h264_slice_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_slice_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u32
- ``size``
-
* - __u32
- ``header_bit_size``
-
* - __u16
- ``first_mb_in_slice``
-
* - __u8
- ``slice_type``
-
* - __u8
- ``pic_parameter_set_id``
-
* - __u8
- ``colour_plane_id``
-
* - __u8
- ``redundant_pic_cnt``
-
* - __u16
- ``frame_num``
-
* - __u16
- ``idr_pic_id``
-
* - __u16
- ``pic_order_cnt_lsb``
-
* - __s32
- ``delta_pic_order_cnt_bottom``
-
* - __s32
- ``delta_pic_order_cnt0``
-
* - __s32
- ``delta_pic_order_cnt1``
-
* - struct :c:type:`v4l2_h264_pred_weight_table`
- ``pred_weight_table``
-
* - __u32
- ``dec_ref_pic_marking_bit_size``
-
* - __u32
- ``pic_order_cnt_bit_size``
-
* - __u8
- ``cabac_init_idc``
-
* - __s8
- ``slice_qp_delta``
-
* - __s8
- ``slice_qs_delta``
-
* - __u8
- ``disable_deblocking_filter_idc``
-
* - __s8
- ``slice_alpha_c0_offset_div2``
-
* - __s8
- ``slice_beta_offset_div2``
-
* - __u8
- ``num_ref_idx_l0_active_minus1``
-
* - __u8
- ``num_ref_idx_l1_active_minus1``
-
* - __u32
- ``slice_group_change_cycle``
-
* - __u8
- ``ref_pic_list0[32]``
- Reference picture list after applying the per-slice modifications
* - __u8
- ``ref_pic_list1[32]``
- Reference picture list after applying the per-slice modifications
* - __u32
- ``flags``
- See :ref:`Slice Parameter Flags <h264_slice_flags>`
.. _h264_slice_flags:
``Slice Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SLICE_FLAG_FIELD_PIC``
- 0x00000001
-
* - ``V4L2_H264_SLICE_FLAG_BOTTOM_FIELD``
- 0x00000002
-
* - ``V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED``
- 0x00000004
-
* - ``V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH``
- 0x00000008
-
``Prediction Weight Table``
The bitstream parameters are defined according to :ref:`h264`,
section 7.4.3.2 "Prediction Weight Table Semantics". For further
documentation, refer to the above specification, unless there is
an explicit comment stating otherwise.
.. c:type:: v4l2_h264_pred_weight_table
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_pred_weight_table
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u16
- ``luma_log2_weight_denom``
-
* - __u16
- ``chroma_log2_weight_denom``
-
* - struct :c:type:`v4l2_h264_weight_factors`
- ``weight_factors[2]``
- The weight factors at index 0 are the weight factors for the reference
list 0, the one at index 1 for the reference list 1.
.. c:type:: v4l2_h264_weight_factors
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_weight_factors
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __s16
- ``luma_weight[32]``
-
* - __s16
- ``luma_offset[32]``
-
* - __s16
- ``chroma_weight[32][2]``
-
* - __s16
- ``chroma_offset[32][2]``
-
``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
Specifies the decode parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`. For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_decode_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_decode_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - struct :c:type:`v4l2_h264_dpb_entry`
- ``dpb[16]``
-
* - __u16
- ``num_slices``
- Number of slices needed to decode the current frame
* - __u16
- ``nal_ref_idc``
- NAL reference ID value coming from the NAL Unit header
* - __u8
- ``ref_pic_list_p0[32]``
- Backward reference list used by P-frames in the original bitstream order
* - __u8
- ``ref_pic_list_b0[32]``
- Backward reference list used by B-frames in the original bitstream order
* - __u8
- ``ref_pic_list_b1[32]``
- Forward reference list used by B-frames in the original bitstream order
* - __s32
- ``top_field_order_cnt``
- Picture Order Count for the coded top field
* - __s32
- ``bottom_field_order_cnt``
- Picture Order Count for the coded bottom field
* - __u32
- ``flags``
- See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
.. _h264_decode_params_flags:
``Decode Parameters Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC``
- 0x00000001
- That picture is an IDR picture
.. c:type:: v4l2_h264_dpb_entry
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_dpb_entry
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u64
- ``reference_ts``
- Timestamp of the V4L2 capture buffer to use as reference, used
with B-coded and P-coded frames. The timestamp refers to the
``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u16
- ``frame_num``
-
* - __u16
- ``pic_num``
-
* - __s32
- ``top_field_order_cnt``
-
* - __s32
- ``bottom_field_order_cnt``
-
* - __u32
- ``flags``
- See :ref:`DPB Entry Flags <h264_dpb_flags>`
.. _h264_dpb_flags:
``DPB Entries Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DPB_ENTRY_FLAG_VALID``
- 0x00000001
- The DPB entry is valid and should be considered
* - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE``
- 0x00000002
- The DPB entry is currently being used as a reference frame
* - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM``
- 0x00000004
- The DPB entry is a long term reference frame
.. _v4l2-mpeg-mpeg2:

15
Documentation/media/uapi/v4l/extended-controls.rst
View file

@ -85,20 +85,17 @@ be able to see such compound controls. In other words, these controls
with compound types should only be used programmatically.
Since such compound controls need to expose more information about
themselves than is possible with
:ref:`VIDIOC_QUERYCTRL` the
:ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
particular, this ioctl gives the dimensions of the N-dimensional array
if this control consists of more than one element.
themselves than is possible with :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
the :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
particular, this ioctl gives the dimensions of the N-dimensional array if
this control consists of more than one element.
.. note::
#. It is important to realize that due to the flexibility of controls it is
necessary to check whether the control you want to set actually is
supported in the driver and what the valid range of values is. So use
the :ref:`VIDIOC_QUERYCTRL` (or :ref:`VIDIOC_QUERY_EXT_CTRL
<VIDIOC_QUERYCTRL>`) and :ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>`
ioctls to check this.
:ref:`VIDIOC_QUERYCTRL` to check this.
#. It is possible that some of the menu indices in a control of
type ``V4L2_CTRL_TYPE_MENU`` may not be supported (``VIDIOC_QUERYMENU``
@ -144,7 +141,7 @@ control class is found:
while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &qctrl)) {
if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_MPEG)
break;
/* ... */
/* ... */
qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
}

17
Documentation/media/uapi/v4l/field-order.rst
View file

@ -51,6 +51,11 @@ determined by the video standard. Hence the distinction between temporal
and spatial order of fields. The diagrams below should make this
clearer.
In V4L it is assumed that all video cameras transmit fields on the media
bus in the same order they were captured, so if the top field was
captured first (is the older field), the top field is also transmitted
first on the bus.
All video capture and output devices must report the current field
order. Some drivers may permit the selection of a different order, to
this end applications initialize the ``field`` field of struct
@ -101,10 +106,10 @@ enum v4l2_field
* - ``V4L2_FIELD_INTERLACED``
- 4
- Images contain both fields, interleaved line by line. The temporal
order of the fields (whether the top or bottom field is first
transmitted) depends on the current video standard. M/NTSC
transmits the bottom field first, all other standards the top
field first.
order of the fields (whether the top or bottom field is older)
depends on the current video standard. In M/NTSC the bottom
field is the older field. In all other standards the top field
is the older field.
* - ``V4L2_FIELD_SEQ_TB``
- 5
- Images contain both fields, the top field lines are stored first
@ -135,11 +140,11 @@ enum v4l2_field
* - ``V4L2_FIELD_INTERLACED_TB``
- 8
- Images contain both fields, interleaved line by line, top field
first. The top field is transmitted first.
first. The top field is the older field.
* - ``V4L2_FIELD_INTERLACED_BT``
- 9
- Images contain both fields, interleaved line by line, top field
first. The bottom field is transmitted first.
first. The bottom field is the older field.

25
Documentation/media/uapi/v4l/pixfmt-compressed.rst
View file

@ -52,6 +52,31 @@ Compressed Formats
- ``V4L2_PIX_FMT_H264_MVC``
- 'M264'
- H264 MVC video elementary stream.
* .. _V4L2-PIX-FMT-H264-SLICE-RAW:
- ``V4L2_PIX_FMT_H264_SLICE_RAW``
- 'S264'
- H264 parsed slice data, without the start code and as
extracted from the H264 bitstream. This format is adapted for
stateless video decoders that implement an H264 pipeline
(using the :ref:`mem2mem` and :ref:`media-request-api`).
Metadata associated with the frame to decode are required to
be passed through the ``V4L2_CID_MPEG_VIDEO_H264_SPS``,
``V4L2_CID_MPEG_VIDEO_H264_PPS``,
``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``,
``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS`` and
``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS`` controls. See the
:ref:`associated Codec Control IDs <v4l2-mpeg-h264>`. Exactly
one output and one capture buffer must be provided for use
with this pixel format. The output buffer must contain the
appropriate number of macroblocks to decode a full
corresponding frame to the matching capture buffer.
.. note::
This format is not yet part of the public kernel API and it
is expected to change.
* .. _V4L2-PIX-FMT-H263:
- ``V4L2_PIX_FMT_H263``

15
Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
View file

@ -31,7 +31,20 @@ describing all planes of that format.
* - __u32
- ``sizeimage``
- Maximum size in bytes required for image data in this plane.
- Maximum size in bytes required for image data in this plane,
set by the driver. When the image consists of variable length
compressed data this is the number of bytes required by the
codec to support the worst-case compression scenario.
The driver will set the value for uncompressed images.
Clients are allowed to set the sizeimage field for variable length
compressed data flagged with ``V4L2_FMT_FLAG_COMPRESSED`` at
:ref:`VIDIOC_ENUM_FMT`, but the driver may ignore it and set the
value itself, or it may modify the provided value based on
alignment requirements or minimum/maximum size requirements.
If the client wants to leave this to the driver, then it should
set sizeimage to 0.
* - __u32
- ``bytesperline``
- Distance in bytes between the leftmost pixels in two adjacent

13
Documentation/media/uapi/v4l/pixfmt-v4l2.rst
View file

@ -89,7 +89,18 @@ Single-planar format structure
- Size in bytes of the buffer to hold a complete image, set by the
driver. Usually this is ``bytesperline`` times ``height``. When
the image consists of variable length compressed data this is the
maximum number of bytes required to hold an image.
number of bytes required by the codec to support the worst-case
compression scenario.
The driver will set the value for uncompressed images.
Clients are allowed to set the sizeimage field for variable length
compressed data flagged with ``V4L2_FMT_FLAG_COMPRESSED`` at
:ref:`VIDIOC_ENUM_FMT`, but the driver may ignore it and set the
value itself, or it may modify the provided value based on
alignment requirements or minimum/maximum size requirements.
If the client wants to leave this to the driver, then it should
set sizeimage to 0.
* - __u32
- ``colorspace``
- Image colorspace, from enum :c:type:`v4l2_colorspace`.

8
Documentation/media/uapi/v4l/vidioc-qbuf.rst
View file

@ -139,6 +139,14 @@ 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 must be passed in as well.
If the application sets the ``memory`` field to ``V4L2_MEMORY_DMABUF`` to
dequeue a :ref:`DMABUF <dmabuf>` buffer, the driver fills the ``m.fd`` field
with a file descriptor numerically the same as the one given to ``VIDIOC_QBUF``
when the buffer was enqueued. No new file descriptor is created at dequeue time
and the value is only for the application convenience. When the multi-planar
API is used the ``m.fd`` fields of the passed array of struct
:c:type:`v4l2_plane` are filled instead.
By default ``VIDIOC_DQBUF`` blocks when no buffer is in the outgoing
queue. When the ``O_NONBLOCK`` flag was given to the
:ref:`open() <func-open>` function, ``VIDIOC_DQBUF`` returns

30
Documentation/media/uapi/v4l/vidioc-queryctrl.rst
View file

@ -443,6 +443,36 @@ See also the examples in :ref:`control`.
- n/a
- A struct :c:type:`v4l2_ctrl_mpeg2_quantization`, containing MPEG-2
quantization matrices for stateless video decoders.
* - ``V4L2_CTRL_TYPE_H264_SPS``
- n/a
- n/a
- n/a
- A struct :c:type:`v4l2_ctrl_h264_sps`, containing H264
sequence parameters for stateless video decoders.
* - ``V4L2_CTRL_TYPE_H264_PPS``
- n/a
- n/a
- n/a
- A struct :c:type:`v4l2_ctrl_h264_pps`, containing H264
picture parameters for stateless video decoders.
* - ``V4L2_CTRL_TYPE_H264_SCALING_MATRIX``
- n/a
- n/a
- n/a
- A struct :c:type:`v4l2_ctrl_h264_scaling_matrix`, containing H264
scaling matrices for stateless video decoders.
* - ``V4L2_CTRL_TYPE_H264_SLICE_PARAMS``
- n/a
- n/a
- n/a
- A struct :c:type:`v4l2_ctrl_h264_slice_params`, containing H264
slice parameters for stateless video decoders.
* - ``V4L2_CTRL_TYPE_H264_DECODE_PARAMS``
- n/a
- n/a
- n/a
- A struct :c:type:`v4l2_ctrl_h264_decode_params`, containing H264
decode parameters for stateless video decoders.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|

1
Documentation/media/v4l-drivers/index.rst
View file

@ -64,5 +64,6 @@ For more details see the file COPYING in the source distribution of Linux.
si476x
soc-camera
uvcvideo
vimc
vivid
zr364xx

22
Documentation/media/v4l-drivers/vimc.dot Normal file
View file

@ -0,0 +1,22 @@
# SPDX-License-Identifier: GPL-2.0
digraph board {
rankdir=TB
n00000001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
n00000001:port0 -> n00000005:port0 [style=bold]
n00000001:port0 -> n0000000b [style=bold]
n00000003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
n00000003:port0 -> n00000008:port0 [style=bold]
n00000003:port0 -> n0000000f [style=bold]
n00000005 [label="{{<port0> 0} | Debayer A\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000005:port1 -> n00000017:port0
n00000008 [label="{{<port0> 0} | Debayer B\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000008:port1 -> n00000017:port0 [style=dashed]
n0000000b [label="Raw Capture 0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
n0000000f [label="Raw Capture 1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
n00000013 [label="RGB/YUV Input\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
n00000013 -> n00000017:port0 [style=dashed]
n00000017 [label="{{<port0> 0} | Scaler\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000017:port1 -> n0000001a [style=bold]
n0000001a [label="RGB/YUV Capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
}

98
Documentation/media/v4l-drivers/vimc.rst Normal file
View file

@ -0,0 +1,98 @@
.. SPDX-License-Identifier: GPL-2.0
The Virtual Media Controller Driver (vimc)
==========================================
The vimc driver emulates complex video hardware using the V4L2 API and the Media
API. It has a capture device and three subdevices: sensor, debayer and scaler.
Topology
--------
The topology is hardcoded, although you could modify it in vimc-core and
recompile the driver to achieve your own topology. This is the default topology:
.. _vimc_topology_graph:
.. kernel-figure:: vimc.dot
:alt: vimc.dot
:align: center
Media pipeline graph on vimc
Configuring the topology
~~~~~~~~~~~~~~~~~~~~~~~~
Each subdevice will come with its default configuration (pixelformat, height,
width, ...). One needs to configure the topology in order to match the
configuration on each linked subdevice to stream frames through the pipeline.
If the configuration doesn't match, the stream will fail. The ``v4l-utils``
package is a bundle of user-space applications, that comes with ``media-ctl`` and
``v4l2-ctl`` that can be used to configure the vimc configuration. This sequence
of commands fits for the default topology:
.. code-block:: bash
media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
Subdevices
----------
Subdevices define the behavior of an entity in the topology. Depending on the
subdevice, the entity can have multiple pads of type source or sink.
vimc-sensor:
Generates images in several formats using video test pattern generator.
Exposes:
* 1 Pad source
vimc-debayer:
Transforms images in bayer format into a non-bayer format.
Exposes:
* 1 Pad sink
* 1 Pad source
vimc-scaler:
Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a
1920x1440 image. (this value can be configured, see at
`Module options`_).
Exposes:
* 1 Pad sink
* 1 Pad source
vimc-capture:
Exposes node /dev/videoX to allow userspace to capture the stream.
Exposes:
* 1 Pad sink
* 1 Pad source
Module options
---------------
Vimc has a few module parameters to configure the driver. You should pass
those arguments to each subdevice, not to the vimc module. For example::
vimc_subdevice.param=value
* ``vimc_scaler.sca_mult=<unsigned int>``
Image size multiplier factor to be used to multiply both width and
height, so the image size will be ``sca_mult^2`` bigger than the
original one. Currently, only supports scaling up (the default value
is 3).
* ``vimc_debayer.deb_mean_win_size=<unsigned int>``
Window size to calculate the mean. Note: the window size needs to be an
odd number, as the main pixel stays in the center of the window,
otherwise the next odd number is considered (the default value is 3).

5
Documentation/media/v4l-drivers/vivid.rst
View file

@ -941,6 +941,11 @@ Digital Video Controls
affects the reported colorspace since DVI_D outputs will always use
sRGB.
- Display Present:
sets the presence of a "display" on the HDMI output. This affects
the tx_edid_present, tx_hotplug and tx_rxsense controls.
FM Radio Receiver Controls
~~~~~~~~~~~~~~~~~~~~~~~~~~

5
Documentation/media/videodev2.h.rst.exceptions
View file

@ -136,6 +136,11 @@ replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_PPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_SCALING_MATRIX :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_DECODE_PARAMS :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities