You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branches 'sh/urgent', 'sh/core', 'sh/clockevents', 'sh/asm-generic' and 'sh/trivial' into sh-fixes-for-linus
This commit is contained in:
@@ -113,3 +113,5 @@ Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
Gustavo Padovan <padovan@profusion.mobi>
|
||||
|
||||
@@ -6,13 +6,21 @@ Description: This is a read-only file. Dumps below driver information and
|
||||
hardware registers.
|
||||
- S ACTive
|
||||
- Command Issue
|
||||
- Allocated
|
||||
- Completed
|
||||
- PORT IRQ STAT
|
||||
- HOST IRQ STAT
|
||||
- Allocated
|
||||
- Commands in Q
|
||||
|
||||
What: /sys/block/rssd*/status
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Indicates the status of the device.
|
||||
Description: This is a read-only file. Indicates the status of the device.
|
||||
|
||||
What: /sys/block/rssd*/flags
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps the flags in port and driver
|
||||
data structure
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
What: /sys/bus/fcoe/ctlr_X
|
||||
Date: March 2012
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
Description: 'FCoE Controller' instances on the fcoe bus
|
||||
Attributes:
|
||||
|
||||
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
||||
this value will change the dev_loss_tmo for all
|
||||
FCFs discovered by this controller.
|
||||
|
||||
lesb_link_fail: Link Error Status Block (LESB) link failure count.
|
||||
|
||||
lesb_vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
failure count.
|
||||
|
||||
lesb_miss_fka: Link Error Status Block (LESB) missed FCoE
|
||||
Initialization Protocol (FIP) Keep-Alives (FKA).
|
||||
|
||||
lesb_symb_err: Link Error Status Block (LESB) symbolic error count.
|
||||
|
||||
lesb_err_block: Link Error Status Block (LESB) block error count.
|
||||
|
||||
lesb_fcs_error: Link Error Status Block (LESB) Fibre Channel
|
||||
Serivces error count.
|
||||
|
||||
Notes: ctlr_X (global increment starting at 0)
|
||||
|
||||
What: /sys/bus/fcoe/fcf_X
|
||||
Date: March 2012
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
Description: 'FCoE FCF' instances on the fcoe bus. A FCF is a Fibre Channel
|
||||
Forwarder, which is a FCoE switch that can accept FCoE
|
||||
(Ethernet) packets, unpack them, and forward the embedded
|
||||
Fibre Channel frames into a FC fabric. It can also take
|
||||
outbound FC frames and pack them in Ethernet packets to
|
||||
be sent to their destination on the Ethernet segment.
|
||||
Attributes:
|
||||
|
||||
fabric_name: Identifies the fabric that the FCF services.
|
||||
|
||||
switch_name: Identifies the FCF.
|
||||
|
||||
priority: The switch's priority amongst other FCFs on the same
|
||||
fabric.
|
||||
|
||||
selected: 1 indicates that the switch has been selected for use;
|
||||
0 indicates that the swich will not be used.
|
||||
|
||||
fc_map: The Fibre Channel MAP
|
||||
|
||||
vfid: The Virtual Fabric ID
|
||||
|
||||
mac: The FCF's MAC address
|
||||
|
||||
fka_peroid: The FIP Keep-Alive peroid
|
||||
|
||||
fabric_state: The internal kernel state
|
||||
"Unknown" - Initialization value
|
||||
"Disconnected" - No link to the FCF/fabric
|
||||
"Connected" - Host is connected to the FCF
|
||||
"Deleted" - FCF is being removed from the system
|
||||
|
||||
dev_loss_tmo: The device loss timeout peroid for this FCF.
|
||||
|
||||
Notes: A device loss infrastructre similar to the FC Transport's
|
||||
is present in fcoe_sysfs. It is nice to have so that a
|
||||
link flapping adapter doesn't continually advance the count
|
||||
used to identify the discovered FCF. FCFs will exist in a
|
||||
"Disconnected" state until either the timer expires and the
|
||||
FCF becomes "Deleted" or the FCF is rediscovered and becomes
|
||||
"Connected."
|
||||
|
||||
|
||||
Users: The first user of this interface will be the fcoeadm application,
|
||||
which is commonly packaged in the fcoe-utils package.
|
||||
@@ -0,0 +1,15 @@
|
||||
What: /sys/bus/i2c/devices/.../output_hvled[n]
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the controlling backlight device for high-voltage current
|
||||
sink HVLED[n] (n = 1, 2) (0, 1).
|
||||
|
||||
What: /sys/bus/i2c/devices/.../output_lvled[n]
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the controlling led device for low-voltage current sink
|
||||
LVLED[n] (n = 1..5) (0..3).
|
||||
@@ -65,11 +65,11 @@ snap_*
|
||||
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
|
||||
-------------------------------------------------------------
|
||||
|
||||
id
|
||||
snap_id
|
||||
|
||||
The rados internal snapshot id assigned for this snapshot
|
||||
|
||||
size
|
||||
snap_size
|
||||
|
||||
The size of the image when this snapshot was taken.
|
||||
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
What: /sys/class/backlight/<backlight>/als_channel
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the ALS output channel used as input in
|
||||
ALS-current-control mode (0, 1), where
|
||||
|
||||
0 - out_current0 (backlight 0)
|
||||
1 - out_current1 (backlight 1)
|
||||
|
||||
What: /sys/class/backlight/<backlight>/als_en
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Enable ALS-current-control mode (0, 1).
|
||||
|
||||
What: /sys/class/backlight/<backlight>/id
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the id of this backlight (0, 1).
|
||||
|
||||
What: /sys/class/backlight/<backlight>/linear
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the brightness-mapping mode (0, 1), where
|
||||
|
||||
0 - exponential mode
|
||||
1 - linear mode
|
||||
|
||||
What: /sys/class/backlight/<backlight>/pwm
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the PWM-input control mask (5 bits), where
|
||||
|
||||
bit 5 - PWM-input enabled in Zone 4
|
||||
bit 4 - PWM-input enabled in Zone 3
|
||||
bit 3 - PWM-input enabled in Zone 2
|
||||
bit 2 - PWM-input enabled in Zone 1
|
||||
bit 1 - PWM-input enabled in Zone 0
|
||||
bit 0 - PWM-input enabled
|
||||
@@ -0,0 +1,65 @@
|
||||
What: /sys/class/leds/<led>/als_channel
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the ALS output channel to use as input in
|
||||
ALS-current-control mode (1, 2), where
|
||||
|
||||
1 - out_current1
|
||||
2 - out_current2
|
||||
|
||||
What: /sys/class/leds/<led>/als_en
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Enable ALS-current-control mode (0, 1).
|
||||
|
||||
What: /sys/class/leds/<led>/falltime
|
||||
What: /sys/class/leds/<led>/risetime
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the pattern generator fall and rise times (0..7), where
|
||||
|
||||
0 - 2048 us
|
||||
1 - 262 ms
|
||||
2 - 524 ms
|
||||
3 - 1.049 s
|
||||
4 - 2.097 s
|
||||
5 - 4.194 s
|
||||
6 - 8.389 s
|
||||
7 - 16.78 s
|
||||
|
||||
What: /sys/class/leds/<led>/id
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the id of this led (0..3).
|
||||
|
||||
What: /sys/class/leds/<led>/linear
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the brightness-mapping mode (0, 1), where
|
||||
|
||||
0 - exponential mode
|
||||
1 - linear mode
|
||||
|
||||
What: /sys/class/leds/<led>/pwm
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the PWM-input control mask (5 bits), where
|
||||
|
||||
bit 5 - PWM-input enabled in Zone 4
|
||||
bit 4 - PWM-input enabled in Zone 3
|
||||
bit 3 - PWM-input enabled in Zone 2
|
||||
bit 2 - PWM-input enabled in Zone 1
|
||||
bit 1 - PWM-input enabled in Zone 0
|
||||
bit 0 - PWM-input enabled
|
||||
@@ -123,3 +123,54 @@ Description:
|
||||
half page, or a quarter page).
|
||||
|
||||
In the case of ECC NOR, it is the ECC block size.
|
||||
|
||||
What: /sys/class/mtd/mtdX/ecc_strength
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
Maximum number of bit errors that the device is capable of
|
||||
correcting within each region covering an ecc step. This will
|
||||
always be a non-negative integer. Note that some devices will
|
||||
have multiple ecc steps within each writesize region.
|
||||
|
||||
In the case of devices lacking any ECC capability, it is 0.
|
||||
|
||||
What: /sys/class/mtd/mtdX/bitflip_threshold
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
This allows the user to examine and adjust the criteria by which
|
||||
mtd returns -EUCLEAN from mtd_read(). If the maximum number of
|
||||
bit errors that were corrected on any single region comprising
|
||||
an ecc step (as reported by the driver) equals or exceeds this
|
||||
value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
|
||||
returned. Higher layers (e.g., UBI) use this return code as an
|
||||
indication that an erase block may be degrading and should be
|
||||
scrutinized as a candidate for being marked as bad.
|
||||
|
||||
The initial value may be specified by the flash device driver.
|
||||
If not, then the default value is ecc_strength.
|
||||
|
||||
The introduction of this feature brings a subtle change to the
|
||||
meaning of the -EUCLEAN return code. Previously, it was
|
||||
interpreted to mean simply "one or more bit errors were
|
||||
corrected". Its new interpretation can be phrased as "a
|
||||
dangerously high number of bit errors were corrected on one or
|
||||
more regions comprising an ecc step". The precise definition of
|
||||
"dangerously high" can be adjusted by the user with
|
||||
bitflip_threshold. Users are discouraged from doing this,
|
||||
however, unless they know what they are doing and have intimate
|
||||
knowledge of the properties of their device. Broadly speaking,
|
||||
bitflip_threshold should be low enough to detect genuine erase
|
||||
block degradation, but high enough to avoid the consequences of
|
||||
a persistent return value of -EUCLEAN on devices where sticky
|
||||
bitflips occur. Note that if bitflip_threshold exceeds
|
||||
ecc_strength, -EUCLEAN is never returned by mtd_read().
|
||||
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
|
||||
returned, absent a hard error.
|
||||
|
||||
This is generally applicable only to NAND flash devices with ECC
|
||||
capability. It is ignored on devices lacking ECC capability;
|
||||
i.e., devices for which ecc_strength is zero.
|
||||
|
||||
@@ -23,9 +23,10 @@ Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Attribute group for control of the status LEDs and the OLEDs.
|
||||
This attribute group is only available for Intuos 4 M, L,
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
|
||||
(LEDs only). Therefore its presence implicitly signifies the
|
||||
presence of said LEDs and OLEDs on the tablet device.
|
||||
and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
|
||||
21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
|
||||
implicitly signifies the presence of said LEDs and OLEDs on the
|
||||
tablet device.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
|
||||
Date: August 2011
|
||||
@@ -48,10 +49,10 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the four (for Intuos 4)
|
||||
or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
|
||||
LEDs is active (0..3). The other three LEDs on the same side are
|
||||
always inactive.
|
||||
Writing to this file sets which one of the four (for Intuos 4
|
||||
and Intuos 5) or of the right four (for Cintiq 21UX2 and Cintiq
|
||||
24HD) status LEDs is active (0..3). The other three LEDs on the
|
||||
same side are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
|
||||
Date: September 2011
|
||||
|
||||
@@ -671,8 +671,9 @@ ones already enabled by DEBUG.
|
||||
Chapter 14: Allocating memory
|
||||
|
||||
The kernel provides the following general purpose memory allocators:
|
||||
kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc(). Please refer to
|
||||
the API documentation for further information about them.
|
||||
kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
|
||||
vzalloc(). Please refer to the API documentation for further information
|
||||
about them.
|
||||
|
||||
The preferred form for passing a size of a struct is the following:
|
||||
|
||||
@@ -686,6 +687,17 @@ Casting the return value which is a void pointer is redundant. The conversion
|
||||
from void pointer to any other pointer type is guaranteed by the C programming
|
||||
language.
|
||||
|
||||
The preferred form for allocating an array is the following:
|
||||
|
||||
p = kmalloc_array(n, sizeof(...), ...);
|
||||
|
||||
The preferred form for allocating a zeroed array is the following:
|
||||
|
||||
p = kcalloc(n, sizeof(...), ...);
|
||||
|
||||
Both forms check for overflow on the allocation size n * sizeof(...),
|
||||
and return NULL if that occurred.
|
||||
|
||||
|
||||
Chapter 15: The inline disease
|
||||
|
||||
|
||||
@@ -70,6 +70,8 @@ IOCTLS = \
|
||||
VIDIOC_SUBDEV_ENUM_MBUS_CODE \
|
||||
VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
|
||||
VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \
|
||||
VIDIOC_SUBDEV_G_SELECTION \
|
||||
VIDIOC_SUBDEV_S_SELECTION \
|
||||
|
||||
TYPES = \
|
||||
$(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/linux/videodev2.h) \
|
||||
@@ -193,7 +195,7 @@ DVB_DOCUMENTED = \
|
||||
#
|
||||
|
||||
install_media_images = \
|
||||
$(Q)cp $(OBJIMGFILES) $(MEDIA_OBJ_DIR)/media_api
|
||||
$(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
|
||||
|
||||
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
|
||||
$(Q)base64 -d $< >$@
|
||||
|
||||
@@ -531,6 +531,139 @@ typedef enum fe_delivery_system {
|
||||
here are referring to what can be found in the TMCC-structure -
|
||||
independent of the mode.</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-FIC-VER">
|
||||
<title><constant>DTV_ATSCMH_FIC_VER</constant></title>
|
||||
<para>Version number of the FIC (Fast Information Channel) signaling data.</para>
|
||||
<para>FIC is used for relaying information to allow rapid service acquisition by the receiver.</para>
|
||||
<para>Possible values: 0, 1, 2, 3, ..., 30, 31</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-PARADE-ID">
|
||||
<title><constant>DTV_ATSCMH_PARADE_ID</constant></title>
|
||||
<para>Parade identification number</para>
|
||||
<para>A parade is a collection of up to eight MH groups, conveying one or two ensembles.</para>
|
||||
<para>Possible values: 0, 1, 2, 3, ..., 126, 127</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-NOG">
|
||||
<title><constant>DTV_ATSCMH_NOG</constant></title>
|
||||
<para>Number of MH groups per MH subframe for a designated parade.</para>
|
||||
<para>Possible values: 1, 2, 3, 4, 5, 6, 7, 8</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-TNOG">
|
||||
<title><constant>DTV_ATSCMH_TNOG</constant></title>
|
||||
<para>Total number of MH groups including all MH groups belonging to all MH parades in one MH subframe.</para>
|
||||
<para>Possible values: 0, 1, 2, 3, ..., 30, 31</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SGN">
|
||||
<title><constant>DTV_ATSCMH_SGN</constant></title>
|
||||
<para>Start group number.</para>
|
||||
<para>Possible values: 0, 1, 2, 3, ..., 14, 15</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-PRC">
|
||||
<title><constant>DTV_ATSCMH_PRC</constant></title>
|
||||
<para>Parade repetition cycle.</para>
|
||||
<para>Possible values: 1, 2, 3, 4, 5, 6, 7, 8</para>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-FRAME-MODE">
|
||||
<title><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></title>
|
||||
<para>RS frame mode.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_frame_mode {
|
||||
ATSCMH_RSFRAME_PRI_ONLY = 0,
|
||||
ATSCMH_RSFRAME_PRI_SEC = 1,
|
||||
} atscmh_rs_frame_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-FRAME-ENSEMBLE">
|
||||
<title><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></title>
|
||||
<para>RS frame ensemble.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_frame_ensemble {
|
||||
ATSCMH_RSFRAME_ENS_PRI = 0,
|
||||
ATSCMH_RSFRAME_ENS_SEC = 1,
|
||||
} atscmh_rs_frame_ensemble_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-CODE-MODE-PRI">
|
||||
<title><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></title>
|
||||
<para>RS code mode (primary).</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_code_mode {
|
||||
ATSCMH_RSCODE_211_187 = 0,
|
||||
ATSCMH_RSCODE_223_187 = 1,
|
||||
ATSCMH_RSCODE_235_187 = 2,
|
||||
} atscmh_rs_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-RS-CODE-MODE-SEC">
|
||||
<title><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></title>
|
||||
<para>RS code mode (secondary).</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_rs_code_mode {
|
||||
ATSCMH_RSCODE_211_187 = 0,
|
||||
ATSCMH_RSCODE_223_187 = 1,
|
||||
ATSCMH_RSCODE_235_187 = 2,
|
||||
} atscmh_rs_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-BLOCK-MODE">
|
||||
<title><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Block Mode.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_block_mode {
|
||||
ATSCMH_SCCC_BLK_SEP = 0,
|
||||
ATSCMH_SCCC_BLK_COMB = 1,
|
||||
} atscmh_sccc_block_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-A">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Rate.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_code_mode {
|
||||
ATSCMH_SCCC_CODE_HLF = 0,
|
||||
ATSCMH_SCCC_CODE_QTR = 1,
|
||||
} atscmh_sccc_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-B">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Rate.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_code_mode {
|
||||
ATSCMH_SCCC_CODE_HLF = 0,
|
||||
ATSCMH_SCCC_CODE_QTR = 1,
|
||||
} atscmh_sccc_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-C">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Rate.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_code_mode {
|
||||
ATSCMH_SCCC_CODE_HLF = 0,
|
||||
ATSCMH_SCCC_CODE_QTR = 1,
|
||||
} atscmh_sccc_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-SCCC-CODE-MODE-D">
|
||||
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></title>
|
||||
<para>Series Concatenated Convolutional Code Rate.</para>
|
||||
<para>Possible values are:</para>
|
||||
<programlisting>
|
||||
typedef enum atscmh_sccc_code_mode {
|
||||
ATSCMH_SCCC_CODE_HLF = 0,
|
||||
ATSCMH_SCCC_CODE_QTR = 1,
|
||||
} atscmh_sccc_code_mode_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
<section id="DTV-API-VERSION">
|
||||
<title><constant>DTV_API_VERSION</constant></title>
|
||||
@@ -774,6 +907,33 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="atscmh-params">
|
||||
<title>ATSC-MH delivery system</title>
|
||||
<para>The following parameters are valid for ATSC-MH:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-FIC-VER"><constant>DTV_ATSCMH_FIC_VER</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-PARADE-ID"><constant>DTV_ATSCMH_PARADE_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-NOG"><constant>DTV_ATSCMH_NOG</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-TNOG"><constant>DTV_ATSCMH_TNOG</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SGN"><constant>DTV_ATSCMH_SGN</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-PRC"><constant>DTV_ATSCMH_PRC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-MODE"><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-ENSEMBLE"><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-PRI"><constant>DTV_ATSCMH_CODE_MODE_PRI</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-SEC"><constant>DTV_ATSCMH_CODE_MODE_SEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-BLOCK-MODE"><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-cable-systems">
|
||||
<title>Properties used on cable delivery systems</title>
|
||||
|
||||
@@ -197,4 +197,33 @@ in the frequency range from 87,5 to 108,0 MHz</title>
|
||||
<title>NTSC-4: United States RBDS Standard</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="iso12232">
|
||||
<abbrev>ISO 12232:2006</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>International Organization for Standardization
|
||||
(<ulink url="http://www.iso.org">http://www.iso.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>Photography — Digital still cameras — Determination
|
||||
of exposure index, ISO speed ratings, standard output sensitivity, and
|
||||
recommended exposure index</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="cea861">
|
||||
<abbrev>CEA-861-E</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Consumer Electronics Association
|
||||
(<ulink url="http://www.ce.org">http://www.ce.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>A DTV Profile for Uncompressed High Speed Digital Interfaces</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="vesadmt">
|
||||
<abbrev>VESA DMT</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Video Electronics Standards Association
|
||||
(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT)</title>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
||||
@@ -724,41 +724,49 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) {
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
</section>
|
||||
<section id="dv-timings">
|
||||
<title>Digital Video (DV) Timings</title>
|
||||
<para>
|
||||
The video standards discussed so far has been dealing with Analog TV and the
|
||||
The video standards discussed so far have been dealing with Analog TV and the
|
||||
corresponding video timings. Today there are many more different hardware interfaces
|
||||
such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry
|
||||
video signals and there is a need to extend the API to select the video timings
|
||||
for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to
|
||||
the limited bits available, a new set of IOCTLs is added to set/get video timings at
|
||||
the limited bits available, a new set of IOCTLs was added to set/get video timings at
|
||||
the input and output: </para><itemizedlist>
|
||||
<listitem>
|
||||
<para>DV Presets: Digital Video (DV) presets. These are IDs representing a
|
||||
<para>DV Timings: This will allow applications to define detailed
|
||||
video timings for the interface. This includes parameters such as width, height,
|
||||
polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename>
|
||||
header can be used to get the timings of the formats in the <xref linkend="cea861" /> and
|
||||
<xref linkend="vesadmt" /> standards.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>DV Presets: Digital Video (DV) presets (<emphasis role="bold">deprecated</emphasis>).
|
||||
These are IDs representing a
|
||||
video timing at the input/output. Presets are pre-defined timings implemented
|
||||
by the hardware according to video standards. A __u32 data type is used to represent
|
||||
a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions
|
||||
to support as many different presets as needed.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Custom DV Timings: This will allow applications to define more detailed
|
||||
custom video timings for the interface. This includes parameters such as width, height,
|
||||
polarities, frontporch, backporch etc.
|
||||
</para>
|
||||
to support as many different presets as needed. This API is deprecated in favor of the DV Timings
|
||||
API.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>To enumerate and query the attributes of the DV timings supported by a device,
|
||||
applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls.
|
||||
To set DV timings for the device, applications use the
|
||||
&VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
|
||||
&VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
|
||||
use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
|
||||
<para>To enumerate and query the attributes of DV presets supported by a device,
|
||||
applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset,
|
||||
applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the
|
||||
&VIDIOC-S-DV-PRESET; ioctl.</para>
|
||||
<para>To set custom DV timings for the device, applications use the
|
||||
&VIDIOC-S-DV-TIMINGS; ioctl and to get current custom DV timings they use the
|
||||
&VIDIOC-G-DV-TIMINGS; ioctl.</para>
|
||||
&VIDIOC-S-DV-PRESET; ioctl. To detect the preset as seen by the video receiver applications
|
||||
use the &VIDIOC-QUERY-DV-PRESET; ioctl.</para>
|
||||
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||
<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
|
||||
video timings for the device.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
&sub-controls;
|
||||
|
||||
@@ -2407,6 +2407,54 @@ details.</para>
|
||||
<para>Added <link linkend="jpeg-controls">JPEG compression control
|
||||
class</link>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Extended the DV Timings API:
|
||||
&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
|
||||
&VIDIOC-DV-TIMINGS-CAP;.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.5</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added integer menus, the new type will be
|
||||
V4L2_CTRL_TYPE_INTEGER_MENU.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added selection API for V4L2 subdev interface:
|
||||
&VIDIOC-SUBDEV-G-SELECTION; and
|
||||
&VIDIOC-SUBDEV-S-SELECTION;.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> Added <constant>V4L2_COLORFX_ANTIQUE</constant>,
|
||||
<constant>V4L2_COLORFX_ART_FREEZE</constant>,
|
||||
<constant>V4L2_COLORFX_AQUA</constant>,
|
||||
<constant>V4L2_COLORFX_SILHOUETTE</constant>,
|
||||
<constant>V4L2_COLORFX_SOLARIZATION</constant>,
|
||||
<constant>V4L2_COLORFX_VIVID</constant> and
|
||||
<constant>V4L2_COLORFX_ARBITRARY_CBCR</constant> menu items
|
||||
to the <constant>V4L2_CID_COLORFX</constant> control.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> Added <constant>V4L2_CID_COLORFX_CBCR</constant> control.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para> Added camera controls <constant>V4L2_CID_AUTO_EXPOSURE_BIAS</constant>,
|
||||
<constant>V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE</constant>,
|
||||
<constant>V4L2_CID_IMAGE_STABILIZATION</constant>,
|
||||
<constant>V4L2_CID_ISO_SENSITIVITY</constant>,
|
||||
<constant>V4L2_CID_ISO_SENSITIVITY_AUTO</constant>,
|
||||
<constant>V4L2_CID_EXPOSURE_METERING</constant>,
|
||||
<constant>V4L2_CID_SCENE_MODE</constant>,
|
||||
<constant>V4L2_CID_3A_LOCK</constant>,
|
||||
<constant>V4L2_CID_AUTO_FOCUS_START</constant>,
|
||||
<constant>V4L2_CID_AUTO_FOCUS_STOP</constant>,
|
||||
<constant>V4L2_CID_AUTO_FOCUS_STATUS</constant> and
|
||||
<constant>V4L2_CID_AUTO_FOCUS_RANGE</constant>.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
@@ -2505,6 +2553,10 @@ and may change in the future.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENCODER-CMD; and &VIDIOC-TRY-ENCODER-CMD;
|
||||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DECODER-CMD; and &VIDIOC-TRY-DECODER-CMD;
|
||||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@@ -2514,6 +2566,10 @@ ioctls.</para>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
|
||||
&VIDIOC-DV-TIMINGS-CAP; ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Flash API. <xref linkend="flash-controls" /></para>
|
||||
</listitem>
|
||||
@@ -2523,6 +2579,14 @@ ioctls.</para>
|
||||
<listitem>
|
||||
<para>Selection API. <xref linkend="selection-api" /></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
|
||||
and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link linkend="v4l2-auto-focus-area"><constant>
|
||||
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
@@ -2538,6 +2602,17 @@ interfaces and should not be implemented in new drivers.</para>
|
||||
<constant>VIDIOC_S_MPEGCOMP</constant> ioctls. Use Extended Controls,
|
||||
<xref linkend="extended-controls" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-G-DV-PRESET;, &VIDIOC-S-DV-PRESET;, &VIDIOC-ENUM-DV-PRESETS; and
|
||||
&VIDIOC-QUERY-DV-PRESET; ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><constant>VIDIOC_SUBDEV_G_CROP</constant> and
|
||||
<constant>VIDIOC_SUBDEV_S_CROP</constant> ioctls. Use
|
||||
<constant>VIDIOC_SUBDEV_G_SELECTION</constant> and
|
||||
<constant>VIDIOC_SUBDEV_S_SELECTION</constant>, <xref
|
||||
linkend="vidioc-subdev-g-selection" />.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -76,11 +76,12 @@
|
||||
<wordasword>format</wordasword> means the combination of media bus data
|
||||
format, frame width and frame height.</para></note>
|
||||
|
||||
<para>Image formats are typically negotiated on video capture and output
|
||||
devices using the <link linkend="crop">cropping and scaling</link> ioctls.
|
||||
The driver is responsible for configuring every block in the video pipeline
|
||||
according to the requested format at the pipeline input and/or
|
||||
output.</para>
|
||||
<para>Image formats are typically negotiated on video capture and
|
||||
output devices using the format and <link
|
||||
linkend="vidioc-subdev-g-selection">selection</link> ioctls. The
|
||||
driver is responsible for configuring every block in the video
|
||||
pipeline according to the requested format at the pipeline input
|
||||
and/or output.</para>
|
||||
|
||||
<para>For complex devices, such as often found in embedded systems,
|
||||
identical image sizes at the output of a pipeline can be achieved using
|
||||
@@ -276,11 +277,11 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Cropping and scaling</title>
|
||||
<title>Selections: cropping, scaling and composition</title>
|
||||
|
||||
<para>Many sub-devices support cropping frames on their input or output
|
||||
pads (or possible even on both). Cropping is used to select the area of
|
||||
interest in an image, typically on a video sensor or video decoder. It can
|
||||
interest in an image, typically on an image sensor or a video decoder. It can
|
||||
also be used as part of digital zoom implementations to select the area of
|
||||
the image that will be scaled up.</para>
|
||||
|
||||
@@ -288,26 +289,179 @@
|
||||
&v4l2-rect; by the coordinates of the top left corner and the rectangle
|
||||
size. Both the coordinates and sizes are expressed in pixels.</para>
|
||||
|
||||
<para>The crop rectangle is retrieved and set using the
|
||||
&VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad
|
||||
formats, drivers store try and active crop rectangles. The format
|
||||
negotiation mechanism applies to crop settings as well.</para>
|
||||
<para>As for pad formats, drivers store try and active
|
||||
rectangles for the selection targets of ACTUAL type <xref
|
||||
linkend="v4l2-subdev-selection-targets">.</xref></para>
|
||||
|
||||
<para>On input pads, cropping is applied relatively to the current pad
|
||||
format. The pad format represents the image size as received by the
|
||||
sub-device from the previous block in the pipeline, and the crop rectangle
|
||||
represents the sub-image that will be transmitted further inside the
|
||||
sub-device for processing. The crop rectangle be entirely containted
|
||||
inside the input image size.</para>
|
||||
<para>On sink pads, cropping is applied relative to the
|
||||
current pad format. The pad format represents the image size as
|
||||
received by the sub-device from the previous block in the
|
||||
pipeline, and the crop rectangle represents the sub-image that
|
||||
will be transmitted further inside the sub-device for
|
||||
processing.</para>
|
||||
|
||||
<para>Input crop rectangle are reset to their default value when the input
|
||||
image format is modified. Drivers should use the input image size as the
|
||||
crop rectangle default value, but hardware requirements may prevent this.
|
||||
</para>
|
||||
<para>The scaling operation changes the size of the image by
|
||||
scaling it to new dimensions. The scaling ratio isn't specified
|
||||
explicitly, but is implied from the original and scaled image
|
||||
sizes. Both sizes are represented by &v4l2-rect;.</para>
|
||||
|
||||
<para>Cropping behaviour on output pads is not defined.</para>
|
||||
<para>Scaling support is optional. When supported by a subdev,
|
||||
the crop rectangle on the subdev's sink pad is scaled to the
|
||||
size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL
|
||||
using <constant>V4L2_SUBDEV_SEL_COMPOSE_ACTUAL</constant>
|
||||
selection target on the same pad. If the subdev supports scaling
|
||||
but not composing, the top and left values are not used and must
|
||||
always be set to zero.</para>
|
||||
|
||||
<para>On source pads, cropping is similar to sink pads, with the
|
||||
exception that the source size from which the cropping is
|
||||
performed, is the COMPOSE rectangle on the sink pad. In both
|
||||
sink and source pads, the crop rectangle must be entirely
|
||||
contained inside the source image size for the crop
|
||||
operation.</para>
|
||||
|
||||
<para>The drivers should always use the closest possible
|
||||
rectangle the user requests on all selection targets, unless
|
||||
specifically told otherwise.
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant> and
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant> flags may be
|
||||
used to round the image size either up or down. <xref
|
||||
linkend="v4l2-subdev-selection-flags"></xref></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Types of selection targets</title>
|
||||
|
||||
<section>
|
||||
<title>ACTUAL targets</title>
|
||||
|
||||
<para>ACTUAL targets reflect the actual hardware configuration
|
||||
at any point of time. There is a BOUNDS target
|
||||
corresponding to every ACTUAL.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>BOUNDS targets</title>
|
||||
|
||||
<para>BOUNDS targets is the smallest rectangle that contains
|
||||
all valid ACTUAL rectangles. It may not be possible to set the
|
||||
ACTUAL rectangle as large as the BOUNDS rectangle, however.
|
||||
This may be because e.g. a sensor's pixel array is not
|
||||
rectangular but cross-shaped or round. The maximum size may
|
||||
also be smaller than the BOUNDS rectangle.</para>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Order of configuration and format propagation</title>
|
||||
|
||||
<para>Inside subdevs, the order of image processing steps will
|
||||
always be from the sink pad towards the source pad. This is also
|
||||
reflected in the order in which the configuration must be
|
||||
performed by the user: the changes made will be propagated to
|
||||
any subsequent stages. If this behaviour is not desired, the
|
||||
user must set
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag. This
|
||||
flag causes no propagation of the changes are allowed in any
|
||||
circumstances. This may also cause the accessed rectangle to be
|
||||
adjusted by the driver, depending on the properties of the
|
||||
underlying hardware.</para>
|
||||
|
||||
<para>The coordinates to a step always refer to the actual size
|
||||
of the previous step. The exception to this rule is the source
|
||||
compose rectangle, which refers to the sink compose bounds
|
||||
rectangle --- if it is supported by the hardware.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>Sink pad format. The user configures the sink pad
|
||||
format. This format defines the parameters of the image the
|
||||
entity receives through the pad for further processing.</listitem>
|
||||
|
||||
<listitem>Sink pad actual crop selection. The sink pad crop
|
||||
defines the crop performed to the sink pad format.</listitem>
|
||||
|
||||
<listitem>Sink pad actual compose selection. The size of the
|
||||
sink pad compose rectangle defines the scaling ratio compared
|
||||
to the size of the sink pad crop rectangle. The location of
|
||||
the compose rectangle specifies the location of the actual
|
||||
sink compose rectangle in the sink compose bounds
|
||||
rectangle.</listitem>
|
||||
|
||||
<listitem>Source pad actual crop selection. Crop on the source
|
||||
pad defines crop performed to the image in the sink compose
|
||||
bounds rectangle.</listitem>
|
||||
|
||||
<listitem>Source pad format. The source pad format defines the
|
||||
output pixel format of the subdev, as well as the other
|
||||
parameters with the exception of the image width and height.
|
||||
Width and height are defined by the size of the source pad
|
||||
actual crop selection.</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Accessing any of the above rectangles not supported by the
|
||||
subdev will return <constant>EINVAL</constant>. Any rectangle
|
||||
referring to a previous unsupported rectangle coordinates will
|
||||
instead refer to the previous supported rectangle. For example,
|
||||
if sink crop is not supported, the compose selection will refer
|
||||
to the sink pad format dimensions instead.</para>
|
||||
|
||||
<figure id="subdev-image-processing-crop">
|
||||
<title>Image processing in subdevs: simple crop example</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="subdev-image-processing-crop.svg"
|
||||
format="SVG" scale="200" />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>In the above example, the subdev supports cropping on its
|
||||
sink pad. To configure it, the user sets the media bus format on
|
||||
the subdev's sink pad. Now the actual crop rectangle can be set
|
||||
on the sink pad --- the location and size of this rectangle
|
||||
reflect the location and size of a rectangle to be cropped from
|
||||
the sink format. The size of the sink crop rectangle will also
|
||||
be the size of the format of the subdev's source pad.</para>
|
||||
|
||||
<figure id="subdev-image-processing-scaling-multi-source">
|
||||
<title>Image processing in subdevs: scaling with multiple sources</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="subdev-image-processing-scaling-multi-source.svg"
|
||||
format="SVG" scale="200" />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>In this example, the subdev is capable of first cropping,
|
||||
then scaling and finally cropping for two source pads
|
||||
individually from the resulting scaled image. The location of
|
||||
the scaled image in the cropped image is ignored in sink compose
|
||||
target. Both of the locations of the source crop rectangles
|
||||
refer to the sink scaling rectangle, independently cropping an
|
||||
area at location specified by the source crop rectangle from
|
||||
it.</para>
|
||||
|
||||
<figure id="subdev-image-processing-full">
|
||||
<title>Image processing in subdevs: scaling and composition
|
||||
with multiple sinks and sources</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="subdev-image-processing-full.svg"
|
||||
format="SVG" scale="200" />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>The subdev driver supports two sink pads and two source
|
||||
pads. The images from both of the sink pads are individually
|
||||
cropped, then scaled and further composed on the composition
|
||||
bounds rectangle. From that, two independent streams are cropped
|
||||
and sent out of the subdev from the source pads.</para>
|
||||
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
&sub-subdev-formats;
|
||||
|
||||
@@ -543,12 +543,13 @@ and can range from zero to the number of buffers allocated
|
||||
with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-buf-type;</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Type of the buffer, same as &v4l2-format;
|
||||
<structfield>type</structfield> or &v4l2-requestbuffers;
|
||||
<structfield>type</structfield>, set by the application.</entry>
|
||||
<structfield>type</structfield>, set by the application. See <xref
|
||||
linkend="v4l2-buf-type" /></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -568,7 +569,7 @@ refers to an input stream, applications when an output stream.</entry>
|
||||
linkend="buffer-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-field;</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>field</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Indicates the field order of the image in the
|
||||
@@ -630,11 +631,12 @@ bandwidth. These devices identify by not enumerating any video
|
||||
standards, see <xref linkend="standard" />.</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-memory;</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>memory</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>This field must be set by applications and/or drivers
|
||||
in accordance with the selected I/O method.</entry>
|
||||
in accordance with the selected I/O method. See <xref linkend="v4l2-memory"
|
||||
/></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
<refentry>
|
||||
<refentry id="pixfmt-srggb10">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_SRGGB10 ('RG10'),
|
||||
V4L2_PIX_FMT_SGRBG10 ('BA10'),
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
<refentry id="pixfmt-srggb10dpcm8">
|
||||
<refmeta>
|
||||
<refentrytitle>
|
||||
V4L2_PIX_FMT_SBGGR10DPCM8 ('bBA8'),
|
||||
V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
|
||||
V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
|
||||
V4L2_PIX_FMT_SRGGB10DPCM8 ('bRA8'),
|
||||
</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-SBGGR10DPCM8"><constant>V4L2_PIX_FMT_SBGGR10DPCM8</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGBRG10DPCM8"><constant>V4L2_PIX_FMT_SGBRG10DPCM8</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGRBG10DPCM8"><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SRGGB10DPCM8"><constant>V4L2_PIX_FMT_SRGGB10DPCM8</constant></refname>
|
||||
<refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>The following four pixel formats are raw sRGB / Bayer formats
|
||||
with 10 bits per colour compressed to 8 bits each, using DPCM
|
||||
compression. DPCM, differential pulse-code modulation, is lossy.
|
||||
Each colour component consumes 8 bits of memory. In other respects
|
||||
this format is similar to <xref
|
||||
linkend="pixfmt-srggb10">.</xref></para>
|
||||
|
||||
</refsect1>
|
||||
</refentry>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user