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 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (57 commits) [media] as3645a: Fix compilation by including slab.h [media] s5p-fimc: Remove linux/version.h include from fimc-mdevice.c [media] s5p-mfc: Remove linux/version.h include from s5p_mfc.c [media] ds3000: using logical && instead of bitwise & [media] v4l2-ctrls: make control names consistent [media] DVB: dib0700, add support for Nova-TD LEDs [media] DVB: dib0700, add corrected Nova-TD frontend_attach [media] DVB: dib0700, separate stk7070pd initialization [media] DVB: dib0700, move Nova-TD Stick to a separate set [media] : add MODULE_FIRMWARE to dib0700 [media] DVB-CORE: remove superfluous DTV_CMDs [media] s5p-jpeg: adapt to recent videobuf2 changes [media] s5p-g2d: fixed a bug in controls setting function [media] s5p-mfc: Fix volatile controls setup [media] drivers/media/video/s5p-mfc/s5p_mfc.c: adjust double test [media] drivers/media/video/s5p-fimc/fimc-capture.c: adjust double test [media] s5p-fimc: Fix incorrect control ID assignment [media] dvb_frontend: Don't call get_frontend() if idle [media] DocBook/dvbproperty.xml: Remove DTV_MODULATION from ISDB-T [media] DocBook/dvbproperty.xml: Fix ISDB-T delivery system parameters ...
This commit is contained in:
Linus Torvalds
@@ -163,14 +163,16 @@ get/set up to 64 properties. The actual meaning of each property is described on
|
||||
<section id="DTV-FREQUENCY">
|
||||
<title><constant>DTV_FREQUENCY</constant></title>
|
||||
|
||||
<para>Central frequency of the channel, in HZ.</para>
|
||||
<para>Central frequency of the channel.</para>
|
||||
|
||||
<para>Notes:</para>
|
||||
<para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
|
||||
<para>1)For satellital delivery systems, it is measured in kHz.
|
||||
For the other ones, it is measured in Hz.</para>
|
||||
<para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
|
||||
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
|
||||
the channel which is 6MHz.</para>
|
||||
|
||||
<para>2)As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
<para>3)As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
|
||||
central frequency of the channel is expected.</para>
|
||||
</section>
|
||||
@@ -735,14 +737,10 @@ typedef enum fe_hierarchy {
|
||||
<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-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CODE-RATE-HP"><constant>DTV_CODE_RATE_HP</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CODE-RATE-LP"><constant>DTV_CODE_RATE_LP</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-LAYER-ENABLED"><constant>DTV_ISDBT_LAYER_ENABLED</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-PARTIAL-RECEPTION"><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-SOUND-BROADCASTING"><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></link></para></listitem>
|
||||
|
||||
@@ -183,7 +183,12 @@ applications must set the array to zero.</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>ctrl_class</structfield></entry>
|
||||
<entry>The control class to which all controls belong, see
|
||||
<xref linkend="ctrl-class" />.</entry>
|
||||
<xref linkend="ctrl-class" />. Drivers that use a kernel framework for handling
|
||||
controls will also accept a value of 0 here, meaning that the controls can
|
||||
belong to any control class. Whether drivers support this can be tested by setting
|
||||
<structfield>ctrl_class</structfield> to 0 and calling <constant>VIDIOC_TRY_EXT_CTRLS</constant>
|
||||
with a <structfield>count</structfield> of 0. If that succeeds, then the driver
|
||||
supports this feature.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -194,10 +199,13 @@ also be zero.</entry>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>error_idx</structfield></entry>
|
||||
<entry>Set by the driver in case of an error. It is the
|
||||
index of the control causing the error or equal to 'count' when the
|
||||
error is not associated with a particular control. Undefined when the
|
||||
ioctl returns 0 (success).</entry>
|
||||
<entry>Set by the driver in case of an error. If it is equal
|
||||
to <structfield>count</structfield>, then no actual changes were made to
|
||||
controls. In other words, the error was not associated with setting a particular
|
||||
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
|
||||
were modified and control <structfield>error_idx</structfield> is the one that
|
||||
caused the error. The <structfield>error_idx</structfield> value is undefined
|
||||
if the ioctl returned 0 (success).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -364,15 +364,20 @@ capability and it is cleared otherwise.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_FLAG_OVERLAY</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>The frame buffer is an overlay surface the same
|
||||
size as the capture. [?]</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="hspan">The purpose of
|
||||
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> was never quite clear.
|
||||
Most drivers seem to ignore this flag. For compatibility with the
|
||||
<wordasword>bttv</wordasword> driver applications should set the
|
||||
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> flag.</entry>
|
||||
<entry>If this flag is set for a video capture device, then the
|
||||
driver will set the initial overlay size to cover the full framebuffer size,
|
||||
otherwise the existing overlay size (as set by &VIDIOC-S-FMT;) will be used.
|
||||
|
||||
Only one video capture driver (bttv) supports this flag. The use of this flag
|
||||
for capture devices is deprecated. There is no way to detect which drivers
|
||||
support this flag, so the only reliable method of setting the overlay size is
|
||||
through &VIDIOC-S-FMT;.
|
||||
|
||||
If this flag is set for a video output device, then the video output overlay
|
||||
window is relative to the top-left corner of the framebuffer and restricted
|
||||
to the size of the framebuffer. If it is cleared, then the video output
|
||||
overlay window is relative to the video output display.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_FLAG_CHROMAKEY</constant></entry>
|
||||
|
||||
@@ -98,8 +98,11 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
|
||||
<entry>&v4l2-tuner-type;</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>The tuner type. This is the same value as in the
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The field is not
|
||||
applicable to modulators, &ie; ignored by drivers.</entry>
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
|
||||
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
|
||||
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
|
||||
for all others. The field is not applicable to modulators, &ie; ignored
|
||||
by drivers.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -61,8 +61,8 @@ desired input in an integer and call the
|
||||
<constant>VIDIOC_S_INPUT</constant> ioctl with a pointer to this
|
||||
integer. Side effects are possible. For example inputs may support
|
||||
different video standards, so the driver may implicitly switch the
|
||||
current standard. It is good practice to select an input before
|
||||
querying or negotiating any other parameters.</para>
|
||||
current standard. Because of these possible side effects applications
|
||||
must select an input before querying or negotiating any other parameters.</para>
|
||||
|
||||
<para>Information about video inputs is available using the
|
||||
&VIDIOC-ENUMINPUT; ioctl.</para>
|
||||
|
||||
@@ -61,8 +61,9 @@ desired output in an integer and call the
|
||||
<constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this integer.
|
||||
Side effects are possible. For example outputs may support different
|
||||
video standards, so the driver may implicitly switch the current
|
||||
standard. It is good practice to select an output before querying or
|
||||
negotiating any other parameters.</para>
|
||||
standard.
|
||||
standard. Because of these possible side effects applications
|
||||
must select an output before querying or negotiating any other parameters.</para>
|
||||
|
||||
<para>Information about video outputs is available using the
|
||||
&VIDIOC-ENUMOUTPUT; ioctl.</para>
|
||||
|
||||
@@ -439,17 +439,6 @@ Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: For VIDIOC_S_FREQUENCY the type field must match the device node's type.
|
||||
If not, return -EINVAL.
|
||||
When: 3.2
|
||||
Why: It makes no sense to switch the tuner to radio mode by calling
|
||||
VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by
|
||||
calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a
|
||||
move to more consistent handling of tv and radio tuners.
|
||||
Who: Hans Verkuil <hans.verkuil@cisco.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Opening a radio device node will no longer automatically switch the
|
||||
tuner mode from tv to radio.
|
||||
When: 3.3
|
||||
|
||||
@@ -666,27 +666,6 @@ a control of this type whenever the first control belonging to a new control
|
||||
class is added.
|
||||
|
||||
|
||||
Differences from the Spec
|
||||
=========================
|
||||
|
||||
There are a few places where the framework acts slightly differently from the
|
||||
V4L2 Specification. Those differences are described in this section. We will
|
||||
have to see whether we need to adjust the spec or not.
|
||||
|
||||
1) It is no longer required to have all controls contained in a
|
||||
v4l2_ext_control array be from the same control class. The framework will be
|
||||
able to handle any type of control in the array. You need to set ctrl_class
|
||||
to 0 in order to enable this. If ctrl_class is non-zero, then it will still
|
||||
check that all controls belong to that control class.
|
||||
|
||||
If you set ctrl_class to 0 and count to 0, then it will only return an error
|
||||
if there are no controls at all.
|
||||
|
||||
2) Clarified the way error_idx works. For get and set it will be equal to
|
||||
count if nothing was done yet. If it is less than count then only the controls
|
||||
up to error_idx-1 were successfully applied.
|
||||
|
||||
|
||||
Proposals for Extensions
|
||||
========================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user