Commit 85538b1a authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab

Merge branch 'topic/docs-next' into v4l_for_linus

* topic/docs-next: (322 commits)
  [media] cx23885-cardlist.rst: add a new card
  [media] doc-rst: add some needed escape codes
  [media] doc-rst: kapi: use :c:func: instead of :cpp:func
  doc-rst: kernel-doc: fix a change introduced by mistake
  [media] v4l2-ioctl.h add debug info for struct v4l2_ioctl_ops
  [media] dvb_ringbuffer.h: some documentation improvements
  [media] v4l2-ctrls.h: fully document the header file
  [media] doc-rst: Fix some typedef ugly warnings
  [media] doc-rst: reorganize the kAPI v4l2 chapters
  [media] rename v4l2-framework.rst to v4l2-intro.rst
  [media] move V4L2 clocks to a separate .rst file
  [media] v4l2-fh.rst: add cross references and markups
  [media] v4l2-fh.rst: add fh contents from v4l2-framework.rst
  [media] v4l2-fh.h: add documentation for it
  [media] v4l2-event.rst: add cross-references and markups
  [media] v4l2-event.h: document all functions
  [media] v4l2-event.rst: add text from v4l2-framework.rst
  [media] v4l2-framework.rst: remove videobuf quick chapter
  [media] v4l2-dev: add cross-references and improve markup
  [media] doc-rst: move v4l2-dev doc to a separate file
  ...
