- 07 Dec, 2020 20 commits
-
-
Laurent Pinchart authored
Semi-planar pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and summarize their descriptions in a single table. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Laurent Pinchart authored
Luma-only pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and describe them in a single table. Signed-off-by:
-
Laurent Pinchart authored
Document the naming scheme for the existing packed YUV 4:4:4 formats, as previously done for the RGB formats. Signed-off-by:
-
Laurent Pinchart authored
The 4:4:4 packed YUV formats are documented with a bit-level representation, which creates a wide table. Switch to a byte-oriented representation to make it more compact. This prepares for the addition of formats with more than 8 bits per component, that would make the table way too wide. Signed-off-by:
-
Laurent Pinchart authored
The padding bits are left blank, which look weird in the XYUV format, and, worse, may lead to the VUYX format to be understand as consuming 3 bytes per pixel. Add 'X' for padding bits as we do for RGB formats. Signed-off-by:
-
Laurent Pinchart authored
The pixfmt-packed-yuv.rst file documents packed YUV 4:4:4 formats, but is titled generically as "Packed YUV formats". 4:2:2 and 4:1:1 packed YUV formats are documented in separate files, which can be confusing. Group all packed YUV formats in pixfmt-packed-yuv.rst, which allows documenting the 4:2:2 formats in a more concise way. Signed-off-by:
-
Laurent Pinchart authored
Document YUV subsampling, including chroma spatial siting, and replace the siting examples in individual formats by references to the common documentation. Signed-off-by:
-
Laurent Pinchart authored
Using '-' to represent padding bits and bytes make text and tables more difficult to read. Use 'x' and 'X' instead. Signed-off-by:
-
Laurent Pinchart authored
All formats using 8 bits per component can be described with a byte granularity instead of a bit granularity without loss of precision. This makes the corresponding table more compact and easier to read. Signed-off-by:
-
Laurent Pinchart authored
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 authored
Improve readability of the documentation by adding a section title for the deprecated formats. Signed-off-by:
-
Laurent Pinchart authored
The packed RGB formats documentation includes a layout table without any context. This doesn't bring much useful information, and is confusing at best. Remove it. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
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:
-
Sakari Ailus authored
rval wasn't set, resulting in probe returning zero instead of an error. Fixes: de10c161 ("[media] smiapp: Get clock rate if it's not available through DT") Reported-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
There is no intialization for the 'reg' variable, so printing it produces undefined behavior as well as a compile-time warning: drivers/media/i2c/ccs/ccs-core.c:314:49: error: variable 'reg' is uninitialized when used here [-Werror,-Wuninitialized] "0x%8.8x %s pixels: %d %s (pixelcode %u)\n", reg, Remove the variable and stop printing it. Fixes: fd906581 ("media: smiapp: Obtain frame descriptor from CCS limits") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
Clang points out that the error handling in ov02a10_s_stream() is broken, and just returns a random error code: drivers/media/i2c/ov02a10.c:537:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (ov02a10->streaming == on) ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/media/i2c/ov02a10.c:568:9: note: uninitialized use occurs here return ret; ^~~ drivers/media/i2c/ov02a10.c:537:2: note: remove the 'if' if its condition is always false if (ov02a10->streaming == on) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If streaming is already on, leave it that way and return success. Suggested-by:Dongchun Zhu <dongchun.zhu@mediatek.com> Fixes: 91807efb ("media: i2c: add OV02A10 image sensor driver") Signed-off-by:
-
Sakari Ailus authored
This reverts commit f61eb7bc. While aligning with the OF graph schema will be done for the media DT bindings, this patch got merged a little too hastily. Revert it for now. Suggested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jonas Karlman authored
Add a keymap for the pine64 IR remote [0]. The mouse key has been mapped to KEY_EPG to provide a more useful remote. [0] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpgSigned-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
- 03 Dec, 2020 20 commits
-
-
Mauro Carvalho Chehab authored
With Sphinx 2.x: those two warnings are produced: /devel/v4l/docs/sphinx2/Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede a section header) /devel/v4l/docs/sphinx2/Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must precede a section header) The reason is that there's no blank line between the two identifiers. Fixes: 3f46cac6 ("media: admin-guide/pixfmt-meta-rkisp1.rst: pixfmt reference conforming with macro") Signed-off-by:
-
Hans Verkuil authored
Document V4L2_CTRL_TYPE_FWHT_PARAMS and p_fwht_params. Also improve the V4L2_PIX_FMT_FWHT_STATELESS description. Signed-off-by:
-
Hans Verkuil authored
Add 'struct' to clarify that these are pointers to structs. Signed-off-by:
-
Hans Verkuil authored
Drop the 'bullets' for the HEVC stateless codec documentation. It doesn't work, and they just show up as asterisks. Signed-off-by:
-
Hans Verkuil authored
Move the documentation for the stateless FWHT codec to ext-ctrls-codec-stateless.rst since that is the proper place for the stable stateless API documentation. Signed-off-by:
-
Hans Verkuil authored
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 authored
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 at the driver's code. While not too late, let's rename them is preparation for promoting the stateless FWHT codec API as a public API. Signed-off-by:
-
Hans Verkuil authored
The v4l2_area struct was not documented in the media documentation, which meant that references to that struct elsewhere in the documentation never linked to anything. [mchehab: remove .. cssclass:: longtable] Signed-off-by:
-
Helen Koike authored
Fix warnings from make htmlddocs: Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede a section header) Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must precede a section header) Fixes: df22026a ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format") Signed-off-by:
Helen Koike <helen.koike@collabora.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Ezequiel Garcia authored
Now that we've destaged the H264 stateless codec controls, and with all the pieces in place, update the documentation and move it to its own section. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
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:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Ezequiel Garcia authored
For now, only print the type of the control. In the future, we might want to be able to print the values of all the stateless codec controls currently set in the control handler, which should be useful for debugging reasons. Signed-off-by:
-
Ezequiel Garcia authored
Move the H264 stateless control types out of staging, and re-number them to avoid any confusion. Signed-off-by:
-
Ezequiel Garcia authored
When V4L2_CTRL_TYPE_H264_PRED_WEIGHTS was added, adding a replace symbol directive in videodev2.h.rst.exceptions was missed. Now that the control type is destaged, it's important to fix this. Signed-off-by:
-
Ezequiel Garcia authored
Since we are ready to stabilize the H264 stateless API, start by first moving the parsed H264 pixel format. Signed-off-by:
-
Ezequiel Garcia authored
Add a new control class to hold the stateless codecs controls that are ready to be moved out of staging. Signed-off-by:
-
Ezequiel Garcia authored
Check that all the fields that correspond or are related to a H264 specification syntax element have legal values. Signed-off-by:
-
Ezequiel Garcia authored
Avoid including h264-ctrls.h, vp8-ctrls.h, etc, and instead just include v4l2-ctrls.h which does the right thing. This is in preparation for moving the stateless controls out of staging, which will mean removing some of these headers. Signed-off-by:
-
Ezequiel Garcia authored
For historical reasons, stateful codec controls are named as {}_MPEG_{}. While we can't at this point sanely change all control IDs (such as V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER), we can least change the more meaningful macros such as classes macros. Signed-off-by: -
Ezequiel Garcia authored
Cedrus supports H.264 profiles from Baseline to High, except for the Extended profile Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE so that userspace can query the driver for the supported profiles and levels. Signed-off-by:
-
