#
fea13a69 |
|
10-Dec-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: docs: uAPI: fix table output in LaTeX/PDF format There are lots of tables that are not properly displayed in LaTeX/PDF. Fix the tablecolumns, add longtable where needed and LaTeX formatting macros, in order to address such issues. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
407e84cd |
|
24-Sep-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: docs: make V4L documents more compatible with Sphinx 3.1+ Sphinx 3.x broke support for the cdomain.py extension, as the c domain code was rewritten. Due to that, the c tags need to be re-written, in order to use the new c domain notation. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
b38c73ca |
|
27-Aug-2020 |
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> |
media: v4l2: add support for colorspace conversion API (CSC) for video capture For video capture it is the driver that reports the colorspace, transfer function, Y'CbCr/HSV encoding and quantization range used by the video, and there is no way to request something different, even though many HDTV receivers have some sort of colorspace conversion capabilities. For output video this feature already exists since the application specifies this information for the video format it will send out, and the transmitter will enable any available CSC if a format conversion has to be performed in order to match the capabilities of the sink. For video capture we propose adding new v4l2_pix_format flag: V4L2_PIX_FMT_FLAG_SET_CSC. The flag is set by the application, the driver will interpret the colorspace, xfer_func, ycbcr_enc/hsv_enc and quantization fields as the requested colorspace information and will attempt to do the conversion it supports. Drivers set the flags V4L2_FMT_FLAG_CSC_COLORSPACE, V4L2_FMT_FLAG_CSC_XFER_FUNC, V4L2_FMT_FLAG_CSC_YCBCR_ENC/V4L2_FMT_FLAG_CSC_HSV_ENC, V4L2_FMT_FLAG_CSC_QUANTIZATION, in the flags field of the struct v4l2_fmtdesc during enumeration to indicate that they support colorspace conversion for the respective field. Drivers do not have to actually look at the flags. If the flags are not set, then the fields 'colorspace', 'xfer_func', 'ycbcr_enc/hsv_enc', and 'quantization' are set to the default values by the core, i.e. just pass on the received format without conversion. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
059b1c5b |
|
26-Aug-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: docs: use the new SPDX header for GFDL-1.1 on *.rst files SPDX v3.10 gained support for GFDL-1.1 with no invariant sections: https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html So, remove the license text, replacing them by this new SPDX license. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
286cf7d3 |
|
26-May-2020 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: videodev2.h: add V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL flag Add the V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL flag to signal that the coded frame interval can be set separately from the raw frame interval for stateful encoders. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Michael Tretter <m.tretter@pengutronix.de> Acked-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
6ba189d3 |
|
06-May-2020 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: vidioc-enum-fmt.rst: make the ENUM_FMT text clearer Rework the documentation to make it easier for the reader to understand the differences in behavior of this ioctl between MC and non-MC drivers. Note the addition of the 'video-node-centric' and 'MC-centric' terms to help understand what the IO_MC capability really means. Also mention in the beginning that mbus_code is one of the fields that application should initialize, and add META_OUTPUT as one of the types that this ioctl supports (that was never added here when the META_OUTPUT buffer type was added). Finally document that EINVAL will be returned if mbus_code is unsupported. Fixes: e5b6b07a1b45 ("media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
e5b6b07a |
|
24-Apr-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices The VIDIOC_ENUM_FMT ioctl enumerates all formats supported by a video node. For MC-centric devices, its behaviour has always been ill-defined, with drivers implementing one of the following behaviours: - No support for VIDIOC_ENUM_FMT at all - Enumerating all formats supported by the video node, regardless of the configuration of the pipeline - Enumerating formats supported by the video node for the active configuration of the connected subdevice The first behaviour is obviously useless for applications. The second behaviour provides the most information, but doesn't offer a way to find what formats are compatible with a given pipeline configuration. The third behaviour fixes that, but with the drawback that applications can't enumerate all supported formats anymore, and have to modify the active configuration of the pipeline to enumerate formats. The situation is messy as none of the implemented behaviours are ideal, and userspace can't predict what will happen as the behaviour is driver-specific. To fix this, let's extend the VIDIOC_ENUM_FMT with a missing capability: enumerating pixel formats for a given media bus code. The media bus code is passed through the v4l2_fmtdesc structure in a new mbus_code field (repurposed from the reserved fields). With this capability in place, applications can enumerate pixel formats for a given media bus code without modifying the active configuration of the device. The current behaviour of the ioctl is preserved when the new mbus_code field is set to 0, ensuring compatibility with existing userspace. The API extension is documented as mandatory for MC-centric devices (as advertised through the V4L2_CAP_IO_MC capability), allowing applications and compliance tools to easily determine the availability of the VIDIOC_ENUM_FMT extension. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
54f38fca |
|
04-Mar-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: docs: move uAPI book to userspace-api/media Since 2017, there is an space reserved for userspace API, created by changeset 1d596dee3862 ("docs: Create a user-space API guide"). As the media subsystem was one of the first subsystems to use Sphinx, until this patch, we were keeping things on a separate place. Let's just use the new location, as having all uAPI altogether will likely make things easier for developers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|