parents 9c1958fc d271d3d9
......@@ -247,64 +247,6 @@ X!Isound/sound_firmware.c
-->
</chapter>
<chapter id="mediadev">
<title>Media Devices</title>
<sect1><title>Video2Linux devices</title>
!Iinclude/media/tuner.h
!Iinclude/media/tuner-types.h
!Iinclude/media/tveeprom.h
!Iinclude/media/v4l2-async.h
!Iinclude/media/v4l2-ctrls.h
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
!Iinclude/media/v4l2-rect.h
!Iinclude/media/v4l2-subdev.h
!Iinclude/media/videobuf2-core.h
!Iinclude/media/videobuf2-v4l2.h
!Iinclude/media/videobuf2-memops.h
</sect1>
<sect1><title>Digital TV (DVB) devices</title>
<sect1><title>Digital TV Common functions</title>
!Idrivers/media/dvb-core/dvb_math.h
!Idrivers/media/dvb-core/dvb_ringbuffer.h
!Idrivers/media/dvb-core/dvbdev.h
</sect1>
<sect1><title>Digital TV Frontend kABI</title>
!Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend
!Idrivers/media/dvb-core/dvb_frontend.h
</sect1>
<sect1><title>Digital TV Demux kABI</title>
!Pdrivers/media/dvb-core/demux.h Digital TV Demux
<sect1><title>Demux Callback API</title>
!Pdrivers/media/dvb-core/demux.h Demux Callback
</sect1>
!Idrivers/media/dvb-core/demux.h
</sect1>
<sect1><title>Digital TV Conditional Access kABI</title>
!Idrivers/media/dvb-core/dvb_ca_en50221.h
</sect1>
</sect1>
<sect1><title>Remote Controller devices</title>
!Iinclude/media/rc-core.h
!Iinclude/media/lirc_dev.h
</sect1>
<sect1><title>Media Controller devices</title>
!Pinclude/media/media-device.h Media Controller
!Iinclude/media/media-device.h
!Iinclude/media/media-devnode.h
!Iinclude/media/media-entity.h
</sect1>
<sect1><title>Consumer Electronics Control devices</title>
!Iinclude/media/cec-edid.h
</sect1>
</chapter>
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
......
......@@ -526,7 +526,7 @@
<para>
You may extract a single document from such a collection, and
dispbibute it individually under this License, provided you
distribute it individually under this License, provided you
insert a copy of this License into the extracted document, and
follow this License in all other respects regarding verbatim
copying of that document.
......
......@@ -114,7 +114,7 @@ on working with the default settings initially.</para>
<para>Some receiver have maximum resolution which is defined by internal
sample rate or data format limitations. E.g. it's common that signals can
only be reported in 50 microsecond steps. This integer value is used by
lircd to automatically adjust the aeps tolerance value in the lircd
lircd to automatically adjust the steps tolerance value in the lircd
config file.</para>
</listitem>
</varlistentry>
......
......@@ -38,9 +38,10 @@ ALLSPHINXOPTS = -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) -d $(B
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
quiet_cmd_sphinx = SPHINX $@
cmd_sphinx = $(SPHINXBUILD) -b $2 $(ALLSPHINXOPTS) $(BUILDDIR)/$2
cmd_sphinx = BUILDDIR=$(BUILDDIR) $(SPHINXBUILD) -b $2 $(ALLSPHINXOPTS) $(BUILDDIR)/$2
htmldocs:
$(MAKE) BUILDDIR=$(BUILDDIR) -f $(srctree)/Documentation/media/Makefile $@
$(call cmd,sphinx,html)
pdfdocs:
......
......@@ -28,7 +28,7 @@ sys.path.insert(0, os.path.abspath('sphinx'))
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = ['kernel-doc', 'rstFlatTable']
extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include']
# Gracefully handle missing rst2pdf.
try:
......@@ -176,7 +176,14 @@ except ImportError:
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
#html_static_path = ['_static']
html_static_path = ['sphinx-static']
html_context = {
'css_files': [
'_static/theme_overrides.css',
],
}
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
......@@ -404,7 +411,7 @@ epub_exclude_files = ['search.html']
# multiple PDF files here actually tries to get the cross-referencing right
# *between* PDF files.
pdf_documents = [
('index', u'Kernel', u'Kernel', u'J. Random Bozo'),
('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
]
# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
......
This diff is collapsed.
Thanks go to the following people for patches and contributions:
Michael Hunold <m.hunold@gmx.de>
for the initial saa7146 driver and its recent overhaul
Christian Theiss
for his work on the initial Linux DVB driver
Marcus Metzler <mocm@metzlerbros.de>
Ralph Metzler <rjkm@metzlerbros.de>
for their continuing work on the DVB driver
Michael Holzt <kju@debian.org>
for his contributions to the dvb-net driver
Diego Picciani <d.picciani@novacomp.it>
for CyberLogin for Linux which allows logging onto EON
(in case you are wondering where CyberLogin is, EON changed its login
procedure and CyberLogin is no longer used.)
Martin Schaller <martin@smurf.franken.de>
for patching the cable card decoder driver
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
for various fixes regarding tuning, OSD and CI stuff and his work on VDR
Steve Brown <sbrown@cortland.com>
for his AFC kernel thread
Christoph Martin <martin@uni-mainz.de>
for his LIRC infrared handler
Andreas Oberritter <obi@linuxtv.org>
Dennis Noermann <dennis.noermann@noernet.de>
Felix Domke <tmbinc@elitedvb.net>
Florian Schirmer <jolt@tuxbox.org>
Ronny Strutz <3des@elitedvb.de>
Wolfram Joost <dbox2@frokaschwei.de>
...and all the other dbox2 people
for many bugfixes in the generic DVB Core, frontend drivers and
their work on the dbox2 port of the DVB driver
Oliver Endriss <o.endriss@gmx.de>
for many bugfixes
Andrew de Quincey <adq_dvb@lidskialf.net>
for the tda1004x frontend driver, and various bugfixes
Peter Schildmann <peter.schildmann@web.de>
for the driver for the Technisat SkyStar2 PCI DVB card
Vadim Catana <skystar@moldova.cc>
Roberto Ragusa <r.ragusa@libero.it>
Augusto Cardoso <augusto@carhil.net>
for all the work for the FlexCopII chipset by B2C2,Inc.
Davor Emard <emard@softhome.net>
for his work on the budget drivers, the demux code,
the module unloading problems, ...
Hans-Frieder Vogt <hfvogt@arcor.de>
for his work on calculating and checking the crc's for the
TechnoTrend/Hauppauge DEC driver firmware
Michael Dreher <michael@5dot1.de>
Andreas 'randy' Weinberger
for the support of the Fujitsu-Siemens Activy budget DVB-S
Kenneth Aafløy <ke-aa@frisurf.no>
for adding support for Typhoon DVB-S budget card
Ernst Peinlich <e.peinlich@inode.at>
for tuning/DiSEqC support for the DEC 3000-s
Peter Beutner <p.beutner@gmx.net>
for the IR code for the ttusb-dec driver
Wilson Michaels <wilsonmichaels@earthlink.net>
for the lgdt330x frontend driver, and various bugfixes
Michael Krufky <mkrufky@linuxtv.org>
for maintaining v4l/dvb inter-tree dependencies
Taylor Jacob <rtjacob@earthlink.net>
for the nxt2002 frontend driver
Jean-Francois Thibert <jeanfrancois@sagetv.com>
for the nxt2004 frontend driver
Kirk Lapray <kirk.lapray@gmail.com>
for the or51211 and or51132 frontend drivers, and
for merging the nxt2002 and nxt2004 modules into a
single nxt200x frontend driver.
(If you think you should be in this list, but you are not, drop a
line to the DVB mailing list)
Linux Digital Video Broadcast (DVB) subsystem
=============================================
The main development site and CVS repository for these
drivers is https://linuxtv.org.
The developer mailing list linux-dvb is also hosted there,
see https://linuxtv.org/lists.php. Please check
the archive https://linuxtv.org/pipermail/linux-dvb/
and the Wiki https://linuxtv.org/wiki/
before asking newbie questions on the list.
API documentation, utilities and test/example programs
are available as part of the old driver package for Linux 2.4
(linuxtv-dvb-1.0.x.tar.gz), or from CVS (module DVB).
We plan to split this into separate packages, but it's not
been done yet.
https://linuxtv.org/downloads/
What's inside this directory:
"avermedia.txt"
contains detailed information about the
Avermedia DVB-T cards. See also "bt8xx.txt".
"bt8xx.txt"
contains detailed information about the
various bt8xx based "budget" DVB cards.
"cards.txt"
contains a list of supported hardware.
"ci.txt"
contains detailed information about the
CI module as part from TwinHan cards and Clones.
"contributors.txt"
is the who-is-who of DVB development.
"faq.txt"
contains frequently asked questions and their answers.
"get_dvb_firmware"
script to download and extract firmware for those devices
that require it.
"ttusb-dec.txt"
contains detailed information about the
TT DEC2000/DEC3000 USB DVB hardware.
"udev.txt"
how to get DVB and udev up and running.
"README.dvb-usb"
contains detailed information about the DVB USB cards.
"README.flexcop"
contains detailed information about the
Technisat- and Flexcop B2C2 drivers.
Good luck and have fun!
How to set up the Technisat/B2C2 Flexcop devices
================================================
1) Find out what device you have
================================
Important Notice: The driver does NOT support Technisat USB 2 devices!
First start your linux box with a shipped kernel:
lspci -vvv for a PCI device (lsusb -vvv for an USB device) will show you for example:
02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip /
Technisat SkyStar2 DVB card (rev 02)
dmesg | grep frontend may show you for example:
DVB: registering frontend 0 (Conexant CX24123/CX24109)...
2) Kernel compilation:
======================
If the Flexcop / Technisat is the only DVB / TV / Radio device in your box
get rid of unnecessary modules and check this one:
"Multimedia support" => "Customise analog and hybrid tuner modules to build"
In this directory uncheck every driver which is activated there
(except "Simple tuner support" for ATSC 3rd generation only -> see case 9 please).
Then please activate:
2a) Main module part:
"Multimedia support" => "DVB/ATSC adapters"
=> "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
a.) => "Technisat/B2C2 Air/Sky/Cable2PC PCI" (PCI card) or
b.) => "Technisat/B2C2 Air/Sky/Cable2PC USB" (USB 1.1 adapter)
and for troubleshooting purposes:
c.) => "Enable debug for the B2C2 FlexCop drivers"
2b) Frontend / Tuner / Demodulator module part:
"Multimedia support" => "DVB/ATSC adapters"
=> "Customise the frontend modules to build" "Customise DVB frontends" =>
1.) SkyStar DVB-S Revision 2.3:
a.) => "Zarlink VP310/MT312/ZL10313 based"
b.) => "Generic I2C PLL based tuners"
2.) SkyStar DVB-S Revision 2.6:
a.) => "ST STV0299 based"
b.) => "Generic I2C PLL based tuners"
3.) SkyStar DVB-S Revision 2.7:
a.) => "Samsung S5H1420 based"
b.) => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
c.) => "ISL6421 SEC controller"
4.) SkyStar DVB-S Revision 2.8:
a.) => "Conexant CX24123 based"
b.) => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
c.) => "ISL6421 SEC controller"
5.) AirStar DVB-T card:
a.) => "Zarlink MT352 based"
b.) => "Generic I2C PLL based tuners"
6.) CableStar DVB-C card:
a.) => "ST STV0297 based"
b.) => "Generic I2C PLL based tuners"
7.) AirStar ATSC card 1st generation:
a.) => "Broadcom BCM3510"
8.) AirStar ATSC card 2nd generation:
a.) => "NxtWave Communications NXT2002/NXT2004 based"
b.) => "Generic I2C PLL based tuners"
9.) AirStar ATSC card 3rd generation:
a.) => "LG Electronics LGDT3302/LGDT3303 based"
b.) "Multimedia support" => "Customise analog and hybrid tuner modules to build"
=> "Simple tuner support"
Author: Uwe Bugla <uwe.bugla@gmx.de> August 2009
......@@ -14,6 +14,10 @@ Contents:
:maxdepth: 2
kernel-documentation
media/media_uapi
media/media_kapi
media/dvb-drivers/index
media/v4l-drivers/index
Indices and tables
==================
......
# Generate the *.h.rst files from uAPI headers
PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
UAPI = $(srctree)/include/uapi/linux
KAPI = $(srctree)/include/linux
SRC_DIR=$(srctree)/Documentation/media
FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \
videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst
TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
htmldocs: $(BUILDDIR) ${TARGETS}
$(BUILDDIR):
$(Q)mkdir -p $@
# Rule to convert a .h file to inline RST documentation
gen_rst = \
echo ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions; \
${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
quiet_gen_rst = echo ' PARSE $(patsubst $(srctree)/%,%,$<)'; \
${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
silent_gen_rst = ${gen_rst}
$(BUILDDIR)/audio.h.rst: ${UAPI}/dvb/audio.h ${PARSER} $(SRC_DIR)/audio.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/ca.h.rst: ${UAPI}/dvb/ca.h ${PARSER} $(SRC_DIR)/ca.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/dmx.h.rst: ${UAPI}/dvb/dmx.h ${PARSER} $(SRC_DIR)/dmx.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/frontend.h.rst: ${UAPI}/dvb/frontend.h ${PARSER} $(SRC_DIR)/frontend.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/net.h.rst: ${UAPI}/dvb/net.h ${PARSER} $(SRC_DIR)/net.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} $(SRC_DIR)/video.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} $(SRC_DIR)/videodev2.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/media.h.rst: ${UAPI}/media.h ${PARSER} $(SRC_DIR)/media.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/cec.h.rst: ${KAPI}/cec.h ${PARSER} $(SRC_DIR)/cec.h.rst.exceptions
@$($(quiet)gen_rst)
$(BUILDDIR)/lirc.h.rst: ${UAPI}/lirc.h ${PARSER} $(SRC_DIR)/lirc.h.rst.exceptions
@$($(quiet)gen_rst)
cleandocs:
-rm ${TARGETS}
# Ignore header name
ignore define _DVBAUDIO_H_
# Typedef pointing to structs
replace typedef audio_karaoke_t audio-karaoke
# Undocumented audio caps, as this is a deprecated API anyway
ignore define AUDIO_CAP_DTS
ignore define AUDIO_CAP_LPCM
ignore define AUDIO_CAP_MP1
ignore define AUDIO_CAP_MP2
ignore define AUDIO_CAP_MP3
ignore define AUDIO_CAP_AAC
ignore define AUDIO_CAP_OGG
ignore define AUDIO_CAP_SDDS
ignore define AUDIO_CAP_AC3
# some typedefs should point to struct/enums
replace typedef audio_mixer_t audio-mixer
replace typedef audio_status_t audio-status
# Ignore header name
ignore define _DVBCA_H_
# struct ca_slot_info defines
replace define CA_CI ca-slot-info
replace define CA_CI_LINK ca-slot-info
replace define CA_CI_PHYS ca-slot-info
replace define CA_DESCR ca-slot-info
replace define CA_SC ca-slot-info
replace define CA_CI_MODULE_PRESENT ca-slot-info
replace define CA_CI_MODULE_READY ca-slot-info
# struct ca_descr_info defines
replace define CA_ECD ca-descr-info
replace define CA_NDS ca-descr-info
replace define CA_DSS ca-descr-info
# some typedefs should point to struct/enums
replace typedef ca_pid_t ca-pid
replace typedef ca_slot_info_t ca-slot-info
replace typedef ca_descr_info_t ca-descr-info
replace typedef ca_caps_t ca-caps
replace typedef ca_msg_t ca-msg
replace typedef ca_descr_t ca-descr
This diff is collapsed.
# Ignore header name
ignore define _UAPI_DVBDMX_H_
# Ignore limit constants
ignore define DMX_FILTER_SIZE
# dmx-pes-type-t enum symbols
replace enum dmx_ts_pes dmx-pes-type-t
replace symbol DMX_PES_AUDIO0 dmx-pes-type-t
replace symbol DMX_PES_VIDEO0 dmx-pes-type-t
replace symbol DMX_PES_TELETEXT0 dmx-pes-type-t
replace symbol DMX_PES_SUBTITLE0 dmx-pes-type-t
replace symbol DMX_PES_PCR0 dmx-pes-type-t
replace symbol DMX_PES_AUDIO1 dmx-pes-type-t
replace symbol DMX_PES_VIDEO1 dmx-pes-type-t
replace symbol DMX_PES_TELETEXT1 dmx-pes-type-t
replace symbol DMX_PES_SUBTITLE1 dmx-pes-type-t
replace symbol DMX_PES_PCR1 dmx-pes-type-t
replace symbol DMX_PES_AUDIO2 dmx-pes-type-t
replace symbol DMX_PES_VIDEO2 dmx-pes-type-t
replace symbol DMX_PES_TELETEXT2 dmx-pes-type-t
replace symbol DMX_PES_SUBTITLE2 dmx-pes-type-t
replace symbol DMX_PES_PCR2 dmx-pes-type-t
replace symbol DMX_PES_AUDIO3 dmx-pes-type-t
replace symbol DMX_PES_VIDEO3 dmx-pes-type-t
replace symbol DMX_PES_TELETEXT3 dmx-pes-type-t
replace symbol DMX_PES_SUBTITLE3 dmx-pes-type-t
replace symbol DMX_PES_PCR3 dmx-pes-type-t
replace symbol DMX_PES_OTHER dmx-pes-type-t
# Ignore obsolete symbols
ignore define DMX_PES_AUDIO
ignore define DMX_PES_VIDEO
ignore define DMX_PES_TELETEXT
ignore define DMX_PES_SUBTITLE
ignore define DMX_PES_PCR
# dmx_input_t symbols
replace enum dmx_input dmx-input-t
replace symbol DMX_IN_FRONTEND dmx-input-t
replace symbol DMX_IN_DVR dmx-input-t
# dmx_source_t symbols
replace enum dmx_source dmx-source-t
replace symbol DMX_SOURCE_FRONT0 dmx-source-t
replace symbol DMX_SOURCE_FRONT1 dmx-source-t
replace symbol DMX_SOURCE_FRONT2 dmx-source-t
replace symbol DMX_SOURCE_FRONT3 dmx-source-t
replace symbol DMX_SOURCE_DVR0 dmx-source-t
replace symbol DMX_SOURCE_DVR1 dmx-source-t
replace symbol DMX_SOURCE_DVR2 dmx-source-t
replace symbol DMX_SOURCE_DVR3 dmx-source-t
# Flags for struct dmx_sct_filter_params
replace define DMX_CHECK_CRC dmx-sct-filter-params
replace define DMX_ONESHOT dmx-sct-filter-params
replace define DMX_IMMEDIATE_START dmx-sct-filter-params
replace define DMX_KERNEL_CLIENT dmx-sct-filter-params
# some typedefs should point to struct/enums
replace typedef dmx_caps_t dmx-caps
replace typedef dmx_filter_t dmx-filter
This diff is collapsed.
How to get the bt8xx cards working
==================================
1) General information
======================
Authors: Richard Walker,
Jamie Honan,
Michael Hunold,
Manu Abraham,
Uwe Bugla,
Michael Krufky
.. note::
This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
General information
-------------------
This class of cards has a bt878a as the PCI interface, and require the bttv driver
for accessing the i2c bus and the gpio pins of the bt8xx chipset.
Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
Compiling kernel please enable:
a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Enable Video for Linux API 1 (DEPRECATED)"
b.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Video Capture Adapters" => "BT848 Video For Linux"
c.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
Please use the following options with care as deselection of drivers which are in fact necessary
may result in DVB devices that cannot be tuned due to lack of driver support:
You can save RAM by deselecting every frontend module that your DVB card does not need.
#) ``Device drivers`` => ``Multimedia devices`` => ``Video For Linux`` => ``Enable Video for Linux API 1 (DEPRECATED)``
#) ``Device drivers`` => ``Multimedia devices`` => ``Video For Linux`` => ``Video Capture Adapters`` => ``BT848 Video For Linux``
#) ``Device drivers`` => ``Multimedia devices`` => ``Digital Video Broadcasting Devices`` => ``DVB for Linux`` ``DVB Core Support`` ``Bt8xx based PCI Cards``
Please use the following options with care as deselection of drivers which are in fact necessary may result in DVB devices that cannot be tuned due to lack of driver support:
You can save RAM by deselecting every frontend module that your DVB card does not need.
First please remove the static dependency of DVB card drivers on all frontend modules for all possible card variants by enabling:
#) ``Device drivers`` => ``Multimedia devices`` => ``Digital Video Broadcasting Devices`` => ``DVB for Linux`` ``DVB Core Support`` ``Load and attach frontend modules as needed``
First please remove the static dependency of DVB card drivers on all frontend modules for all possible card variants by enabling:
d.) "Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Load and attach frontend modules as needed"
If you know the frontend driver that your card needs please enable:
#) ``Device drivers`` => ``Multimedia devices`` => ``Digital Video Broadcasting Devices`` => ``DVB for Linux`` ``DVB Core Support`` ``Customise DVB Frontends`` => ``Customise the frontend modules to build``
If you know the frontend driver that your card needs please enable:
e.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Customise DVB Frontends" => "Customise the frontend modules to build"
Then please select your card-specific frontend module.
2) Loading Modules
==================
Loading Modules
---------------
Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically.
Exceptions are:
......@@ -36,20 +49,24 @@ People running udev please see Documentation/dvb/udev.txt.
In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary:
2a) Running TwinHan and Clones
------------------------------
Running TwinHan and Clones
~~~~~~~~~~~~~~~~~~~~~~~~~~
.. code-block:: none
$ modprobe bttv card=113
$ modprobe dst
Useful parameters for verbosity level and debugging the dst module:
verbose=0: messages are disabled
.. code-block:: none
verbose=0: messages are disabled
1: only error messages are displayed
2: notifications are displayed
3: other useful messages are displayed
4: debug setting
dst_addons=0: card is a free to air (FTA) card only
dst_addons=0: card is a free to air (FTA) card only
0x20: card has a conditional access slot for scrambled channels
The autodetected values are determined by the cards' "response string".
......@@ -57,42 +74,49 @@ In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
For bug reports please send in a complete log with verbose=4 activated.
Please also see Documentation/dvb/ci.txt.
2b) Running multiple cards
--------------------------
Running multiple cards
~~~~~~~~~~~~~~~~~~~~~~
Examples of card ID's:
Pinnacle PCTV Sat: 94
Nebula Electronics Digi TV: 104
pcHDTV HD-2000 TV: 112
Twinhan DST and clones: 113
Avermedia AverTV DVB-T 771: 123
Avermedia AverTV DVB-T 761: 124
DViCO FusionHDTV DVB-T Lite: 128
DViCO FusionHDTV 5 Lite: 135
Notice: The order of the card ID should be uprising:
Example:
.. code-block:: none
Pinnacle PCTV Sat: 94
Nebula Electronics Digi TV: 104
pcHDTV HD-2000 TV: 112
Twinhan DST and clones: 113
Avermedia AverTV DVB-T 771: 123
Avermedia AverTV DVB-T 761: 124
DViCO FusionHDTV DVB-T Lite: 128
DViCO FusionHDTV 5 Lite: 135
.. note::
The order of the card ID should be uprising:
Example:
.. code-block:: none
$ modprobe bttv card=113 card=135
For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org.
2c) Probing the cards with broken PCI subsystem ID
--------------------------------------------------
Probing the cards with broken PCI subsystem ID
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are some TwinHan cards that the EEPROM has become corrupted for some
reason. The cards do not have correct PCI subsystem ID. But we can force
probing the cards with broken PCI subsystem ID
.. code-block:: none
$ echo 109e 0878 $subvendor $subdevice > \
/sys/bus/pci/drivers/bt878/new_id
109e: PCI_VENDOR_ID_BROOKTREE
0878: PCI_DEVICE_ID_BROOKTREE_878
.. code-block:: none
109e: PCI_VENDOR_ID_BROOKTREE
0878: PCI_DEVICE_ID_BROOKTREE_878
Authors: Richard Walker,
Jamie Honan,
Michael Hunold,
Manu Abraham,
Uwe Bugla,
Michael Krufky
Hardware supported by the linuxtv.org DVB drivers
=================================================
Generally, the DVB hardware manufacturers frequently change the
frontends (i.e. tuner / demodulator units) used, usually without
changing the product name, revision number or specs. Some cards
are also available in versions with different frontends for
DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed separately.
.. note::
Note 1: There is no guarantee that every frontend driver works
This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
Please look at
https://linuxtv.org/wiki/index.php/Hardware_Device_Information
for an updated list of supported cards.
Generally, the DVB hardware manufacturers frequently change the
frontends (i.e. tuner / demodulator units) used, usually without
changing the product name, revision number or specs. Some cards
are also available in versions with different frontends for
DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed separately.
.. note::
#) There is no guarantee that every frontend driver works
out of the box with every card, because of different wiring.
Note 2: The demodulator chips can be used with a variety of
#) The demodulator chips can be used with a variety of
tuner/PLL chips, and not all combinations are supported. Often
the demodulator and tuner/PLL chip are inside a metal box for
shielding, and the whole metal box has its own part number.
o Frontends drivers:
- Frontends drivers:
- dvb_dummy_fe: for testing...
DVB-S:
- ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
- cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL)
......@@ -26,21 +39,23 @@ o Frontends drivers:
- stv0299 : Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL),
LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL),
Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB, Technisat Sky2Pc with bios Rev. 2.6
DVB-C:
- ves1820 : various (ves1820 demodulator, sp5659c or spXXXX PLL)
- at76c651 : Atmel AT76c651(B) with DAT7021 PLL
DVB-T:
- alps_tdlb7 : Alps TDLB7 (sp8870 demodulator, sp5659 PLL)
- alps_tdmb7 : Alps TDMB7 (cx22700 demodulator)
- grundig_29504-401 : Grundig 29504-401 (LSI L64781 demodulator), tsa5060 PLL
- tda1004x : Philips tda10045h (td1344 or tdm1316l PLL)
- nxt6000 : Alps TDME7 (MITEL SP5659 PLL), Alps TDED4 (TI ALP510 PLL),
Comtech DVBT-6k07 (SP5730 PLL)
(NxtWave Communications NXT6000 demodulator)
- nxt6000 : Alps TDME7 (MITEL SP5659 PLL), Alps TDED4 (TI ALP510 PLL), Comtech DVBT-6k07 (SP5730 PLL), (NxtWave Communications NXT6000 demodulator)
- sp887x : Microtune 7202D
- dib3000mb : DiBcom 3000-MB demodulator
DVB-S/C/T:
- dst : TwinHan DST Frontend
ATSC:
- nxt200x : Nxtwave NXT2002 & NXT2004
- or51211 : or51211 based (pcHDTV HD2000 card)
......@@ -49,10 +64,10 @@ o Frontends drivers:
- lgdt330x : LG Electronics DT3302 & DT3303
o Cards based on the Phillips saa7146 multimedia PCI bridge chip:
- Cards based on the Phillips saa7146 multimedia PCI bridge chip:
- TI AV7110 based cards (i.e. with hardware MPEG decoder):
- Siemens/Technotrend/Hauppauge PCI DVB card revision 1.1, 1.3, 1.5, 1.6, 2.1
(aka Hauppauge Nexus)
- Siemens/Technotrend/Hauppauge PCI DVB card revision 1.1, 1.3, 1.5, 1.6, 2.1 (aka Hauppauge Nexus)
- "budget" cards (i.e. without hardware MPEG decoder):
- Technotrend Budget / Hauppauge WinTV-Nova PCI Cards
- SATELCO Multimedia PCI
......@@ -60,10 +75,12 @@ o Cards based on the Phillips saa7146 multimedia PCI bridge chip:
- Typhoon DVB-S budget
- Fujitsu-Siemens Activy DVB-S budget card
o Cards based on the B2C2 Inc. FlexCopII/IIb/III:
- Cards based on the B2C2 Inc. FlexCopII/IIb/III:
- Technisat SkyStar2 PCI DVB card revision 2.3, 2.6B, 2.6C
o Cards based on the Conexant Bt8xx PCI bridge:
- Cards based on the Conexant Bt8xx PCI bridge:
- Pinnacle PCTV Sat DVB
- Nebula Electronics DigiTV
- TwinHan DST
......@@ -73,11 +90,13 @@ o Cards based on the Conexant Bt8xx PCI bridge:
- DViCO FusionHDTV DVB-T Lite
- DViCO FusionHDTV5 Lite
o Technotrend / Hauppauge DVB USB devices:
- Technotrend / Hauppauge DVB USB devices:
- Nova USB
- DEC 2000-T, 3000-S, 2540-T
o DiBcom DVB-T USB based devices:
- DiBcom DVB-T USB based devices:
- Twinhan VisionPlus VisionDTV USB-Ter DVB-T Device
- HAMA DVB-T USB device
- CTS Portable (Chinese Television System)
......@@ -92,9 +111,10 @@ o DiBcom DVB-T USB based devices:
- Yakumo DVB-T mobile USB2.0
- DiBcom USB2.0 DVB-T reference device (non-public)
o Experimental support for the analog module of the Siemens DVB-C PCI card
- Experimental support for the analog module of the Siemens DVB-C PCI card
- Cards based on the Conexant cx2388x PCI bridge:
o Cards based on the Conexant cx2388x PCI bridge:
- ADS Tech Instant TV DVB-T PCI
- ATI HDTV Wonder
- digitalnow DNTV Live! DVB-T
......@@ -109,7 +129,8 @@ o Cards based on the Conexant cx2388x PCI bridge:
- TerraTec Cinergy 1400 DVB-T
- WinFast DTV1000-T
o Cards based on the Phillips saa7134 PCI bridge:
- Cards based on the Phillips saa7134 PCI bridge:
- Medion 7134
- Pinnacle PCTV 300i DVB-T + PAL
- LifeView FlyDVB-T DUO
......
* For the user
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: This document describes the usage of the high level CI API as
Digital TV Conditional Access Interface (CI API)
================================================
.. note::
This documentation is outdated.
This document describes the usage of the high level CI API as
in accordance to the Linux DVB API. This is a not a documentation for the,
existing low level CI API.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To utilize the High Level CI capabilities,
.. note::
(1*) This point is valid only for the Twinhan/clones
For the Twinhan/Twinhan clones, the dst_ca module handles the CI
hardware handling.This module is loaded automatically if a CI
(Common Interface, that holds the CAM (Conditional Access Module)
is detected.
(2) one requires a userspace application, ca_zap. This small userland
application is in charge of sending the descrambling related information
to the CAM.
ca_zap
~~~~~~
An userspace application, like ``ca_zap`` is required to handle encrypted
MPEG-TS streams.
The ``ca_zap`` userland application is in charge of sending the
descrambling related information to the Conditional Access Module (CAM).
This application requires the following to function properly as of now.
(a) Tune to a valid channel, with szap.
a) Tune to a valid channel, with szap.
eg: $ szap -c channels.conf -r "TMC" -x
(b) a channels.conf containing a valid PMT PID
b) a channels.conf containing a valid PMT PID
eg: TMC:11996:h:0:27500:278:512:650:321
here 278 is a valid PMT PID. the rest of the values are the
same ones that szap uses.
(c) after running a szap, you have to run ca_zap, for the
c) after running a szap, you have to run ca_zap, for the
descrambler to function,
eg: $ ca_zap channels.conf "TMC"
(d) Hopefully enjoy your favourite subscribed channel as you do with
d) Hopefully enjoy your favourite subscribed channel as you do with
a FTA card.
(3) Currently ca_zap, and dst_test, both are meant for demonstration
.. note::
Currently ca_zap, and dst_test, both are meant for demonstration
purposes only, they can become full fledged applications if necessary.
* Cards that fall in this category
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cards that fall in this category
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At present the cards that fall in this category are the Twinhan and its
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
so on.
* CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CI module support is largely dependent upon the firmware on the cards
Some cards do support almost all of the available CI modules. There is
nothing much that can be done in order to make additional CI modules
......@@ -58,11 +74,12 @@ Modules that have been tested by this driver at present are
(2) Viaccess from SCM
(3) Dragoncam
* The High level CI API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The High level CI API
~~~~~~~~~~~~~~~~~~~~~
For the programmer
^^^^^^^^^^^^^^^^^^
* For the programmer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the High Level CI approach any new card with almost any random
architecture can be implemented with this style, the definitions
inside the switch statement can be easily adapted for any card, thereby
......@@ -74,29 +91,30 @@ array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accommodate this feature.
* Why the need for another CI interface ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why the need for another CI interface?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is one of the most commonly asked question. Well a nice question.
Strictly speaking this is not a new interface.
The CI interface is defined in the DVB API in ca.h as
The CI interface is defined in the DVB API in ca.h as:
typedef struct ca_slot_info {
.. code-block:: c
typedef struct ca_slot_info {
int num; /* slot number */
int type; /* CA interface this slot supports */
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_DESCR 8 /* built-in descrambler */
#define CA_SC 128 /* simple smart card interface */
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_DESCR 8 /* built-in descrambler */
#define CA_SC 128 /* simple smart card interface */
unsigned int flags;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
......@@ -113,7 +131,6 @@ means that no session management, link layer or a transport layer do
exist in this case in the application to driver communication. It is
as simple as that. The driver/hardware has to take care of that.
With this High Level CI interface, the interface can be defined with the
regular ioctls.
......@@ -129,34 +146,36 @@ All these ioctls are also valid for the High level CI interface
#define CA_SET_PID _IOW('o', 135, ca_pid_t)
On querying the device, the device yields information thus
On querying the device, the device yields information thus:
.. code-block:: none
CA_GET_SLOT_INFO
----------------------------
Command = [info]
APP: Number=[1]
APP: Type=[1]
APP: flags=[1]
APP: CI High level interface
APP: CA/CI Module Present
CA_GET_SLOT_INFO
----------------------------
Command = [info]
APP: Number=[1]
APP: Type=[1]
APP: flags=[1]
APP: CI High level interface
APP: CA/CI Module Present
CA_GET_CAP
----------------------------
Command = [caps]
APP: Slots=[1]
APP: Type=[1]
APP: Descrambler keys=[16]
APP: Type=[1]
CA_GET_CAP
----------------------------
Command = [caps]
APP: Slots=[1]
APP: Type=[1]
APP: Descrambler keys=[16]
APP: Type=[1]
CA_SEND_MSG
----------------------------
Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
Found CA descriptor @ program level
CA_SEND_MSG
----------------------------
Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
Found CA descriptor @ program level
(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)]
(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)]
ca_message length is 25 (0x19) bytes
EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)]
(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)]
ca_message length is 25 (0x19) bytes
EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
Not all ioctl's are implemented in the driver from the API, the other
......@@ -164,21 +183,20 @@ features of the hardware that cannot be implemented by the API are achieved
using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is
used to exchange the data to maintain compatibility with other hardware.
.. code-block:: c
/* a message to/from a CI-CAM */
typedef struct ca_msg {
/* a message to/from a CI-CAM */
typedef struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
} ca_msg_t;
The flow of data can be described thus,
.. code-block:: none
App (User)
-----
......
Contributors
============
.. note::
This documentation is outdated. There are several other DVB contributors
that aren't listed below.
Thanks go to the following people for patches and contributions:
- Michael Hunold <m.hunold@gmx.de>
- for the initial saa7146 driver and its recent overhaul
- Christian Theiss
- for his work on the initial Linux DVB driver
- Marcus Metzler <mocm@metzlerbros.de> and
Ralph Metzler <rjkm@metzlerbros.de>
- for their continuing work on the DVB driver
- Michael Holzt <kju@debian.org>
- for his contributions to the dvb-net driver
- Diego Picciani <d.picciani@novacomp.it>
- for CyberLogin for Linux which allows logging onto EON
(in case you are wondering where CyberLogin is, EON changed its login
procedure and CyberLogin is no longer used.)
- Martin Schaller <martin@smurf.franken.de>
- for patching the cable card decoder driver
- Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
- for various fixes regarding tuning, OSD and CI stuff and his work on VDR
- Steve Brown <sbrown@cortland.com>
- for his AFC kernel thread
- Christoph Martin <martin@uni-mainz.de>
- for his LIRC infrared handler
- Andreas Oberritter <obi@linuxtv.org>,
Dennis Noermann <dennis.noermann@noernet.de>,
Felix Domke <tmbinc@elitedvb.net>,
Florian Schirmer <jolt@tuxbox.org>,
Ronny Strutz <3des@elitedvb.de>,
Wolfram Joost <dbox2@frokaschwei.de>
and all the other dbox2 people
- for many bugfixes in the generic DVB Core, frontend drivers and
their work on the dbox2 port of the DVB driver
- Oliver Endriss <o.endriss@gmx.de>
- for many bugfixes
- Andrew de Quincey <adq_dvb@lidskialf.net>
- for the tda1004x frontend driver, and various bugfixes
- Peter Schildmann <peter.schildmann@web.de>
- for the driver for the Technisat SkyStar2 PCI DVB card
- Vadim Catana <skystar@moldova.cc>,
Roberto Ragusa <r.ragusa@libero.it> and
Augusto Cardoso <augusto@carhil.net>
- for all the work for the FlexCopII chipset by B2C2,Inc.
- Davor Emard <emard@softhome.net>
- for his work on the budget drivers, the demux code,
the module unloading problems, ...
- Hans-Frieder Vogt <hfvogt@arcor.de>
- for his work on calculating and checking the crc's for the
TechnoTrend/Hauppauge DEC driver firmware
- Michael Dreher <michael@5dot1.de> and
Andreas 'randy' Weinberger
- for the support of the Fujitsu-Siemens Activy budget DVB-S
- Kenneth Aafløy <ke-aa@frisurf.no>
- for adding support for Typhoon DVB-S budget card
- Ernst Peinlich <e.peinlich@inode.at>
- for tuning/DiSEqC support for the DEC 3000-s
- Peter Beutner <p.beutner@gmx.net>
- for the IR code for the ttusb-dec driver
- Wilson Michaels <wilsonmichaels@earthlink.net>
- for the lgdt330x frontend driver, and various bugfixes
- Michael Krufky <mkrufky@linuxtv.org>
- for maintaining v4l/dvb inter-tree dependencies
- Taylor Jacob <rtjacob@earthlink.net>
- for the nxt2002 frontend driver
- Jean-Francois Thibert <jeanfrancois@sagetv.com>
- for the nxt2004 frontend driver
- Kirk Lapray <kirk.lapray@gmail.com>
- for the or51211 and or51132 frontend drivers, and
for merging the nxt2002 and nxt2004 modules into a
single nxt200x frontend driver.
(If you think you should be in this list, but you are not, drop a
line to the DVB mailing list)
FAQ
===
.. note::
This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
Some very frequently asked questions about linuxtv-dvb
1. The signal seems to die a few seconds after tuning.
......@@ -71,8 +79,7 @@ Some very frequently asked questions about linuxtv-dvb
http://www.dbox2.info/
LinuxDVB on the dBox2
http://www.tuxbox.org/
http://cvs.tuxbox.org/
http://www.tuxbox.org/ and http://cvs.tuxbox.org/
the TuxBox CVS many interesting DVB applications and the dBox2
DVB source
......@@ -85,8 +92,7 @@ Some very frequently asked questions about linuxtv-dvb
http://mplayerhq.hu/
mplayer
http://xine.sourceforge.net/
http://xinehq.de/
http://xine.sourceforge.net/ and http://xinehq.de/
xine
http://www.mythtv.org/
......@@ -125,6 +131,9 @@ Some very frequently asked questions about linuxtv-dvb
Check your routes if they include the multicast address range.
Additionally make sure that "source validation by reversed path
lookup" is disabled:
.. code-block:: none
$ "echo 0 > /proc/sys/net/ipv4/conf/dvb0/rp_filter"
7. What the hell are all those modules that need to be loaded?
......@@ -156,4 +165,3 @@ Some very frequently asked questions about linuxtv-dvb
- dvb-ttpci: The main driver for AV7110 based, full-featured
DVB-S/C/T cards
eof
.. -*- coding: utf-8; mode: rst -*-
.. include:: <isonum.txt>
##############################################
Linux Digital TV driver-specific documentation
##############################################
**Copyright** |copy| 2001-2016 : LinuxTV Developers
This documentation is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation version 2 of the License.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
For more details see the file COPYING in the source distribution of Linux.
.. class:: toc-title
Table of Contents
.. toctree::
:maxdepth: 5
:numbered:
intro
avermedia
bt8xx
cards
ci
dvb-usb
faq
lmedm04
opera-firmware
technisat
ttusb-dec
udev
contributors
Introdution
===========
The main development site and GIT repository for these
drivers is https://linuxtv.org.
The DVB mailing list linux-dvb is hosted at vger. Please see
http://vger.kernel.org/vger-lists.html#linux-media for details.
There are also some other old lists hosted at https://linuxtv.org/lists.php. Please check the archive https://linuxtv.org/pipermail/linux-dvb/.
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.
Please check it before asking newbie questions on the list.
API documentation is documented at the Kernel. You'll also find useful
documentation at: https://linuxtv.org/docs.php.
You may also find useful material at https://linuxtv.org/downloads/.
In order to get firmware from proprietary drivers, there's a script at
the kernel tree, at scripts/get_dvb_firmware.
Firmware files for lmedm04 cards
================================
To extract firmware for the DM04/QQBOX you need to copy the
following file(s) to this directory.
for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
For DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
-------------------------------------------
The Sharp 7395 driver can be found in windows/system32/drivers
......@@ -9,38 +12,43 @@ The Sharp 7395 driver can be found in windows/system32/drivers
US2A0D.sys (dated 17 Mar 2009)
and run
./get_dvb_firmware lme2510c_s7395
and run:
.. code-block:: none
scripts/get_dvb_firmware lme2510c_s7395
will produce
dvb-usb-lme2510c-s7395.fw
will produce dvb-usb-lme2510c-s7395.fw
An alternative but older firmware can be found on the driver
disk DVB-S_EN_3.5A in BDADriver/driver
LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)
and run
./get_dvb_firmware lme2510c_s7395_old
and run:
will produce
dvb-usb-lme2510c-s7395.fw
.. code-block:: none
--------------------------------------------------------------------
./get_dvb_firmware lme2510c_s7395_old
will produce dvb-usb-lme2510c-s7395.fw
The LG firmware can be found on the driver
disk DM04+_5.1A[LG] in BDADriver/driver
for DM04 LME2510 (LG Tuner)
For DM04 LME2510 (LG Tuner)
---------------------------
LMEBDA_DVBS.sys (dated 13 Nov 2007)
and run
./get_dvb_firmware lme2510_lg
and run:
will produce
dvb-usb-lme2510-lg.fw
.. code-block:: none
./get_dvb_firmware lme2510_lg
will produce dvb-usb-lme2510-lg.fw
Other LG firmware can be extracted manually from US280D.sys
......@@ -48,34 +56,50 @@ only found in windows/system32/drivers
dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw
for DM04 LME2510C (LG Tuner)
---------------------------
For DM04 LME2510C (LG Tuner)
----------------------------
dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
.. code-block:: none
dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
---------------------------------------------------------------------
The Sharp 0194 tuner driver can be found in windows/system32/drivers
US290D.sys (dated 09 Apr 2009)
For LME2510
dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw
-----------
.. code-block:: none
dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw
For LME2510C
dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw
------------
.. code-block:: none
dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw
---------------------------------------------------------------------
The m88rs2000 tuner driver can be found in windows/system32/drivers
US2B0D.sys (dated 29 Jun 2010)
dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw
.. code-block:: none
dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw
We need to modify id of rs2000 firmware or it will warm boot id 3344:1120.
echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw
.. code-block:: none
echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw
Copy the firmware file(s) to /lib/firmware
Opera firmware
==============
Author: Marco Gittler <g.marco@freenet.de>
To extract the firmware for the Opera DVB-S1 USB-Box
you need to copy the files:
......@@ -6,9 +11,11 @@ you need to copy the files:
from the windriver disk into this directory.
Then run
Then run:
.. code-block:: none
./get_dvb_firmware opera1
scripts/get_dvb_firmware opera1
and after that you have 2 files:
......@@ -22,6 +29,3 @@ Copy them into /lib/firmware/ .
After that the driver can load the firmware
(if you have enabled firmware loading
in kernel config and have hotplug running).
Marco Gittler <g.marco@freenet.de>
How to set up the Technisat/B2C2 Flexcop devices
================================================
.. note::
This documentation is outdated.
Author: Uwe Bugla <uwe.bugla@gmx.de> August 2009
Find out what device you have
-----------------------------
Important Notice: The driver does NOT support Technisat USB 2 devices!
First start your linux box with a shipped kernel:
.. code-block:: none
lspci -vvv for a PCI device (lsusb -vvv for an USB device) will show you for example:
02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip /
Technisat SkyStar2 DVB card (rev 02)
dmesg | grep frontend may show you for example:
DVB: registering frontend 0 (Conexant CX24123/CX24109)...
Kernel compilation:
-------------------
If the Flexcop / Technisat is the only DVB / TV / Radio device in your box
get rid of unnecessary modules and check this one:
``Multimedia support`` => ``Customise analog and hybrid tuner modules to build``
In this directory uncheck every driver which is activated there
(except ``Simple tuner support`` for ATSC 3rd generation only -> see case 9 please).
Then please activate:
- Main module part:
``Multimedia support`` => ``DVB/ATSC adapters`` => ``Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters``
#) => ``Technisat/B2C2 Air/Sky/Cable2PC PCI`` (PCI card) or
#) => ``Technisat/B2C2 Air/Sky/Cable2PC USB`` (USB 1.1 adapter)
and for troubleshooting purposes:
#) => ``Enable debug for the B2C2 FlexCop drivers``
- Frontend / Tuner / Demodulator module part:
``Multimedia support`` => ``DVB/ATSC adapters``
=> ``Customise the frontend modules to build`` ``Customise DVB frontends`` =>
- SkyStar DVB-S Revision 2.3:
#) => ``Zarlink VP310/MT312/ZL10313 based``
#) => ``Generic I2C PLL based tuners``
- SkyStar DVB-S Revision 2.6:
#) => ``ST STV0299 based``
#) => ``Generic I2C PLL based tuners``
- SkyStar DVB-S Revision 2.7:
#) => ``Samsung S5H1420 based``
#) => ``Integrant ITD1000 Zero IF tuner for DVB-S/DSS``
#) => ``ISL6421 SEC controller``
- SkyStar DVB-S Revision 2.8:
#) => ``Conexant CX24123 based``
#) => ``Conexant CX24113/CX24128 tuner for DVB-S/DSS``
#) => ``ISL6421 SEC controller``
- AirStar DVB-T card:
#) => ``Zarlink MT352 based``
#) => ``Generic I2C PLL based tuners``
- CableStar DVB-C card:
#) => ``ST STV0297 based``
#) => ``Generic I2C PLL based tuners``
- AirStar ATSC card 1st generation:
#) => ``Broadcom BCM3510``
- AirStar ATSC card 2nd generation:
#) => ``NxtWave Communications NXT2002/NXT2004 based``
#) => ``Generic I2C PLL based tuners``
- AirStar ATSC card 3rd generation:
#) => ``LG Electronics LGDT3302/LGDT3303 based``
#) ``Multimedia support`` => ``Customise analog and hybrid tuner modules to build`` => ``Simple tuner support``
......@@ -5,41 +5,39 @@ Driver Status
-------------
Supported:
DEC2000-t
DEC2450-t
DEC3000-s
Linux Kernels 2.4 and 2.6
Video Streaming
Audio Streaming
Section Filters
Channel Zapping
Hotplug firmware loader under 2.6 kernels
- DEC2000-t
- DEC2450-t
- DEC3000-s
- Video Streaming
- Audio Streaming
- Section Filters
- Channel Zapping
- Hotplug firmware loader
To Do:
Tuner status information
DVB network interface
Streaming video PC->DEC
Conax support for 2450-t
- Tuner status information
- DVB network interface
- Streaming video PC->DEC
- Conax support for 2450-t
Getting the Firmware
--------------------
To download the firmware, use the following commands:
"get_dvb_firmware dec2000t"
"get_dvb_firmware dec2540t"
"get_dvb_firmware dec3000s"
.. code-block:: none
Compilation Notes for 2.4 kernels
---------------------------------
For 2.4 kernels the firmware for the DECs is compiled into the driver itself.
scripts/get_dvb_firmware dec2000t
scripts/get_dvb_firmware dec2540t
scripts/get_dvb_firmware dec3000s
Copy the three files downloaded above into the build-2.4 directory.
Hotplug Firmware Loading
------------------------
Hotplug Firmware Loading for 2.6 kernels
----------------------------------------
For 2.6 kernels the firmware is loaded at the point that the driver module is
loaded. See linux/Documentation/dvb/firmware.txt for more information.
Since 2.6 kernels, the firmware is loaded at the point that the driver module
is loaded.
Copy the three files downloaded above into the /usr/lib/hotplug/firmware or
/lib/firmware directory (depending on configuration of firmware hotplug).
UDEV rules for DVB
==================
.. note::
#) This documentation is outdated. Udev on modern distributions auto-detect
the DVB devices.
#) **TODO:** change this document to explain how to make DVB devices
persistent, as, when a machine has multiple devices, they may be detected
on different orders, which could cause apps that relies on the device
numbers to fail.
The DVB subsystem currently registers to the sysfs subsystem using the
"class_simple" interface.
This means that only the basic information like module loading parameters
are presented through sysfs. Other things that might be interesting are
currently *not* available.
currently **not** available.
Nevertheless it's now possible to add proper udev rules so that the
DVB device nodes are created automatically.
......@@ -21,10 +34,11 @@ The script should be called "dvb.sh" and should be placed into a script
dir where udev can execute it, most likely /etc/udev/scripts/
So, create a new file /etc/udev/scripts/dvb.sh and add the following:
------------------------------schnipp------------------------------------------------
#!/bin/sh
/bin/echo $1 | /bin/sed -e 's,dvb\([0-9]\)\.\([^0-9]*\)\([0-9]\),dvb/adapter\1/\2\3,'
------------------------------schnipp------------------------------------------------
.. code-block:: none
#!/bin/sh
/bin/echo $1 | /bin/sed -e 's,dvb\([0-9]\)\.\([^0-9]*\)\([0-9]\),dvb/adapter\1/\2\3,'
Don't forget to make the script executable with "chmod".
......@@ -34,9 +48,10 @@ directory for rule files. The main udev configuration file /etc/udev/udev.conf
will tell you the directory where the rules are, most likely it's /etc/udev/rules.d/
Create a new rule file in that directory called "dvb.rule" and add the following line:
------------------------------schnipp------------------------------------------------
KERNEL="dvb*", PROGRAM="/etc/udev/scripts/dvb.sh %k", NAME="%c"
------------------------------schnipp------------------------------------------------
.. code-block:: none
KERNEL="dvb*", PROGRAM="/etc/udev/scripts/dvb.sh %k", NAME="%c"
If you want more control over the device nodes (for example a special group membership)
have a look at "man udev".
......
# Ignore header name
ignore define _DVBFRONTEND_H_
# Group layer A-C symbols together
replace define DTV_ISDBT_LAYERA_FEC dtv-isdbt-layer-fec
replace define DTV_ISDBT_LAYERB_FEC dtv-isdbt-layer-fec
replace define DTV_ISDBT_LAYERC_FEC dtv-isdbt-layer-fec
replace define DTV_ISDBT_LAYERA_MODULATION dtv-isdbt-layer-modulation
replace define DTV_ISDBT_LAYERB_MODULATION dtv-isdbt-layer-modulation
replace define DTV_ISDBT_LAYERC_MODULATION dtv-isdbt-layer-modulation
replace define DTV_ISDBT_LAYERA_SEGMENT_COUNT dtv-isdbt-layer-segment-count
replace define DTV_ISDBT_LAYERB_SEGMENT_COUNT dtv-isdbt-layer-segment-count
replace define DTV_ISDBT_LAYERC_SEGMENT_COUNT dtv-isdbt-layer-segment-count
replace define DTV_ISDBT_LAYERA_TIME_INTERLEAVING dtv-isdbt-layer-time-interleaving
replace define DTV_ISDBT_LAYERB_TIME_INTERLEAVING dtv-isdbt-layer-time-interleaving
replace define DTV_ISDBT_LAYERC_TIME_INTERLEAVING dtv-isdbt-layer-time-interleaving
# Ignore legacy defines
ignore define DTV_ISDBS_TS_ID_LEGACY
ignore define SYS_DVBC_ANNEX_AC
ignore define SYS_DMBTH
# Ignore limits
ignore define DTV_MAX_COMMAND
ignore define MAX_DTV_STATS
ignore define DTV_IOCTL_MAX_MSGS
# Stats enum is documented altogether
replace enum fecap_scale_params frontend-stat-properties
replace symbol FE_SCALE_COUNTER frontend-stat-properties
replace symbol FE_SCALE_DECIBEL frontend-stat-properties
replace symbol FE_SCALE_NOT_AVAILABLE frontend-stat-properties
replace symbol FE_SCALE_RELATIVE frontend-stat-properties
# the same reference is used for both get and set ioctls
replace ioctl FE_SET_PROPERTY FE_GET_PROPERTY
# Ignore struct used only internally at Kernel
ignore struct dtv_cmds_h
# Typedefs that use the enum reference
replace typedef fe_sec_voltage_t fe-sec-voltage
# Replaces for flag constants
replace define FE_TUNE_MODE_ONESHOT fe_set_frontend_tune_mode
replace define LNA_AUTO dtv-lna
replace define NO_STREAM_ID_FILTER dtv-stream-id
.. -*- coding: utf-8; mode: rst -*-
============
Introduction
============
This document covers the Linux Kernel to Userspace API's used by video
and radio streaming devices, including video cameras, analog and digital
TV receiver cards, AM/FM receiver cards, Software Defined Radio (SDR),
streaming capture and output devices, codec devices and remote controllers.
A typical media device hardware is shown at :ref:`typical_media_device`.
.. _typical_media_device:
.. figure:: media_api_files/typical_media_device.*
:alt: typical_media_device.svg
:align: center
Typical Media Device
The media infrastructure API was designed to control such devices. It is
divided into five parts.
1. The :ref:`first part <v4l2spec>` covers radio, video capture and output,
cameras, analog TV devices and codecs.
2. The :ref:`second part <dvbapi>` covers the API used for digital TV and
Internet reception via one of the several digital tv standards. While it is
called as DVB API, in fact it covers several different video standards
including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S, DTMB, etc. The
complete list of supported standards can be found at
:ref:`fe-delivery-system-t`.
3. The :ref:`third part <remote_controllers>` covers the Remote Controller API.
4. The :ref:`fourth part <media_controller>` covers the Media Controller API.
5. The :ref:`fifth part <cec>` covers the CEC (Consumer Electronics Control) API.
It should also be noted that a media device may also have audio components, like
mixers, PCM capture, PCM playback, etc, which are controlled via ALSA API. For
additional information and for the latest development code, see:
`https://linuxtv.org <https://linuxtv.org>`__. For discussing improvements,
reporting troubles, sending new drivers, etc, please mail to: `Linux Media
Mailing List (LMML) <http://vger.kernel.org/vger-lists.html#linux-media>`__.
Digital TV (DVB) devices
------------------------
Digital TV Common functions
---------------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
:export: drivers/media/dvb-core/dvb_math.c
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
:export: drivers/media/dvb-core/dvbdev.c
Digital TV Frontend kABI
------------------------
Digital TV Frontend
~~~~~~~~~~~~~~~~~~~
The Digital TV Frontend kABI defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware independent
frontend layer. It is only of interest for Digital TV device driver writers.
The header file for this API is named dvb_frontend.h and located in
drivers/media/dvb-core.
Before using the Digital TV frontend core, the bridge driver should attach
the frontend demod, tuner and SEC devices and call
:c:func:`dvb_register_frontend()`,
in order to register the new frontend at the subsystem. At device
detach/removal, the bridge driver should call
:c:func:`dvb_unregister_frontend()` to
remove the frontend from the core and then :c:func:`dvb_frontend_detach()`
to free the memory allocated by the frontend drivers.
The drivers should also call :c:func:`dvb_frontend_suspend()` as part of
their handler for the :c:type:`device_driver`.\ ``suspend()``, and
:c:func:`dvb_frontend_resume()` as
part of their handler for :c:type:`device_driver`.\ ``resume()``.
A few other optional functions are provided to handle some special cases.
.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h
Digital TV Demux kABI
---------------------
Digital TV Demux
~~~~~~~~~~~~~~~~
The Kernel Digital TV Demux kABI defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware independent
demux layer. It is only of interest for Digital TV device driver writers.
The header file for this kABI is named demux.h and located in
drivers/media/dvb-core.
The demux kABI should be implemented for each demux in the system. It is
used to select the TS source of a demux and to manage the demux resources.
When the demux client allocates a resource via the demux kABI, it receives
a pointer to the kABI of that resource.
Each demux receives its TS input from a DVB front-end or from memory, as
set via this demux kABI. In a system with more than one front-end, the kABI
can be used to select one of the DVB front-ends as a TS source for a demux,
unless this is fixed in the HW platform.
The demux kABI only controls front-ends regarding to their connections with
demuxes; the kABI used to set the other front-end parameters, such as
tuning, are devined via the Digital TV Frontend kABI.
The functions that implement the abstract interface demux should be defined
static or module private and registered to the Demux core for external
access. It is not necessary to implement every function in the struct
&dmx_demux. For example, a demux interface might support Section filtering,
but not PES filtering. The kABI client is expected to check the value of any
function pointer before calling the function: the value of ``NULL`` means
that the function is not available.
Whenever the functions of the demux API modify shared data, the
possibilities of lost update and race condition problems should be
addressed, e.g. by protecting parts of code with mutexes.
Note that functions called from a bottom half context must not sleep.
Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a
kernel thread being put to sleep if swapping is needed. For example, the
Linux Kernel calls the functions of a network device interface from a
bottom half context. Thus, if a demux kABI function is called from network
device code, the function must not sleep.
Demux Callback API
------------------
Demux Callback
~~~~~~~~~~~~~~
This kernel-space API comprises the callback functions that deliver filtered
data to the demux client. Unlike the other DVB kABIs, these functions are
provided by the client and called from the demux code.
The function pointers of this abstract interface are not packed into a
structure as in the other demux APIs, because the callback functions are
registered and used independent of each other. As an example, it is possible
for the API client to provide several callback functions for receiving TS
packets and no callbacks for PES packets or sections.
The functions that implement the callback API need not be re-entrant: when
a demux driver calls one of these functions, the driver is not allowed to
call the function again before the original call returns. If a callback is
triggered by a hardware interrupt, it is recommended to use the Linux
bottom half mechanism or start a tasklet instead of making the callback
function call directly from a hardware interrupt.
This mechanism is implemented by :c:func:`dmx_ts_cb()` and :cpp:func:`dmx_section_cb()`
callbacks.
.. kernel-doc:: drivers/media/dvb-core/demux.h
Digital TV Conditional Access kABI
----------------------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
Media Controller devices
------------------------
Media Controller
~~~~~~~~~~~~~~~~
The media controller userspace API is documented in
:ref:`the Media Controller uAPI book <media_controller>`. This document focus
on the kernel-side implementation of the media framework.
Abstract media device model
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Discovering a device internal topology, and configuring it at runtime, is one
of the goals of the media framework. To achieve this, hardware devices are
modelled as an oriented graph of building blocks called entities connected
through pads.
An entity is a basic media hardware building block. It can correspond to
a large variety of logical blocks such as physical hardware devices
(CMOS sensor for instance), logical hardware devices (a building block
in a System-on-Chip image processing pipeline), DMA channels or physical
connectors.
A pad is a connection endpoint through which an entity can interact with
other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should
not be confused with physical pins at chip boundaries.
A link is a point-to-point oriented connection between two pads, either
on the same entity or on different entities. Data flows from a source
pad to a sink pad.
Media device
^^^^^^^^^^^^
A media device is represented by a :c:type:`struct media_device <media_device>`
instance, defined in ``include/media/media-device.h``.
Allocation of the structure is handled by the media device driver, usually by
embedding the :c:type:`media_device` instance in a larger driver-specific
structure.
Drivers register media device instances by calling
:c:func:`__media_device_register()` via the macro ``media_device_register()``
and unregistered by calling :c:func:`media_device_unregister()`.
Entities
^^^^^^^^
Entities are represented by a :c:type:`struct media_entity <media_entity>`
instance, defined in ``include/media/media-entity.h``. The structure is usually
embedded into a higher-level structure, such as
:c:type:`v4l2_subdev` or :c:type:`video_device`
instances, although drivers can allocate entities directly.
Drivers initialize entity pads by calling
:c:func:`media_entity_pads_init()`.
Drivers register entities with a media device by calling
:c:func:`media_device_register_entity()`
and unregistred by calling
:c:func:`media_device_unregister_entity()`.
Interfaces
^^^^^^^^^^
Interfaces are represented by a
:c:type:`struct media_interface <media_interface>` instance, defined in
``include/media/media-entity.h``. Currently, only one type of interface is
defined: a device node. Such interfaces are represented by a
:c:type:`struct media_intf_devnode <media_intf_devnode>`.
Drivers initialize and create device node interfaces by calling
:c:func:`media_devnode_create()`
and remove them by calling:
:c:func:`media_devnode_remove()`.
Pads
^^^^
Pads are represented by a :c:type:`struct media_pad <media_pad>` instance,
defined in ``include/media/media-entity.h``. Each entity stores its pads in
a pads array managed by the entity driver. Drivers usually embed the array in
a driver-specific structure.
Pads are identified by their entity and their 0-based index in the pads
array.
Both information are stored in the :c:type:`struct media_pad`, making the
:c:type:`media_pad` pointer the canonical way to store and pass link references.
Pads have flags that describe the pad capabilities and state.
``MEDIA_PAD_FL_SINK`` indicates that the pad supports sinking data.
``MEDIA_PAD_FL_SOURCE`` indicates that the pad supports sourcing data.
.. note::
One and only one of ``MEDIA_PAD_FL_SINK`` or ``MEDIA_PAD_FL_SOURCE`` must
be set for each pad.
Links
^^^^^
Links are represented by a :c:type:`struct media_link <media_link>` instance,
defined in ``include/media/media-entity.h``. There are two types of links:
**1. pad to pad links**:
Associate two entities via their PADs. Each entity has a list that points
to all links originating at or targeting any of its pads.
A given link is thus stored twice, once in the source entity and once in
the target entity.
Drivers create pad to pad links by calling:
:c:func:`media_create_pad_link()` and remove with
:c:func:`media_entity_remove_links()`.
**2. interface to entity links**:
Associate one interface to a Link.
Drivers create interface to entity links by calling:
:c:func:`media_create_intf_link()` and remove with
:c:func:`media_remove_intf_links()`.
.. note::
Links can only be created after having both ends already created.
Links have flags that describe the link capabilities and state. The
valid values are described at :c:func:`media_create_pad_link()` and
:c:func:`media_create_intf_link()`.
Graph traversal
^^^^^^^^^^^^^^^
The media framework provides APIs to iterate over entities in a graph.
To iterate over all entities belonging to a media device, drivers can use
the media_device_for_each_entity macro, defined in
``include/media/media-device.h``.
.. code-block:: c
struct media_entity *entity;
media_device_for_each_entity(entity, mdev) {
// entity will point to each entity in turn
...
}
Drivers might also need to iterate over all entities in a graph that can be
reached only through enabled links starting at a given entity. The media
framework provides a depth-first graph traversal API for that purpose.
.. note::
Graphs with cycles (whether directed or undirected) are **NOT**
supported by the graph traversal API. To prevent infinite loops, the graph
traversal code limits the maximum depth to ``MEDIA_ENTITY_ENUM_MAX_DEPTH``,
currently defined as 16.
Drivers initiate a graph traversal by calling
:c:func:`media_entity_graph_walk_start()`
The graph structure, provided by the caller, is initialized to start graph
traversal at the given entity.
Drivers can then retrieve the next entity by calling
:c:func:`media_entity_graph_walk_next()`
When the graph traversal is complete the function will return ``NULL``.
Graph traversal can be interrupted at any moment. No cleanup function call
is required and the graph structure can be freed normally.
Helper functions can be used to find a link between two given pads, or a pad
connected to another pad through an enabled link
:c:func:`media_entity_find_link()` and
:c:func:`media_entity_remote_pad()`.
Use count and power handling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Due to the wide differences between drivers regarding power management
needs, the media controller does not implement power management. However,
the :c:type:`struct media_entity <media_entity>` includes a ``use_count``
field that media drivers
can use to track the number of users of every entity for power management
needs.
The :c:type:`media_entity<media_entity>`.\ ``use_count`` field is owned by
media drivers and must not be
touched by entity drivers. Access to the field must be protected by the
:c:type:`media_device`.\ ``graph_mutex`` lock.
Links setup
^^^^^^^^^^^
Link properties can be modified at runtime by calling
:c:func:`media_entity_setup_link()`.
Pipelines and media streams
^^^^^^^^^^^^^^^^^^^^^^^^^^^
When starting streaming, drivers must notify all entities in the pipeline to
prevent link states from being modified during streaming by calling
:c:func:`media_entity_pipeline_start()`.
The function will mark all entities connected to the given entity through
enabled links, either directly or indirectly, as streaming.
The :c:type:`struct media_pipeline <media_pipeline>` instance pointed to by
the pipe argument will be stored in every entity in the pipeline.
Drivers should embed the :c:type:`struct media_pipeline <media_pipeline>`
in higher-level pipeline structures and can then access the
pipeline through the :c:type:`struct media_entity <media_entity>`
pipe field.
Calls to :c:func:`media_entity_pipeline_start()` can be nested.
The pipeline pointer must be identical for all nested calls to the function.
:c:func:`media_entity_pipeline_start()` may return an error. In that case,
it will clean up any of the changes it did by itself.
When stopping the stream, drivers must notify the entities with
:c:func:`media_entity_pipeline_stop()`.
If multiple calls to :c:func:`media_entity_pipeline_start()` have been
made the same number of :c:func:`media_entity_pipeline_stop()` calls
are required to stop streaming.
The :c:type:`media_entity`.\ ``pipe`` field is reset to ``NULL`` on the last
nested stop call.
Link configuration will fail with ``-EBUSY`` by default if either end of the
link is a streaming entity. Links that can be modified while streaming must
be marked with the ``MEDIA_LNK_FL_DYNAMIC`` flag.
If other operations need to be disallowed on streaming entities (such as
changing entities configuration parameters) drivers can explicitly check the
media_entity stream_count field to find out if an entity is streaming. This
operation must be done with the media_device graph_mutex held.
Link validation
^^^^^^^^^^^^^^^
Link validation is performed by :c:func:`media_entity_pipeline_start()`
for any entity which has sink pads in the pipeline. The
:c:type:`media_entity`.\ ``link_validate()`` callback is used for that
purpose. In ``link_validate()`` callback, entity driver should check
that the properties of the source pad of the connected entity and its own
sink pad match. It is up to the type of the entity (and in the end, the
properties of the hardware) what matching actually means.
Subsystems should facilitate link validation by providing subsystem specific
helper functions to provide easy access for commonly needed information, and
in the end provide a way to use driver-specific callbacks.
.. kernel-doc:: include/media/media-device.h
.. kernel-doc:: include/media/media-devnode.h
.. kernel-doc:: include/media/media-entity.h
Remote Controller devices
-------------------------
Remote Controller core
~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: include/media/rc-core.h
.. kernel-doc:: include/media/rc-map.h
LIRC
~~~~
.. kernel-doc:: include/media/lirc_dev.h
V4L2 clocks
-----------
.. attention::
This is a temporary API and it shall be replaced by the generic
clock API, when the latter becomes widely available.
Many subdevices, like camera sensors, TV decoders and encoders, need a clock
signal to be supplied by the system. Often this clock is supplied by the
respective bridge device. The Linux kernel provides a Common Clock Framework for
this purpose. However, it is not (yet) available on all architectures. Besides,
the nature of the multi-functional (clock, data + synchronisation, I2C control)
connection of subdevices to the system might impose special requirements on the
clock API usage. E.g. V4L2 has to support clock provider driver unregistration
while a subdevice driver is holding a reference to the clock. For these reasons
a V4L2 clock helper API has been developed and is provided to bridge and
subdevice drivers.
The API consists of two parts: two functions to register and unregister a V4L2
clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
a clock object, similar to the respective generic clock API calls:
v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(),
v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide
clock operations that will be called when clock users invoke respective API
methods.
It is expected that once the CCF becomes available on all relevant
architectures this API will be removed.
V4L2 common functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-common.h
.. kernel-doc:: include/media/v4l2-ioctl.h
Video2Linux devices
-------------------
.. toctree::
:maxdepth: 1
v4l2-intro
v4l2-dev
v4l2-device
v4l2-fh
v4l2-subdev
v4l2-event
v4l2-controls
v4l2-videobuf
v4l2-videobuf2
v4l2-clocks
v4l2-dv-timings
v4l2-flash-led-class
v4l2-mc
v4l2-mediabus
v4l2-mem2mem
v4l2-of
v4l2-rect
v4l2-tuner
v4l2-common
v4l2-tveeprom
This diff is collapsed.
V4L2 device instance
--------------------
Each device instance is represented by a struct :c:type:`v4l2_device`.
Very simple devices can just allocate this struct, but most of the time you
would embed this struct inside a larger struct.
You must register the device instance by calling:
:c:func:`v4l2_device_register <v4l2_device_register>`
(dev, :c:type:`v4l2_dev <v4l2_device>`).
Registration will initialize the :c:type:`v4l2_device` struct. If the
dev->driver_data field is ``NULL``, it will be linked to
:c:type:`v4l2_dev <v4l2_device>` argument.
Drivers that want integration with the media device framework need to set
dev->driver_data manually to point to the driver-specific device structure
that embed the struct :c:type:`v4l2_device` instance. This is achieved by a
``dev_set_drvdata()`` call before registering the V4L2 device instance.
They must also set the struct :c:type:`v4l2_device` mdev field to point to a
properly initialized and registered :c:type:`media_device` instance.
If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a
value derived from dev (driver name followed by the bus_id, to be precise).
If you set it up before calling :c:func:`v4l2_device_register` then it will
be untouched. If dev is ``NULL``, then you **must** setup
:c:type:`v4l2_dev <v4l2_device>`\ ->name before calling
:c:func:`v4l2_device_register`.
You can use :c:func:`v4l2_device_set_name` to set the name based on a driver
name and a driver-global atomic_t instance. This will generate names like
``ivtv0``, ``ivtv1``, etc. If the name ends with a digit, then it will insert
a dash: ``cx18-0``, ``cx18-1``, etc. This function returns the instance number.
The first ``dev`` argument is normally the ``struct device`` pointer of a
``pci_dev``, ``usb_interface`` or ``platform_device``. It is rare for dev to
be ``NULL``, but it happens with ISA devices or when one device creates
multiple PCI devices, thus making it impossible to associate
:c:type:`v4l2_dev <v4l2_device>` with a particular parent.
You can also supply a ``notify()`` callback that can be called by sub-devices
to notify you of events. Whether you need to set this depends on the
sub-device. Any notifications a sub-device supports must be defined in a header
in ``include/media/subdevice.h``.
V4L2 devices are unregistered by calling:
:c:func:`v4l2_device_unregister`
(:c:type:`v4l2_dev <v4l2_device>`).
If the dev->driver_data field points to :c:type:`v4l2_dev <v4l2_device>`,
it will be reset to ``NULL``. Unregistering will also automatically unregister
all subdevs from the device.
If you have a hotpluggable device (e.g. a USB device), then when a disconnect
happens the parent device becomes invalid. Since :c:type:`v4l2_device` has a
pointer to that parent device it has to be cleared as well to mark that the
parent is gone. To do this call:
:c:func:`v4l2_device_disconnect`
(:c:type:`v4l2_dev <v4l2_device>`).
This does *not* unregister the subdevs, so you still need to call the
:c:func:`v4l2_device_unregister` function for that. If your driver is not
hotpluggable, then there is no need to call :c:func:`v4l2_device_disconnect`.
Sometimes you need to iterate over all devices registered by a specific
driver. This is usually the case if multiple device drivers use the same
hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv
hardware. The same is true for alsa drivers for example.
You can iterate over all registered devices as follows:
.. code-block:: c
static int callback(struct device *dev, void *p)
{
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
/* test if this device was inited */
if (v4l2_dev == NULL)
return 0;
...
return 0;
}
int iterate(void *p)
{
struct device_driver *drv;
int err;
/* Find driver 'ivtv' on the PCI bus.
pci_bus_type is a global. For USB busses use usb_bus_type. */
drv = driver_find("ivtv", &pci_bus_type);
/* iterate over all ivtv device instances */
err = driver_for_each_device(drv, NULL, p, callback);
put_driver(drv);
return err;
}
Sometimes you need to keep a running counter of the device instance. This is
commonly used to map a device instance to an index of a module option array.
The recommended approach is as follows:
.. code-block:: c
static atomic_t drv_instance = ATOMIC_INIT(0);
static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id)
{
...
state->instance = atomic_inc_return(&drv_instance) - 1;
}
If you have multiple device nodes then it can be difficult to know when it is
safe to unregister :c:type:`v4l2_device` for hotpluggable devices. For this
purpose :c:type:`v4l2_device` has refcounting support. The refcount is
increased whenever :c:func:`video_register_device` is called and it is
decreased whenever that device node is released. When the refcount reaches
zero, then the :c:type:`v4l2_device` release() callback is called. You can
do your final cleanup there.
If other device nodes (e.g. ALSA) are created, then you can increase and
decrease the refcount manually as well by calling:
:c:func:`v4l2_device_get`
(:c:type:`v4l2_dev <v4l2_device>`).
or:
:c:func:`v4l2_device_put`
(:c:type:`v4l2_dev <v4l2_device>`).
Since the initial refcount is 1 you also need to call
:c:func:`v4l2_device_put` in the ``disconnect()`` callback (for USB devices)
or in the ``remove()`` callback (for e.g. PCI devices), otherwise the refcount
will never reach 0.
v4l2_device functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-device.h
V4L2 DV Timings functions
^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-dv-timings.h
V4L2 events
-----------
The V4L2 events provide a generic way to pass events to user space.
The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events.
Events are defined by a type and an optional ID. The ID may refer to a V4L2
object such as a control ID. If unused, then the ID is 0.
When the user subscribes to an event the driver will allocate a number of
kevent structs for that event. So every (type, ID) event tuple will have
its own set of kevent structs. This guarantees that if a driver is generating
lots of events of one type in a short time, then that will not overwrite
events of another type.
But if you get more events of one type than the number of kevents that were
reserved, then the oldest event will be dropped and the new one added.
Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has
``merge()`` and ``replace()`` callbacks which drivers can set. These
callbacks are called when a new event is raised and there is no more room.
The ``replace()`` callback allows you to replace the payload of the old event
with that of the new event, merging any relevant data from the old payload
into the new payload that replaces it. It is called when this event type has
only one kevent struct allocated. The ``merge()`` callback allows you to merge
the oldest event payload into that of the second-oldest event payload. It is
called when there are two or more kevent structs allocated.
This way no status information is lost, just the intermediate steps leading
up to that state.
A good example of these ``replace``/``merge`` callbacks is in v4l2-event.c:
``ctrls_replace()`` and ``ctrls_merge()`` callbacks for the control event.
.. note::
these callbacks can be called from interrupt context, so they must
be fast.
In order to queue events to video device, drivers should call:
:c:func:`v4l2_event_queue <v4l2_event_queue>`
(:c:type:`vdev <video_device>`, :ref:`ev <v4l2-event>`)
The driver's only responsibility is to fill in the type and the data fields.
The other fields will be filled in by V4L2.
Event subscription
~~~~~~~~~~~~~~~~~~
Subscribing to an event is via:
:c:func:`v4l2_event_subscribe <v4l2_event_subscribe>`
(:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>` ,
elems, :c:type:`ops <v4l2_subscribed_event_ops>`)
This function is used to implement :c:type:`video_device`->
:c:type:`ioctl_ops <v4l2_ioctl_ops>`-> ``vidioc_subscribe_event``,
but the driver must check first if the driver is able to produce events
with specified event id, and then should call
:c:func:`v4l2_event_subscribe` to subscribe the event.
The elems argument is the size of the event queue for this event. If it is 0,
then the framework will fill in a default value (this depends on the event
type).
The ops argument allows the driver to specify a number of callbacks:
======== ==============================================================
Callback Description
======== ==============================================================
add called when a new listener gets added (subscribing to the same
event twice will only cause this callback to get called once)
del called when a listener stops listening
replace replace event 'old' with event 'new'.
merge merge event 'old' into event 'new'.
======== ==============================================================
All 4 callbacks are optional, if you don't want to specify any callbacks
the ops argument itself maybe ``NULL``.
Unsubscribing an event
~~~~~~~~~~~~~~~~~~~~~~
Unsubscribing to an event is via:
:c:func:`v4l2_event_unsubscribe <v4l2_event_unsubscribe>`
(:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>`)
This function is used to implement :c:type:`video_device`->
:c:type:`ioctl_ops <v4l2_ioctl_ops>`-> ``vidioc_unsubscribe_event``.
A driver may call :c:func:`v4l2_event_unsubscribe` directly unless it
wants to be involved in unsubscription process.
The special type ``V4L2_EVENT_ALL`` may be used to unsubscribe all events. The
drivers may want to handle this in a special way.
Check if there's a pending event
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking if there's a pending event is via:
:c:func:`v4l2_event_pending <v4l2_event_pending>`
(:c:type:`fh <v4l2_fh>`)
This function returns the number of pending events. Useful when implementing
poll.
How events work
~~~~~~~~~~~~~~~
Events are delivered to user space through the poll system call. The driver
can use :c:type:`v4l2_fh`->wait (a wait_queue_head_t) as the argument for
``poll_wait()``.
There are standard and private events. New standard events must use the
smallest available event type. The drivers must allocate their events from
their own class starting from class base. Class base is
``V4L2_EVENT_PRIVATE_START`` + n * 1000 where n is the lowest available number.
The first event type in the class is reserved for future use, so the first
available event type is 'class base + 1'.
An example on how the V4L2 events may be used can be found in the OMAP
3 ISP driver (``drivers/media/platform/omap3isp``).
A subdev can directly send an event to the :c:type:`v4l2_device` notify
function with ``V4L2_DEVICE_NOTIFY_EVENT``. This allows the bridge to map
the subdev that sends the event to the video node(s) associated with the
subdev that need to be informed about such an event.
V4L2 event functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-event.h
V4L2 File handlers
------------------
struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific
data that is used by the V4L2 framework.
.. attention::
New drivers must use struct :c:type:`v4l2_fh`
since it is also used to implement priority handling
(:ref:`VIDIOC_G_PRIORITY`).
The users of :c:type:`v4l2_fh` (in the V4L2 framework, not the driver) know
whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer
by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags.
This bit is set whenever :c:func:`v4l2_fh_init` is called.
struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle
structure and ``file->private_data`` is set to it in the driver's ``open()``
function by the driver.
In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger
structure. In that case you should call:
#) :c:func:`v4l2_fh_init` and :cpp:func:`v4l2_fh_add` in ``open()``
#) :c:func:`v4l2_fh_del` and :cpp:func:`v4l2_fh_exit` in ``release()``
Drivers can extract their own file handle structure by using the container_of
macro.
Example:
.. code-block:: c
struct my_fh {
int blah;
struct v4l2_fh fh;
};
...
int my_open(struct file *file)
{
struct my_fh *my_fh;
struct video_device *vfd;
int ret;
...
my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL);
...
v4l2_fh_init(&my_fh->fh, vfd);
...
file->private_data = &my_fh->fh;
v4l2_fh_add(&my_fh->fh);
return 0;
}
int my_release(struct file *file)
{
struct v4l2_fh *fh = file->private_data;
struct my_fh *my_fh = container_of(fh, struct my_fh, fh);
...
v4l2_fh_del(&my_fh->fh);
v4l2_fh_exit(&my_fh->fh);
kfree(my_fh);
return 0;
}
Below is a short description of the :c:type:`v4l2_fh` functions used:
:c:func:`v4l2_fh_init <v4l2_fh_init>`
(:c:type:`fh <v4l2_fh>`, :c:type:`vdev <video_device>`)
- Initialise the file handle. This **MUST** be performed in the driver's
:c:type:`v4l2_file_operations`->open() handler.
:c:func:`v4l2_fh_add <v4l2_fh_add>`
(:c:type:`fh <v4l2_fh>`)
- Add a :c:type:`v4l2_fh` to :c:type:`video_device` file handle list.
Must be called once the file handle is completely initialized.
:c:func:`v4l2_fh_del <v4l2_fh_del>`
(:c:type:`fh <v4l2_fh>`)
- Unassociate the file handle from :c:type:`video_device`. The file handle
exit function may now be called.
:c:func:`v4l2_fh_exit <v4l2_fh_exit>`
(:c:type:`fh <v4l2_fh>`)
- Uninitialise the file handle. After uninitialisation the :c:type:`v4l2_fh`
memory can be freed.
If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions:
:c:func:`v4l2_fh_open <v4l2_fh_open>`
(struct file \*filp)
- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to
the struct :c:type:`video_device` associated with the file struct.
:c:func:`v4l2_fh_release <v4l2_fh_release>`
(struct file \*filp)
- This deletes it from the struct :c:type:`video_device` associated with the
file struct, uninitialised the :c:type:`v4l2_fh` and frees it.
These two functions can be plugged into the v4l2_file_operation's ``open()``
and ``release()`` ops.
Several drivers need to do something when the first file handle is opened and
when the last file handle closes. Two helper functions were added to check
whether the :c:type:`v4l2_fh` struct is the only open filehandle of the
associated device node:
:c:func:`v4l2_fh_is_singular <v4l2_fh_is_singular>`
(:c:type:`fh <v4l2_fh>`)
- Returns 1 if the file handle is the only open file handle, else 0.
:c:func:`v4l2_fh_is_singular_file <v4l2_fh_is_singular_file>`
(struct file \*filp)
- Same, but it calls v4l2_fh_is_singular with filp->private_data.
V4L2 fh functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-fh.h
V4L2 flash functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-flash-led-class.h
Introduction
------------
The V4L2 drivers tend to be very complex due to the complexity of the
hardware: most devices have multiple ICs, export multiple device nodes in
/dev, and create also non-V4L2 devices such as DVB, ALSA, FB, I2C and input
(IR) devices.
Especially the fact that V4L2 drivers have to setup supporting ICs to
do audio/video muxing/encoding/decoding makes it more complex than most.
Usually these ICs are connected to the main bridge driver through one or
more I2C busses, but other busses can also be used. Such devices are
called 'sub-devices'.
For a long time the framework was limited to the video_device struct for
creating V4L device nodes and video_buf for handling the video buffers
(note that this document does not discuss the video_buf framework).
This meant that all drivers had to do the setup of device instances and
connecting to sub-devices themselves. Some of this is quite complicated
to do right and many drivers never did do it correctly.
There is also a lot of common code that could never be refactored due to
the lack of a framework.
So this framework sets up the basic building blocks that all drivers
need and this same framework should make it much easier to refactor
common code into utility functions shared by all drivers.
A good example to look at as a reference is the v4l2-pci-skeleton.c
source that is available in samples/v4l/. It is a skeleton driver for
a PCI capture card, and demonstrates how to use the V4L2 driver
framework. It can be used as a template for real PCI video capture driver.
Structure of a V4L driver
-------------------------
All drivers have the following structure:
1) A struct for each device instance containing the device state.
2) A way of initializing and commanding sub-devices (if any).
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX)
and keeping track of device-node specific data.
4) Filehandle-specific structs containing per-filehandle data;
5) video buffer handling.
This is a rough schematic of how it all relates:
.. code-block:: none
device instances
|
+-sub-device instances
|
\-V4L2 device nodes
|
\-filehandle instances
Structure of the V4L2 framework
-------------------------------
The framework closely resembles the driver structure: it has a v4l2_device
struct for the device instance data, a v4l2_subdev struct to refer to
sub-device instances, the video_device struct stores V4L2 device node data
and the v4l2_fh struct keeps track of filehandle instances.
The V4L2 framework also optionally integrates with the media framework. If a
driver sets the struct v4l2_device mdev field, sub-devices and video nodes
will automatically appear in the media framework as entities.
V4L2 Media Controller functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-mc.h
V4L2 Media Bus functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-mediabus.h
V4L2 Memory to Memory functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-mem2mem.h
V4L2 Open Firmware kAPI
^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-of.h
V4L2 rect helper functions
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-rect.h
This diff is collapsed.
Tuner functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/tuner.h
.. kernel-doc:: include/media/tuner-types.h
Hauppauge TV EEPROM functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/tveeprom.h
.. _vb2_framework:
V4L2 videobuf2 functions and data structures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/videobuf2-core.h
.. kernel-doc:: include/media/videobuf2-v4l2.h
.. kernel-doc:: include/media/videobuf2-memops.h
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment