linux-toradex.git/include/uapi/linux/videodev2.h, branch v5.12-rc6

media: doc: pixfmt-rgb: Clarify naming scheme for RGB formats

2020-12-07T13:02:37+00:00

The naming scheme for the RGB pixel formats has been developed
organically, and isn't consistent between formats using less than 8 bits
per pixels (mostly stored in 1 or 2 bytes per pixel, except for RGB666
that uses 4 bytes per pixel) and formats with 8 bits per pixel (stored
in 3 or 4 bytes). For the latter category, the names use a components
order convention that is the opposite of the first category, and the
opposite of DRM pixel formats. This has led to lots of confusion in the
past, and would really benefit from being explained more precisely. Do
so, which also prepares for the addition of additional RGB pixels
formats.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videodev2.h: Move HM12 format to YUV semi-planar section

2020-12-07T12:59:24+00:00

V4L2_PIX_FMT_HM12 is a YUV semi-planar macro-block format. Move it from
the packed YUV formats section where it was misplaced to the YUV
semi-planar formats section.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videodev2.h: Move HI240 format to vendor-specific section

2020-12-07T12:58:16+00:00

V4L2_PIX_FMT_HI240 is a 8-bit dithered RGB format specific to BTTV. Move
it from the packed YUV formats section where it was misplaced to the
vendor-specific formats section.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videodev2.h: Remove unneeded comment about 4CC value

2020-12-07T12:57:36+00:00

The V4L2_PIX_FMT_BGRA444 format has a comment that explains why its 4CC
value is GA12. This explains the development history and isn't of much
interest to readers, it should have been part of a commit message
instead. Drop the comment, anyone interested in history can turn to git.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: vicodec: mark the stateless FWHT API as stable

2020-12-03T11:27:33+00:00

The FWHT stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (fwht-ctrls.h).

Now, the FWHT stateless controls is ready to be part
of the stable uAPI.

While not too late:

- Rename V4L2_CID_MPEG_VIDEO_FWHT_PARAMS to V4L2_CID_STATELESS_FWHT_PARAMS.

- Move the contents of fwht-ctrls.h to v4l2-controls.h.

- Move the public parts of drivers/media/test-drivers/vicodec/codec-fwht.h
  to v4l2-controls.h.

- Add V4L2_CTRL_TYPE_FWHT_PARAMS control initialization and validation.

- Add p_fwht_params to struct v4l2_ext_control.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: uapi: move H264 stateless controls out of staging

2020-12-03T11:27:33+00:00

The H.264 stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.

Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (h264-ctrls.h).

Now, the H264 stateless controls is ready to be part
of the stable uAPI.

While not too late, let's rename them and re-number their
control IDs, moving them to the newly created stateless
control class, and updating all the drivers accordingly.

Signed-off-by: Ezequiel Garcia 
Tested-by: Jernej Skrabec 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: uapi: Move the H264 stateless control types out of staging

2020-12-03T11:27:33+00:00

Move the H264 stateless control types out of staging,
and re-number them to avoid any confusion.

Signed-off-by: Ezequiel Garcia 
Tested-by: Jernej Skrabec 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: uapi: Move parsed H264 pixel format out of staging

2020-12-03T11:27:33+00:00

Since we are ready to stabilize the H264 stateless API,
start by first moving the parsed H264 pixel format.

Signed-off-by: Ezequiel Garcia 
Tested-by: Jernej Skrabec 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format

2020-11-17T05:59:56+00:00

Add the Rockchip ISP1 specific processing parameter format
V4L2_META_FMT_RK_ISP1_PARAMS and metadata format
V4L2_META_FMT_RK_ISP1_STAT_3A for 3A.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Jacob Chen 
Signed-off-by: Helen Koike 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: Fix V4L2_COLORSPACE_470_SYSTEM_BG description

2020-11-16T09:31:07+00:00

The description of the V4L2_COLORSPACE_470_SYSTEM_BG stated that it was
superseded by SMPTE 170M. That is incorrect. The probably root cause of
this is that the HDMI standard does not support this colorspace and,
unless otherwise signaled, will fall back to SMPTE 170M for SDTV.

However, EBU Tech. 3321 states that sources should signal Rec. 709 as the
colorimetry when using HDMI since the difference between Rec. 709 and
Tech. 3213 are negligible.

Update the text accordingly.

Also drop a spurious " at the end of the Tech 3213 title in the
bibliography.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab