summaryrefslogtreecommitdiff
path: root/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2020-06-03 20:59:38 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2020-06-03 20:59:38 -0700
commita98f670e41a99f53acb1fb33cee9c6abbb2e6f23 (patch)
treef8ae10a4cb91758ad7f9422053753a8c5d0f04dc /Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
parentee01c4d72adffb7d424535adf630f2955748fa8b (diff)
parent938b29db3aa9c293c7c1366b16e55e308f1a1ddd (diff)
Merge tag 'media/v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - Media documentation is now split into admin-guide, driver-api and userspace-api books (a longstanding request from Jon); - The media Kconfig was reorganized, in order to make easier to select drivers and their dependencies; - The testing drivers now has a separate directory; - added a new driver for Rockchip Video Decoder IP; - The atomisp staging driver was resurrected. It is meant to work with 4 generations of cameras on Atom-based laptops, tablets and cell phones. So, it seems worth investing time to cleanup this driver and making it in good shape. - Added some V4L2 core ancillary routines to help with h264 codecs; - Added an ov2740 image sensor driver; - The si2157 gained support for Analog TV, which, in turn, added support for some cx231xx and cx23885 boards to also support analog standards; - Added some V4L2 controls (V4L2_CID_CAMERA_ORIENTATION and V4L2_CID_CAMERA_SENSOR_ROTATION) to help identifying where the camera is located at the device; - VIDIOC_ENUM_FMT was extended to support MC-centric devices; - Lots of drivers improvements and cleanups. * tag 'media/v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (503 commits) media: Documentation: media: Refer to mbus format documentation from CSI-2 docs media: s5k5baf: Replace zero-length array with flexible-array media: i2c: imx219: Drop <linux/clk-provider.h> and <linux/clkdev.h> media: i2c: Add ov2740 image sensor driver media: ov8856: Implement sensor module revision identification media: ov8856: Add devicetree support media: dt-bindings: ov8856: Document YAML bindings media: dvb-usb: Add Cinergy S2 PCIe Dual Port support media: dvbdev: Fix tuner->demod media controller link media: dt-bindings: phy: phy-rockchip-dphy-rx0: move rockchip dphy rx0 bindings out of staging media: staging: dt-bindings: phy-rockchip-dphy-rx0: remove non-used reg property media: atomisp: unify the version for isp2401 a0 and b0 versions media: atomisp: update TODO with the current data media: atomisp: adjust some code at sh_css that could be broken media: atomisp: don't produce errs for ignored IRQs media: atomisp: print IRQ when debugging media: atomisp: isp_mmu: don't use kmem_cache media: atomisp: add a notice about possible leak resources media: atomisp: disable the dynamic and reserved pools media: atomisp: turn on camera before setting it ...
Diffstat (limited to 'Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst')
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst63
1 files changed, 63 insertions, 0 deletions
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
new file mode 100644
index 000000000000..bb9d484c25e4
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
@@ -0,0 +1,63 @@
+.. Permission is granted to copy, distribute and/or modify this
+.. document under the terms of the GNU Free Documentation License,
+.. Version 1.1 or any later version published by the Free Software
+.. Foundation, with no Invariant Sections, no Front-Cover Texts
+.. and no Back-Cover Texts. A copy of the license is included at
+.. Documentation/userspace-api/media/fdl-appendix.rst.
+..
+.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
+
+.. _image-process-controls:
+
+*******************************
+Image Process Control Reference
+*******************************
+
+The Image Process control class is intended for low-level control of
+image processing functions. Unlike ``V4L2_CID_IMAGE_SOURCE_CLASS``, the
+controls in this class affect processing the image, and do not control
+capturing of it.
+
+
+.. _image-process-control-id:
+
+Image Process Control IDs
+=========================
+
+``V4L2_CID_IMAGE_PROC_CLASS (class)``
+ The IMAGE_PROC class descriptor.
+
+``V4L2_CID_LINK_FREQ (integer menu)``
+ Data bus frequency. Together with the media bus pixel code, bus type
+ (clock cycles per sample), the data bus frequency defines the pixel
+ rate (``V4L2_CID_PIXEL_RATE``) in the pixel array (or possibly
+ elsewhere, if the device is not an image sensor). The frame rate can
+ be calculated from the pixel clock, image width and height and
+ horizontal and vertical blanking. While the pixel rate control may
+ be defined elsewhere than in the subdev containing the pixel array,
+ the frame rate cannot be obtained from that information. This is
+ because only on the pixel array it can be assumed that the vertical
+ and horizontal blanking information is exact: no other blanking is
+ allowed in the pixel array. The selection of frame rate is performed
+ by selecting the desired horizontal and vertical blanking. The unit
+ of this control is Hz.
+
+``V4L2_CID_PIXEL_RATE (64-bit integer)``
+ Pixel rate in the source pads of the subdev. This control is
+ read-only and its unit is pixels / second.
+
+``V4L2_CID_TEST_PATTERN (menu)``
+ Some capture/display/sensor devices have the capability to generate
+ test pattern images. These hardware specific test patterns can be
+ used to test if a device is working properly.
+
+``V4L2_CID_DEINTERLACING_MODE (menu)``
+ The video deinterlacing mode (such as Bob, Weave, ...). The menu items are
+ driver specific and are documented in :ref:`uapi-v4l-drivers`.
+
+``V4L2_CID_DIGITAL_GAIN (integer)``
+ Digital gain is the value by which all colour components
+ are multiplied by. Typically the digital gain applied is the
+ control value divided by e.g. 0x100, meaning that to get no
+ digital gain the control value needs to be 0x100. The no-gain
+ configuration is also typically the default.