Register V4L2 metadata fourcc codes for the Dreamchip RPP-X1 ISP
parameters and statistics buffers. These formats are used by the driver
to exchange ISP configuration and 3A statistics with userspace through
the extensible parameters framework.
Signed-off-by: Jai Luthra <[email protected]>
Reviewed-by: Jacopo Mondi <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Niklas Söderlund <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
The vdpu381 decoder found on newer Rockchip SoC need the information
from the long term and short term ref pic sets from the SPS.
So far, it wasn't included in the v4l2 API, so add it with new dynamic
sized controls.
Each element of the hevc_ext_sps_lt_rps array contains the long term ref
pic set at that index.
Each element of the hevc_ext_sps_st_rps contains the short term ref pic
set at that index, as the raw data.
It is the role of the drivers to calculate the reference sets values.
Reviewed-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Detlev Casanova <[email protected]>
Signed-off-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Introduce a new pixel format, V4L2_PIX_FMT_AV1, to the
Video4Linux2(V4L2) API. This format is intended for AV1
bitstreams in stateful decoding/encoding workflows.
The fourcc code 'AV10' is used to distinguish
this format from the existing V4L2_PIX_FMT_AV1_FRAME,
which is used for stateless AV1 decoder implementation.
Reviewed-by: Bryan O'Donoghue <[email protected]>
Reviewed-by: Nicolas Dufresne <[email protected]>
Reviewed-by: Hans Verkuil <[email protected]>
Signed-off-by: Deepa Guthyappa Madivalara <[email protected]>
Tested-by: Val Packett <[email protected]>
Signed-off-by: Bryan O'Donoghue <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Some definitions use a tab after the define keyword instead of the
usual single space. Replace it for better consistency.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
The UVC driver provides two metadata types V4L2_META_FMT_UVC, and
V4L2_META_FMT_D4XX. The only difference between the two of them is that
V4L2_META_FMT_UVC only copies PTS, SCR, size and flags, and
V4L2_META_FMT_D4XX copies the whole metadata section.
Now we only enable V4L2_META_FMT_D4XX for the Intel D4xx family of
devices, but it is useful to have the whole metadata payload for any
device where vendors include other metadata, such as the one described by
Microsoft:
https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/mf-capture-metadata
This patch introduces a new format V4L2_META_FMT_UVC_MSXU_1_5, that is
identical to V4L2_META_FMT_D4XX.
Let the user enable this format with a quirk for now. This way they can
test if their devices provide useful metadata without rebuilding the
kernel. They can later contribute patches to auto-quirk their devices.
We will also work in methods to auto-detect devices compatible with this
new metadata format.
Suggested-by: Hans de Goede <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
For 12-bit packed Bayer formats: every two consecutive samples are
packed into three bytes. Fix the corresponding comment.
Signed-off-by: Mehdi Djait <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
The Renesas Camera Receiver Unit in the RZ/V2H SoC can output RAW
data captured from an image sensor without conversion to an RGB/YUV
format. In that case the data are packed into 64-bit blocks, with a
variable amount of padding in the most significant bits depending on
the bitdepth of the data. Add new V4L2 pixel format codes for the new
formats, along with documentation to describe them.
Reviewed-by: Lad Prabhakar <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Jacopo Mondi <[email protected]>
Signed-off-by: Daniel Scally <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Add NV15 and NV20 pixel formats used by the Rockchip Video Decoder for
10-bit buffers.
NV15 and NV20 is 10-bit 4:2:0/4:2:2 semi-planar YUV formats similar to
NV12 and NV16, using 10-bit components with no padding between each
component. Instead, a group of 4 luminance/chrominance samples are
stored over 5 bytes in little endian order:
YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' and '20' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a
multiple of 8 for NV15 and 4 for NV20.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Nicolas Dufresne <[email protected]>
Tested-by: Nicolas Dufresne <[email protected]>
Tested-by: Christopher Obbard <[email protected]>
Signed-off-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
V4L2_TYPE_IS_OUTPUT() returns true for V4L2_BUF_TYPE_VIDEO_OVERLAY
which definitely belongs to CAPTURE.
Signed-off-by: Nas Chung <[email protected]>
Signed-off-by: Sebastian Fricke <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Explicitly compare a buffer type only with valid buffer types,
to avoid matching a buffer type outside of the valid buffer type set.
Signed-off-by: Nas Chung <[email protected]>
Reviewed-by: Michael Tretter <[email protected]>
Signed-off-by: Sebastian Fricke <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Add two meta formats for PiSP FE: V4L2_META_FMT_RPI_FE_CFG and
V4L2_META_FMT_RPI_FE_STATS. The former is used to provide configuration
for the FE and the latter is used to read the statistics from the FE.
Signed-off-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
When the index is ORed with V4L2_FMTDESC_FLAG_ENUM_ALL the
driver clears the flag and enumerate all the possible formats,
ignoring any limitations from the current configuration.
Drivers which do not support this flag yet always return an EINVAL.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
[hverkuil: improved doc when the new flag is not supported by the driver]
The rkisp1 driver stores ISP configuration parameters in the fixed
rkisp1_params_cfg structure. As the members of the structure are part of
the userspace API, the structure layout is immutable and cannot be
extended further. Introducing new parameters or modifying the existing
ones would change the buffer layout and cause breakages in existing
applications.
The allow for future extensions to the ISP parameters, introduce a new
extensible parameters format, with a new format 4CC. Document usage of
the new format in the rkisp1 admin guide.
Signed-off-by: Jacopo Mondi <[email protected]>
Reviewed-by: Daniel Scally <[email protected]>
Reviewed-by: Paul Elder <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Tested-by: Kieran Bingham <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Add Raspberry Pi compressed RAW Bayer formats.
The compression algorithm description is provided by Nick Hollinghurst
<[email protected]> from Raspberry Pi.
Signed-off-by: Jacopo Mondi <[email protected]>
Reviewed-by: Naushir Patuck <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
The generic metadata pixel formats (V4L2_META_FMT_GENERIC_*) are meant
to be used in conjunction with device-specific media bus codes. Those
codes are work in progress and not available in the upstream kernel yet.
To make sure the generic metadata pixel formats won't be used by
userspace until we have the full infrastructure in place, keep their
definition private to the kernel for now.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
This is a packed grey-scale image format with a depth of 14 bits per
pixel. Every four consecutive samples are packed into seven bytes. Each
of the first four bytes contain the eight high order bits of the pixels,
and the three following bytes contains the six least significants bits
of each pixel, in the same order.
As the other formats only needed 5 bytes before, append two bytes in the
documentation array.
Signed-off-by: Jean-Michel Hautbois <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
This is a packed grey-scale image format with a depth of 12 bits per
pixel. Two consecutive pixels are packed into 3 bytes. The first 2 bytes
contain the 8 high order bits of the pixels, and the 3rd byte contains
the 4 least significants bits of each pixel, in the same order.
Add the entry in userspace API, and document it.
Signed-off-by: Jean-Michel Hautbois <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Set (and unset) the V4L2_FMT_FLAG_META_LINE_BASED flag in struct
v4l2_fmtdesc based on the format after returning the driver callback for
enumerating formats. This way the drivers don't need to care about the
flag.
Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Many camera sensors, among other devices, transmit embedded data and image
data for each CSI-2 frame. This embedded data typically contains register
configuration of the sensor that has been used to capture the image data
of the same frame.
The embedded data is received by the CSI-2 receiver and has the same
properties as the image data, including that it is line based: it has
width, height and bytesperline (stride).
Add these fields to struct v4l2_meta_format and document them.
Also add V4L2_FMT_FLAG_META_LINE_BASED to tell a given format is
line-based i.e. these fields of struct v4l2_meta_format are valid for it.
Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Generic 8-bit metadata formats define the in-memory data layout but not
the format of the data itself. The reasoning for having such formats is to
allow CSI-2 receiver drivers to receive and DMA drivers to write the data
to memory without knowing a large number of device-specific formats.
These formats may be used only in conjunction with a Media Controller
pipeline where the internal pad of the source sub-device defines the
specific format of the data (using an mbus code).
Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
The structure is packed, which requires that all its fields need to be
also packed.
./include/uapi/linux/videodev2.h:1810:2: warning: field within 'struct v4l2_ext_control' is less aligned than 'union v4l2_ext_control::(anonymous at ./include/uapi/linux/videodev2.h:1810:2)' and is usually due to 'struct v4l2_ext_control' being packed, which can lead to unaligned accesses [-Wunaligned-access]
Explicitly set the inner union as packed.
Marking the inner union as 'packed' does not change the layout, since the
whole struct is already packed, it just silences the clang warning. See
also this llvm discussion:
https://github.com/llvm/llvm-project/issues/55520
Signed-off-by: Ricardo Ribalda <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
VIDIOC_REMOVE_BUFS ioctl allows to remove buffers from a queue.
The number of buffers to remove in given by count field of
struct v4l2_remove_buffers and the range start at the index
specified in the same structure.
Signed-off-by: Benjamin Gaignard <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
[hverkuil: vidioc-remove-bufs.rst: mention no bufs are freed on error]
The HDR10 standard compound controls were missing the corresponding
pointers in videodev2.h. Add these and document them.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
The p_h264_pps pointer in struct v4l2_ext_control was missing the
__user annotation. Add this.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Use one of the struct v4l2_create_buffers reserved bytes to report
the maximum possible number of buffers for the queue.
V4l2 framework set V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS flags in queue
capabilities so userland can know when the field is valid.
Does the same change in v4l2_create_buffers32 structure.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Add HEXTILE compressed format which is defined in Remote Framebuffer
Protocol (RFC 6143, chapter 7.7.4 Hextile Encoding) and is used by
Encoding Compression Engine (ECE) present on Nuvoton NPCM SoCs.
Signed-off-by: Marvin Lin <[email protected]>
Reviewed-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Define one uncompressed capture format V4L2_PIX_FMT_MT2110R in order to
support 10bit for H264 in mt8195.
Signed-off-by: Mingjia Zhang <[email protected]>
Co-developed-by: Yunfei Dong <[email protected]>
Signed-off-by: Yunfei Dong <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Define one uncompressed capture format V4L2_PIX_FMT_MT2110T in order to
support 10bit for AV1/VP9/HEVC in mt8195.
Signed-off-by: Mingjia Zhang <[email protected]>
Co-developed-by: Yunfei Dong <[email protected]>
Signed-off-by: Yunfei Dong <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
This patch adds the AOMedia Video 1 (AV1) kernel uAPI.
This design is based on currently available AV1 API implementations and
aims to support the development of AV1 stateless video codecs
on Linux.
Signed-off-by: Daniel Almeida <[email protected]>
Co-developed-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
VIDIOC_ENUMINPUT documentation describes the tuner field of
struct v4l2_input as index:
Documentation/userspace-api/media/v4l/vidioc-enuminput.rst
"
* - __u32
- ``tuner``
- Capture devices can have zero or more tuners (RF demodulators).
When the ``type`` is set to ``V4L2_INPUT_TYPE_TUNER`` this is an
RF connector and this field identifies the tuner. It corresponds
to struct :c:type:`v4l2_tuner` field ``index``. For
details on tuners see :ref:`tuner`.
"
Drivers I could find also use the 'tuner' field as an index, e.g.:
drivers/media/pci/bt8xx/bttv-driver.c bttv_enum_input()
drivers/media/usb/go7007/go7007-v4l2.c vidioc_enum_input()
However, the UAPI comment claims this field is 'enum v4l2_tuner_type':
include/uapi/linux/videodev2.h
This field being 'enum v4l2_tuner_type' is unlikely as it seems to be
never used that way in drivers, and documentation confirms it. It seem
this comment got in accidentally in the commit which this patch fixes.
Fix the UAPI comment to stop confusion.
This was pointed out by Dmitry while reviewing VIDIOC_ENUMINPUT
support for strace.
Fixes: 6016af82ea ("[media] v4l2: use __u32 rather than enums in ioctl() structs")
Signed-off-by: Marek Vasut <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Use the intended pointer types for p_s32 and p_64 in the union of the
struct v4l2_ext_control.
Fixes: e77eb66342 ("videodev2.h: add p_s32 and p_s64 pointers")
Signed-off-by: Daniel Lundberg Pedersen <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
ABGR64_12 is a reversed RGB format with alpha channel last,
12 bits per component like ABGR32,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
BGR48_12 is a reversed RGB format with 12 bits per component like BGR24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
YUV48_12 is a YUV format with 12-bits per component like YUV24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
[hverkuil: replaced a . by ,]
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Y012 is a luma-only formats with 12-bits per pixel,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
P012 is a YUV format with 12-bits per component with interleaved UV,
like NV12, expanded to 16 bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
And P012M has two non contiguous planes.
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
RealVideo, or also spelled as Real Video, is a suite of proprietary
video compression formats developed by RealNetworks -
the specific format changes with the version.
RealVideo codecs are identified by four-character codes.
RV30 and RV40 are RealNetworks' proprietary H.264-based codecs.
Reviewed-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Ming Qian <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Sorenson Spark is an implementation of H.263 for use
in Flash Video and Adobe Flash files.
Sorenson Spark is an incomplete implementation of H.263.
It differs mostly in header structure and ranges of the coefficients.
Signed-off-by: Ming Qian <[email protected]>
Reviewed-by: Nicolas Dufresne <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Jai Luthra