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 branch 'for-3.10/hid-driver-transport-cleanups' into for-3.10/mt-hybrid-finger-pen
This commit is contained in:
@@ -299,6 +299,8 @@ memory-hotplug.txt
|
||||
- Hotpluggable memory support, how to use and current status.
|
||||
memory.txt
|
||||
- info on typical Linux memory problems.
|
||||
metag/
|
||||
- directory with info about Linux on Meta architecture.
|
||||
mips/
|
||||
- directory with info about Linux on MIPS architecture.
|
||||
misc-devices/
|
||||
|
||||
@@ -1,14 +1,53 @@
|
||||
What: /sys/bus/fcoe/ctlr_X
|
||||
What: /sys/bus/fcoe/
|
||||
Date: August 2012
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
Description: The FCoE bus. Attributes in this directory are control interfaces.
|
||||
Attributes:
|
||||
|
||||
ctlr_create: 'FCoE Controller' instance creation interface. Writing an
|
||||
<ifname> to this file will allocate and populate sysfs with a
|
||||
fcoe_ctlr_device (ctlr_X). The user can then configure any
|
||||
per-port settings and finally write to the fcoe_ctlr_device's
|
||||
'start' attribute to begin the kernel's discovery and login
|
||||
process.
|
||||
|
||||
ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
|
||||
fcoe_ctlr_device's sysfs name to this file will log the
|
||||
fcoe_ctlr_device out of the fabric or otherwise connected
|
||||
FCoE devices. It will also free all kernel memory allocated
|
||||
for this fcoe_ctlr_device and any structures associated
|
||||
with it, this includes the scsi_host.
|
||||
|
||||
What: /sys/bus/fcoe/devices/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
|
||||
Description: 'FCoE Controller' instances on the fcoe bus.
|
||||
The FCoE Controller now has a three stage creation process.
|
||||
1) Write interface name to ctlr_create 2) Configure the FCoE
|
||||
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
|
||||
discovery and login. The FCoE Controller is destroyed by
|
||||
writing it's name, i.e. ctlr_X to the ctlr_delete file.
|
||||
|
||||
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.
|
||||
|
||||
mode: Display or change the FCoE Controller's mode. Possible
|
||||
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
|
||||
is started in 'Fabric' mode then FIP FCF discovery is
|
||||
initiated and ultimately a fabric login is attempted.
|
||||
If a FCoE Controller is started in 'VN2VN' mode then
|
||||
FIP VN2VN discovery and login is performed. A FCoE
|
||||
Controller only supports one mode at a time.
|
||||
|
||||
enabled: Whether an FCoE controller is enabled or disabled.
|
||||
0 if disabled, 1 if enabled. Writing either 0 or 1
|
||||
to this file will enable or disable the FCoE controller.
|
||||
|
||||
lesb/link_fail: Link Error Status Block (LESB) link failure count.
|
||||
|
||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
@@ -26,7 +65,7 @@ Attributes:
|
||||
|
||||
Notes: ctlr_X (global increment starting at 0)
|
||||
|
||||
What: /sys/bus/fcoe/fcf_X
|
||||
What: /sys/bus/fcoe/devices/fcf_X
|
||||
Date: March 2012
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
What: /sys/kernel/mm/ksm
|
||||
Date: September 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Interface for Kernel Samepage Merging (KSM)
|
||||
|
||||
What: /sys/kernel/mm/ksm/full_scans
|
||||
What: /sys/kernel/mm/ksm/pages_shared
|
||||
What: /sys/kernel/mm/ksm/pages_sharing
|
||||
What: /sys/kernel/mm/ksm/pages_to_scan
|
||||
What: /sys/kernel/mm/ksm/pages_unshared
|
||||
What: /sys/kernel/mm/ksm/pages_volatile
|
||||
What: /sys/kernel/mm/ksm/run
|
||||
What: /sys/kernel/mm/ksm/sleep_millisecs
|
||||
Date: September 2009
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Kernel Samepage Merging daemon sysfs interface
|
||||
|
||||
full_scans: how many times all mergeable areas have been
|
||||
scanned.
|
||||
|
||||
pages_shared: how many shared pages are being used.
|
||||
|
||||
pages_sharing: how many more sites are sharing them i.e. how
|
||||
much saved.
|
||||
|
||||
pages_to_scan: how many present pages to scan before ksmd goes
|
||||
to sleep.
|
||||
|
||||
pages_unshared: how many pages unique but repeatedly checked
|
||||
for merging.
|
||||
|
||||
pages_volatile: how many pages changing too fast to be placed
|
||||
in a tree.
|
||||
|
||||
run: write 0 to disable ksm, read 0 while ksm is disabled.
|
||||
write 1 to run ksm, read 1 while ksm is running.
|
||||
write 2 to disable ksm and unmerge all its pages.
|
||||
|
||||
sleep_millisecs: how many milliseconds ksm should sleep between
|
||||
scans.
|
||||
|
||||
See Documentation/vm/ksm.txt for more information.
|
||||
|
||||
What: /sys/kernel/mm/ksm/merge_across_nodes
|
||||
Date: January 2013
|
||||
KernelVersion: 3.9
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Control merging pages across different NUMA nodes.
|
||||
|
||||
When it is set to 0 only pages from the same node are merged,
|
||||
otherwise pages from all nodes can be merged together (default).
|
||||
@@ -0,0 +1,83 @@
|
||||
What: /sys/devices/platform/msi-laptop-pf/lcd_level
|
||||
Date: Oct 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
|
||||
Description:
|
||||
Screen brightness: contains a single integer in the range 0..8.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/auto_brightness
|
||||
Date: Oct 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
|
||||
Description:
|
||||
Enable automatic brightness control: contains either 0 or 1. If
|
||||
set to 1 the hardware adjusts the screen brightness
|
||||
automatically when the power cord is plugged/unplugged.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/wlan
|
||||
Date: Oct 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
|
||||
Description:
|
||||
WLAN subsystem enabled: contains either 0 or 1.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/bluetooth
|
||||
Date: Oct 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
|
||||
Description:
|
||||
Bluetooth subsystem enabled: contains either 0 or 1. Please
|
||||
note that this file is constantly 0 if no Bluetooth hardware is
|
||||
available.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/touchpad
|
||||
Date: Nov 2012
|
||||
KernelVersion: 3.8
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if touchpad is turned on.
|
||||
Touchpad state can only be toggled by pressing Fn+F3.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/turbo_mode
|
||||
Date: Nov 2012
|
||||
KernelVersion: 3.8
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if turbo mode is turned
|
||||
on. In turbo mode power LED is orange and processor is
|
||||
overclocked. Turbo mode is available only if charging. It is
|
||||
only possible to toggle turbo mode state by pressing Fn+F10,
|
||||
and there is a few seconds cooldown between subsequent toggles.
|
||||
If user presses Fn+F10 too frequent, turbo mode state is not
|
||||
changed.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/eco_mode
|
||||
Date: Nov 2012
|
||||
KernelVersion: 3.8
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if ECO mode is turned on.
|
||||
In ECO mode power LED is green and userspace should do some
|
||||
powersaving actions. ECO mode is available only on battery
|
||||
power. ECO mode can only be toggled by pressing Fn+F10.
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown
|
||||
Date: Nov 2012
|
||||
KernelVersion: 3.8
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Contains value in range 0..3:
|
||||
* 0 -> Turbo mode is off
|
||||
* 1 -> Turbo mode is on, cannot be turned off yet
|
||||
* 2 -> Turbo mode is off, cannot be turned on yet
|
||||
* 3 -> Turbo mode is on
|
||||
|
||||
What: /sys/devices/platform/msi-laptop-pf/auto_fan
|
||||
Date: Nov 2012
|
||||
KernelVersion: 3.8
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if fan speed is controlled
|
||||
automatically (1) or fan runs at maximal speed (0). Can be
|
||||
toggled in software.
|
||||
|
||||
@@ -488,9 +488,10 @@ will invoke the generic mapping error check interface. Doing so will ensure
|
||||
that the mapping code will work correctly on all dma implementations without
|
||||
any dependency on the specifics of the underlying implementation. Using the
|
||||
returned address without checking for errors could result in failures ranging
|
||||
from panics to silent data corruption. Couple of example of incorrect ways to
|
||||
check for errors that make assumptions about the underlying dma implementation
|
||||
are as follows and these are applicable to dma_map_page() as well.
|
||||
from panics to silent data corruption. A couple of examples of incorrect ways
|
||||
to check for errors that make assumptions about the underlying dma
|
||||
implementation are as follows and these are applicable to dma_map_page() as
|
||||
well.
|
||||
|
||||
Incorrect example 1:
|
||||
dma_addr_t dma_handle;
|
||||
@@ -751,7 +752,7 @@ Example 1:
|
||||
dma_unmap_single(dma_handle1);
|
||||
map_error_handling1:
|
||||
|
||||
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
|
||||
Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
|
||||
mapping error is detected in the middle)
|
||||
|
||||
dma_addr_t dma_addr;
|
||||
|
||||
@@ -743,6 +743,10 @@ char *date;</synopsis>
|
||||
These two operations are mandatory for GEM drivers that support DRM
|
||||
PRIME.
|
||||
</para>
|
||||
<sect4>
|
||||
<title>DRM PRIME Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
|
||||
</sect4>
|
||||
</sect3>
|
||||
<sect3 id="drm-gem-objects-mapping">
|
||||
<title>GEM Objects Mapping</title>
|
||||
@@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
|
||||
If the parameters are deemed valid, drivers then create, initialize and
|
||||
return an instance of struct <structname>drm_framebuffer</structname>.
|
||||
If desired the instance can be embedded in a larger driver-specific
|
||||
structure. The new instance is initialized with a call to
|
||||
<function>drm_framebuffer_init</function> which takes a pointer to DRM
|
||||
frame buffer operations (struct
|
||||
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
|
||||
structure. Drivers must fill its <structfield>width</structfield>,
|
||||
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
||||
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
||||
<structfield>bits_per_pixel</structfield> and
|
||||
<structfield>pixel_format</structfield> fields from the values passed
|
||||
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
|
||||
should call the <function>drm_helper_mode_fill_fb_struct</function>
|
||||
helper function to do so.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The initailization of the new framebuffer instance is finalized with a
|
||||
call to <function>drm_framebuffer_init</function> which takes a pointer
|
||||
to DRM frame buffer operations (struct
|
||||
<structname>drm_framebuffer_funcs</structname>). Note that this function
|
||||
publishes the framebuffer and so from this point on it can be accessed
|
||||
concurrently from other threads. Hence it must be the last step in the
|
||||
driver's framebuffer initialization sequence. Frame buffer operations
|
||||
are
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
|
||||
@@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
After initializing the <structname>drm_framebuffer</structname>
|
||||
instance drivers must fill its <structfield>width</structfield>,
|
||||
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
||||
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
||||
<structfield>bits_per_pixel</structfield> and
|
||||
<structfield>pixel_format</structfield> fields from the values passed
|
||||
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
|
||||
should call the <function>drm_helper_mode_fill_fb_struct</function>
|
||||
helper function to do so.
|
||||
</para>
|
||||
The lifetime of a drm framebuffer is controlled with a reference count,
|
||||
drivers can grab additional references with
|
||||
<function>drm_framebuffer_reference</function> </para> and drop them
|
||||
again with <function>drm_framebuffer_unreference</function>. For
|
||||
driver-private framebuffers for which the last reference is never
|
||||
dropped (e.g. for the fbdev framebuffer when the struct
|
||||
<structname>drm_framebuffer</structname> is embedded into the fbdev
|
||||
helper struct) drivers can manually clean up a framebuffer at module
|
||||
unload time with
|
||||
<function>drm_framebuffer_unregister_private</function>.
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Output Polling</title>
|
||||
@@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
|
||||
operation.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Locking</title>
|
||||
<para>
|
||||
Beside some lookup structures with their own locking (which is hidden
|
||||
behind the interface functions) most of the modeset state is protected
|
||||
by the <code>dev-<mode_config.lock</code> mutex and additionally
|
||||
per-crtc locks to allow cursor updates, pageflips and similar operations
|
||||
to occur concurrently with background tasks like output detection.
|
||||
Operations which cross domains like a full modeset always grab all
|
||||
locks. Drivers there need to protect resources shared between crtcs with
|
||||
additional locking. They also need to be careful to always grab the
|
||||
relevant crtc locks if a modset functions touches crtc state, e.g. for
|
||||
load detection (which does only grab the <code>mode_config.lock</code>
|
||||
to allow concurrent screen updates on live crtcs).
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: kms initialization and cleanup -->
|
||||
@@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
|
||||
without waiting for rendering or page flip to complete and must block
|
||||
any new rendering to the frame buffer until the page flip completes.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip can be successfully scheduled the driver must set the
|
||||
<code>drm_crtc-<fb</code> field to the new framebuffer pointed to
|
||||
by <code>fb</code>. This is important so that the reference counting
|
||||
on framebuffers stays balanced.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip is already pending, the
|
||||
<methodname>page_flip</methodname> operation must return
|
||||
@@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev)
|
||||
make its properties available to applications.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>KMS API Functions</title>
|
||||
!Edrivers/gpu/drm/drm_crtc.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: kms helper functions -->
|
||||
@@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||
<title>fbdev Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
||||
!Edrivers/gpu/drm/drm_fb_helper.c
|
||||
!Iinclude/drm/drm_fb_helper.h
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display Port Helper Functions Reference</title>
|
||||
@@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
|
||||
!Iinclude/drm/drm_dp_helper.h
|
||||
!Edrivers/gpu/drm/drm_dp_helper.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>EDID Helper Functions Reference</title>
|
||||
!Edrivers/gpu/drm/drm_edid.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: vertical blanking -->
|
||||
|
||||
@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
||||
|
||||
|
||||
<title>LINUX DVB API</title>
|
||||
<subtitle>Version 5.8</subtitle>
|
||||
<subtitle>Version 5.10</subtitle>
|
||||
<!-- ADD THE CHAPTERS HERE -->
|
||||
<chapter id="dvb_introdution">
|
||||
&sub-intro;
|
||||
|
||||
@@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
|
||||
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
|
||||
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
|
||||
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
|
||||
<section id="dtv-stats">
|
||||
<title>DTV stats type</title>
|
||||
<programlisting>
|
||||
struct dtv_stats {
|
||||
__u8 scale; /* enum fecap_scale_params type */
|
||||
union {
|
||||
__u64 uvalue; /* for counters and relative scales */
|
||||
__s64 svalue; /* for 1/1000 dB measures */
|
||||
};
|
||||
} __packed;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="dtv-fe-stats">
|
||||
<title>DTV stats type</title>
|
||||
<programlisting>
|
||||
#define MAX_DTV_STATS 4
|
||||
|
||||
struct dtv_fe_stats {
|
||||
__u8 len;
|
||||
struct dtv_stats stat[MAX_DTV_STATS];
|
||||
} __packed;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="dtv-property">
|
||||
<title>DTV property type</title>
|
||||
<programlisting>
|
||||
/* Reserved fields should be set to 0 */
|
||||
|
||||
struct dtv_property {
|
||||
__u32 cmd;
|
||||
__u32 reserved[3];
|
||||
union {
|
||||
__u32 data;
|
||||
struct dtv_fe_stats st;
|
||||
struct {
|
||||
__u8 data[32];
|
||||
__u32 len;
|
||||
@@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
|
||||
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
||||
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
||||
ISDB-T hierarchical layers can be decoded simultaneously. For that
|
||||
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
|
||||
reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
|
||||
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
|
||||
available segments. The total number of segments over all layers has
|
||||
to 13 in ISDB-T.</para>
|
||||
@@ -850,6 +877,147 @@ enum fe_interleaving {
|
||||
<para>use the special macro LNA_AUTO to set LNA auto</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="frontend-stat-properties">
|
||||
<title>Frontend statistics indicators</title>
|
||||
<para>The values are returned via <constant>dtv_property.stat</constant>.
|
||||
If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
|
||||
<para>For most delivery systems, <constant>dtv_property.stat.len</constant>
|
||||
will be 1 if the stats is supported, and the properties will
|
||||
return a single value for each parameter.</para>
|
||||
<para>It should be noticed, however, that new OFDM delivery systems
|
||||
like ISDB can use different modulation types for each group of
|
||||
carriers. On such standards, up to 3 groups of statistics can be
|
||||
provided, and <constant>dtv_property.stat.len</constant> is updated
|
||||
to reflect the "global" metrics, plus one metric per each carrier
|
||||
group (called "layer" on ISDB).</para>
|
||||
<para>So, in order to be consistent with other delivery systems, the first
|
||||
value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
|
||||
array refers to the global metric. The other elements of the array
|
||||
represent each layer, starting from layer A(index 1),
|
||||
layer B (index 2) and so on.</para>
|
||||
<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
|
||||
<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
|
||||
<constant>svalue</constant> is for signed values of the measure (dB measures)
|
||||
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
|
||||
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
|
||||
<section id = "fecap-scale-params">
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section id="DTV-STAT-SIGNAL-STRENGTH">
|
||||
<title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
|
||||
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
|
||||
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-CNR">
|
||||
<title><constant>DTV_STAT_CNR</constant></title>
|
||||
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
|
||||
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
|
||||
<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
|
||||
<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
|
||||
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
|
||||
<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
|
||||
<para>Measures the amount of bits received before the inner code block, during the same period as
|
||||
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
|
||||
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
|
||||
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
|
||||
<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
|
||||
<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
|
||||
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
|
||||
<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
|
||||
<para>Measures the amount of bits received after the inner coding, during the same period as
|
||||
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
|
||||
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
|
||||
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
|
||||
<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
|
||||
<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
|
||||
<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
|
||||
<para>Measures the total number of blocks received during the same period as
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It can be used to calculate the PER indicator, by dividing
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
|
||||
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="frontend-property-terrestrial-systems">
|
||||
<title>Properties used on terrestrial delivery systems</title>
|
||||
<section id="dvbt-params">
|
||||
@@ -871,6 +1039,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dvbt2-params">
|
||||
<title>DVB-T2 delivery system</title>
|
||||
@@ -895,6 +1064,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="isdbt">
|
||||
<title>ISDB-T delivery system</title>
|
||||
@@ -948,6 +1118,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="atsc-params">
|
||||
<title>ATSC delivery system</title>
|
||||
@@ -961,6 +1132,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="atscmh-params">
|
||||
<title>ATSC-MH delivery system</title>
|
||||
@@ -988,6 +1160,7 @@ enum fe_interleaving {
|
||||
<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>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dtmb-params">
|
||||
<title>DTMB delivery system</title>
|
||||
@@ -1007,6 +1180,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-cable-systems">
|
||||
@@ -1028,6 +1202,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dvbc-annex-b-params">
|
||||
<title>DVB-C Annex B delivery system</title>
|
||||
@@ -1043,6 +1218,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-satellital-systems">
|
||||
@@ -1062,6 +1238,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
<para>Future implementations might add those two missing parameters:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
|
||||
@@ -1077,6 +1254,7 @@ enum fe_interleaving {
|
||||
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="turbo-params">
|
||||
<title>Turbo code delivery system</title>
|
||||
|
||||
@@ -230,7 +230,7 @@ typedef enum fe_status {
|
||||
<entry align="char">The frontend has found a DVB signal</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_VITERBI</entry>
|
||||
<entry align="char">The frontend FEC code is stable</entry>
|
||||
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_SYNC</entry>
|
||||
<entry align="char">Syncronization bytes was found</entry>
|
||||
|
||||
@@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
|
||||
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
||||
are available for the device.</para>
|
||||
&ENOTTY;.
|
||||
|
||||
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
||||
even USB cameras follow some well known video standard. It might have
|
||||
been better to explicitly indicate elsewhere if a device cannot live
|
||||
|
||||
@@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.9</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added timestamp types to
|
||||
<structfield>flags</structfield> field in
|
||||
<structname>v4l2_buffer</structname>. See <xref
|
||||
linkend="buffer-flags" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
|
||||
changes flag. See <xref linkend="changes-flags"/>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
||||
@@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
|
||||
<entry>boolean</entry>
|
||||
<entry>Mirror the picture vertically.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Horizontal image centering. This control is
|
||||
deprecated. New drivers and applications should use the <link
|
||||
linkend="camera-controls">Camera class controls</link>
|
||||
<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
|
||||
<constant>V4L2_CID_PAN_RELATIVE</constant> and
|
||||
<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
|
||||
(formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Vertical image centering. Centering is intended to
|
||||
<emphasis>physically</emphasis> adjust cameras. For image cropping see
|
||||
<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
|
||||
control is deprecated. New drivers and applications should use the
|
||||
<link linkend="camera-controls">Camera class controls</link>
|
||||
<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
|
||||
<constant>V4L2_CID_TILT_RELATIVE</constant> and
|
||||
<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
|
||||
</row>
|
||||
<row id="v4l2-power-line-frequency">
|
||||
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
||||
<entry>enum</entry>
|
||||
|
||||
@@ -477,7 +477,7 @@ rest should be evident.</para>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental"> experimental </link>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
@@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a
|
||||
different or the same device (known as the importer role), or both. This
|
||||
section describes the DMABUF importer role API in V4L2.</para>
|
||||
|
||||
<para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
|
||||
<para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
|
||||
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
|
||||
|
||||
<para>Input and output devices support the streaming I/O method when the
|
||||
@@ -741,17 +741,19 @@ applications when an output stream.</entry>
|
||||
<entry>struct timeval</entry>
|
||||
<entry><structfield>timestamp</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry><para>For input streams this is the
|
||||
system time (as returned by the <function>gettimeofday()</function>
|
||||
function) when the first data byte was captured. For output streams
|
||||
the data will not be displayed before this time, secondary to the
|
||||
nominal frame rate determined by the current video standard in
|
||||
enqueued order. Applications can for example zero this field to
|
||||
display frames as soon as possible. The driver stores the time at
|
||||
which the first data byte was actually sent out in the
|
||||
<structfield>timestamp</structfield> field. This permits
|
||||
applications to monitor the drift between the video and system
|
||||
clock.</para></entry>
|
||||
<entry><para>For input streams this is time when the first data
|
||||
byte was captured, as returned by the
|
||||
<function>clock_gettime()</function> function for the relevant
|
||||
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
|
||||
<xref linkend="buffer-flags" />. For output streams the data
|
||||
will not be displayed before this time, secondary to the nominal
|
||||
frame rate determined by the current video standard in enqueued
|
||||
order. Applications can for example zero this field to display
|
||||
frames as soon as possible. The driver stores the time at which
|
||||
the first data byte was actually sent out in the
|
||||
<structfield>timestamp</structfield> field. This permits
|
||||
applications to monitor the drift between the video and system
|
||||
clock.</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-timecode;</entry>
|
||||
@@ -903,7 +905,7 @@ should set this to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__unsigned long</entry>
|
||||
<entry>unsigned long</entry>
|
||||
<entry><structfield>userptr</structfield></entry>
|
||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
|
||||
@@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data
|
||||
in this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||
in which case caches have not been used.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
|
||||
<entry>0xe000</entry>
|
||||
<entry>Mask for timestamp types below. To test the
|
||||
timestamp type, mask out bits not belonging to timestamp
|
||||
type by performing a logical and operation with buffer
|
||||
flags and timestamp mask.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
|
||||
<entry>0x0000</entry>
|
||||
<entry>Unknown timestamp type. This type is used by
|
||||
drivers before Linux 3.9 and may be either monotonic (see
|
||||
below) or realtime (wall clock). Monotonic clock has been
|
||||
favoured in embedded systems whereas most of the drivers
|
||||
use the realtime clock. Either kinds of timestamps are
|
||||
available in user space via
|
||||
<function>clock_gettime(2)</function> using clock IDs
|
||||
<constant>CLOCK_MONOTONIC</constant> and
|
||||
<constant>CLOCK_REALTIME</constant>, respectively.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
|
||||
<entry>0x2000</entry>
|
||||
<entry>The buffer timestamp has been taken from the
|
||||
<constant>CLOCK_MONOTONIC</constant> clock. To access the
|
||||
same clock outside V4L2, use
|
||||
<function>clock_gettime(2)</function> .</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
|
||||
non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>
|
||||
V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
|
||||
V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
|
||||
V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
|
||||
V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
|
||||
</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
|
||||
<constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
|
||||
</refname>
|
||||
<refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
|
||||
<constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
|
||||
</refname>
|
||||
<refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
|
||||
<constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
|
||||
</refname>
|
||||
<refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
|
||||
<constant>V4L2_PIX_FMT_SRGGB10ALAW8</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 color compressed to 8 bits each,
|
||||
using the A-LAW algorithm. Each color component consumes 8
|
||||
bits of memory. In other respects this format is similar to
|
||||
<xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -0,0 +1,62 @@
|
||||
<refentry id="V4L2-PIX-FMT-UV8">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
|
||||
<refpurpose>UV plane interleaved</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>In this format there is no Y plane, Only CbCr plane. ie
|
||||
(UV interleaved)</para>
|
||||
<example>
|
||||
<title>
|
||||
<constant>V4L2_PIX_FMT_UV8</constant>
|
||||
pixel image
|
||||
</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 4:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
<entry>Cb<subscript>20</subscript></entry>
|
||||
<entry>Cr<subscript>20</subscript></entry>
|
||||
<entry>Cb<subscript>21</subscript></entry>
|
||||
<entry>Cr<subscript>21</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 12:</entry>
|
||||
<entry>Cb<subscript>30</subscript></entry>
|
||||
<entry>Cr<subscript>30</subscript></entry>
|
||||
<entry>Cb<subscript>31</subscript></entry>
|
||||
<entry>Cr<subscript>31</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
||||
&sub-srggb8;
|
||||
&sub-sbggr16;
|
||||
&sub-srggb10;
|
||||
&sub-srggb10alaw8;
|
||||
&sub-srggb10dpcm8;
|
||||
&sub-srggb12;
|
||||
</section>
|
||||
@@ -701,6 +702,7 @@ information.</para>
|
||||
&sub-y12;
|
||||
&sub-y10b;
|
||||
&sub-y16;
|
||||
&sub-uv8;
|
||||
&sub-yuyv;
|
||||
&sub-uyvy;
|
||||
&sub-yvyu;
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -139,6 +139,16 @@ structs, ioctls) must be noted in more detail in the history chapter
|
||||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.9</revnumber>
|
||||
<date>2012-12-03</date>
|
||||
<authorinitials>sa, sn</authorinitials>
|
||||
<revremark>Added timestamp types to v4l2_buffer.
|
||||
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
|
||||
event changes flag, see <xref linkend="changes-flags"/>.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.6</revnumber>
|
||||
<date>2012-07-02</date>
|
||||
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.6</subtitle>
|
||||
<subtitle>Revision 3.9</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
||||
@@ -261,6 +261,12 @@
|
||||
<entry>This control event was triggered because the control flags
|
||||
changed.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
|
||||
<entry>0x0004</entry>
|
||||
<entry>This control event was triggered because the minimum,
|
||||
maximum, step or the default value of the control changed.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user