提交 85538b1a 编写于 作者: M 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
  ...
......@@ -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
......
HOWTO: Get An Avermedia DVB-T working under Linux
______________________________________________
Table of Contents
Assumptions and Introduction
The Avermedia DVB-T
Getting the card going
Receiving DVB-T in Australia
Known Limitations
Further Update
Assumptions and Introduction
It is assumed that the reader understands the basic structure
of the Linux Kernel DVB drivers and the general principles of
Digital TV.
One significant difference between Digital TV and Analogue TV
that the unwary (like myself) should consider is that,
although the component structure of budget DVB-T cards are
substantially similar to Analogue TV cards, they function in
substantially different ways.
The purpose of an Analogue TV is to receive and display an
Analogue Television signal. An Analogue TV signal (otherwise
known as composite video) is an analogue encoding of a
sequence of image frames (25 per second) rasterised using an
interlacing technique. Interlacing takes two fields to
represent one frame. Computers today are at their best when
dealing with digital signals, not analogue signals and a
composite video signal is about as far removed from a digital
data stream as you can get. Therefore, an Analogue TV card for
a PC has the following purpose:
* Tune the receiver to receive a broadcast signal
* demodulate the broadcast signal
* demultiplex the analogue video signal and analogue audio
signal (note some countries employ a digital audio signal
embedded within the modulated composite analogue signal -
NICAM.)
* digitize the analogue video signal and make the resulting
datastream available to the data bus.
The digital datastream from an Analogue TV card is generated
by circuitry on the card and is often presented uncompressed.
For a PAL TV signal encoded at a resolution of 768x576 24-bit
color pixels over 25 frames per second - a fair amount of data
is generated and must be processed by the PC before it can be
displayed on the video monitor screen. Some Analogue TV cards
for PCs have onboard MPEG2 encoders which permit the raw
digital data stream to be presented to the PC in an encoded
and compressed form - similar to the form that is used in
Digital TV.
The purpose of a simple budget digital TV card (DVB-T,C or S)
is to simply:
* Tune the received to receive a broadcast signal.
* Extract the encoded digital datastream from the broadcast
signal.
* Make the encoded digital datastream (MPEG2) available to
the data bus.
The significant difference between the two is that the tuner
on the analogue TV card spits out an Analogue signal, whereas
the tuner on the digital TV card spits out a compressed
encoded digital datastream. As the signal is already
digitised, it is trivial to pass this datastream to the PC
databus with minimal additional processing and then extract
the digital video and audio datastreams passing them to the
appropriate software or hardware for decoding and viewing.
_________________________________________________________
The Avermedia DVB-T
The Avermedia DVB-T is a budget PCI DVB card. It has 3 inputs:
* RF Tuner Input
* Composite Video Input (RCA Jack)
* SVIDEO Input (Mini-DIN)
The RF Tuner Input is the input to the tuner module of the
card. The Tuner is otherwise known as the "Frontend" . The
Frontend of the Avermedia DVB-T is a Microtune 7202D. A timely
post to the linux-dvb mailing list ascertained that the
Microtune 7202D is supported by the sp887x driver which is
found in the dvb-hw CVS module.
The DVB-T card is based around the BT878 chip which is a very
common multimedia bridge and often found on Analogue TV cards.
There is no on-board MPEG2 decoder, which means that all MPEG2
decoding must be done in software, or if you have one, on an
MPEG2 hardware decoding card or chipset.
_________________________________________________________
Getting the card going
In order to fire up the card, it is necessary to load a number
of modules from the DVB driver set. Prior to this it will have
been necessary to download these drivers from the linuxtv CVS
server and compile them successfully.
Depending on the card's feature set, the Device Driver API for
DVB under Linux will expose some of the following device files
in the /dev tree:
* /dev/dvb/adapter0/audio0
* /dev/dvb/adapter0/ca0
* /dev/dvb/adapter0/demux0
* /dev/dvb/adapter0/dvr0
* /dev/dvb/adapter0/frontend0
* /dev/dvb/adapter0/net0
* /dev/dvb/adapter0/osd0
* /dev/dvb/adapter0/video0
The primary device nodes that we are interested in (at this
stage) for the Avermedia DVB-T are:
* /dev/dvb/adapter0/dvr0
* /dev/dvb/adapter0/frontend0
The dvr0 device node is used to read the MPEG2 Data Stream and
the frontend0 node is used to tune the frontend tuner module.
At this stage, it has not been able to ascertain the
functionality of the remaining device nodes in respect of the
Avermedia DVBT. However, full functionality in respect of
tuning, receiving and supplying the MPEG2 data stream is
possible with the currently available versions of the driver.
It may be possible that additional functionality is available
from the card (i.e. viewing the additional analogue inputs
that the card presents), but this has not been tested yet. If
I get around to this, I'll update the document with whatever I
find.
To power up the card, load the following modules in the
following order:
* modprobe bttv (normally loaded automatically)
* modprobe dvb-bt8xx (or place dvb-bt8xx in /etc/modules)
Insertion of these modules into the running kernel will
activate the appropriate DVB device nodes. It is then possible
to start accessing the card with utilities such as scan, tzap,
dvbstream etc.
The frontend module sp887x.o, requires an external firmware.
Please use the command "get_dvb_firmware sp887x" to download
it. Then copy it to /usr/lib/hotplug/firmware or /lib/firmware/
(depending on configuration of firmware hotplug).
Receiving DVB-T in Australia
I have no experience of DVB-T in other countries other than
Australia, so I will attempt to explain how it works here in
Melbourne and how this affects the configuration of the DVB-T
card.
The Digital Broadcasting Australia website has a Reception
locatortool which provides information on transponder channels
and frequencies. My local transmitter happens to be Mount
Dandenong.
The frequencies broadcast by Mount Dandenong are:
Table 1. Transponder Frequencies Mount Dandenong, Vic, Aus.
Broadcaster Channel Frequency
ABC VHF 12 226.5 MHz
TEN VHF 11 219.5 MHz
NINE VHF 8 191.625 MHz
SEVEN VHF 6 177.5 MHz
SBS UHF 29 536.5 MHz
The Scan utility has a set of compiled-in defaults for various
countries and regions, but if they do not suit, or if you have
a pre-compiled scan binary, you can specify a data file on the
command line which contains the transponder frequencies. Here
is a sample file for the above channel transponders:
# Data file for DVB scan program
#
# C Frequency SymbolRate FEC QAM
# S Frequency Polarisation SymbolRate FEC
# T Frequency Bandwidth FEC FEC2 QAM Mode Guard Hier
T 226500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 191625000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 219500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 177500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 536500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
The defaults for the transponder frequency and other
modulation parameters were obtained from www.dba.org.au.
When Scan runs, it will output channels.conf information for
any channel's transponders which the card's frontend can lock
onto. (i.e. any whose signal is strong enough at your
antenna).
Here's my channels.conf file for anyone who's interested:
ABC HDTV:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64
:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2307:0:560
ABC TV Melbourne:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_
4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:65
0:561
ABC TV 2:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64
:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:562
ABC TV 3:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64
:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:563
ABC TV 4:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64
:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:564
ABC DiG Radio:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2311:56
6
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:158
5
TEN Digital 1:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1
586
TEN Digital 2:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1
587
TEN Digital 3:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1
588
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:158
9
TEN Digital 4:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1
590
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:159
1
TEN HD:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:0:1592
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:159
3
Nine Digital:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QA
M_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:660:10
72
Nine Digital HD:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2
:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:0:1
073
Nine Guide:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_
64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:670:1074
7 Digital:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_6
4:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1328
7 Digital 1:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1329
7 Digital 2:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1330
7 Digital 3:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1331
7 HD Digital:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QA
M_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:833:834:133
2
7 Program Guide:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3
:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:865:866:
1334
SBS HD:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:784
SBS DIGITAL 1:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:785
SBS DIGITAL 2:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:162:83:786
SBS EPG:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:
TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:163:85:787
SBS RADIO 1:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:201:798
SBS RADIO 2:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM
_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:202:799
_________________________________________________________
Known Limitations
At present I can say with confidence that the frontend tunes
via /dev/dvb/adapter{x}/frontend0 and supplies an MPEG2 stream
via /dev/dvb/adapter{x}/dvr0. I have not tested the
functionality of any other part of the card yet. I will do so
over time and update this document.
There are some limitations in the i2c layer due to a returned
error message inconsistency. Although this generates errors in
dmesg and the system logs, it does not appear to affect the
ability of the frontend to function correctly.
_________________________________________________________
Further Update
dvbstream and VideoLAN Client on windows works a treat with
DVB, in fact this is currently serving as my main way of
viewing DVB-T at the moment. Additionally, VLC is happily
decoding HDTV signals, although the PC is dropping the odd
frame here and there - I assume due to processing capability -
as all the decoding is being done under windows in software.
Many thanks to Nigel Pearson for the updates to this document
since the recent revision of the driver.
February 14th 2006
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
# Ignore header name
ignore define _CEC_UAPI_H
# Rename some symbols, to avoid namespace conflicts
replace struct cec_event_state_change cec-event-state-change_s
replace struct cec_event_lost_msgs cec-event-lost-msgs_s
replace enum cec_mode_initiator cec-mode-initiator_e
replace enum cec_mode_follower cec-mode-follower_e
# define macros to ignore
ignore define CEC_MAX_MSG_SIZE
ignore define CEC_MAX_LOG_ADDRS
ignore define CEC_LOG_ADDR_MASK_TV
ignore define CEC_LOG_ADDR_MASK_RECORD
ignore define CEC_LOG_ADDR_MASK_TUNER
ignore define CEC_LOG_ADDR_MASK_PLAYBACK
ignore define CEC_LOG_ADDR_MASK_AUDIOSYSTEM
ignore define CEC_LOG_ADDR_MASK_BACKUP
ignore define CEC_LOG_ADDR_MASK_SPECIFIC
ignore define CEC_LOG_ADDR_MASK_UNREGISTERED
# Shouldn't them be documented?
ignore define CEC_LOG_ADDR_INVALID
ignore define CEC_PHYS_ADDR_INVALID
ignore define CEC_VENDOR_ID_NONE
ignore define CEC_MODE_INITIATOR_MSK
ignore define CEC_MODE_FOLLOWER_MSK
ignore define CEC_EVENT_FL_INITIAL_STATE
# Part of CEC 2.0 spec - shouldn't be documented too?
ignore define CEC_LOG_ADDR_TV
ignore define CEC_LOG_ADDR_RECORD_1
ignore define CEC_LOG_ADDR_RECORD_2
ignore define CEC_LOG_ADDR_TUNER_1
ignore define CEC_LOG_ADDR_PLAYBACK_1
ignore define CEC_LOG_ADDR_AUDIOSYSTEM
ignore define CEC_LOG_ADDR_TUNER_2
ignore define CEC_LOG_ADDR_TUNER_3
ignore define CEC_LOG_ADDR_PLAYBACK_2
ignore define CEC_LOG_ADDR_RECORD_3
ignore define CEC_LOG_ADDR_TUNER_4
ignore define CEC_LOG_ADDR_PLAYBACK_3
ignore define CEC_LOG_ADDR_BACKUP_1
ignore define CEC_LOG_ADDR_BACKUP_2
ignore define CEC_LOG_ADDR_SPECIFIC
ignore define CEC_LOG_ADDR_UNREGISTERED
ignore define CEC_LOG_ADDR_BROADCAST
# IMHO, those should also be documented
ignore define CEC_MSG_ACTIVE_SOURCE
ignore define CEC_MSG_IMAGE_VIEW_ON
ignore define CEC_MSG_TEXT_VIEW_ON
ignore define CEC_MSG_INACTIVE_SOURCE
ignore define CEC_MSG_REQUEST_ACTIVE_SOURCE
ignore define CEC_MSG_ROUTING_CHANGE
ignore define CEC_MSG_ROUTING_INFORMATION
ignore define CEC_MSG_SET_STREAM_PATH
ignore define CEC_MSG_STANDBY
ignore define CEC_MSG_RECORD_OFF
ignore define CEC_MSG_RECORD_ON
ignore define CEC_OP_RECORD_SRC_OWN
ignore define CEC_OP_RECORD_SRC_DIGITAL
ignore define CEC_OP_RECORD_SRC_ANALOG
ignore define CEC_OP_RECORD_SRC_EXT_PLUG
ignore define CEC_OP_RECORD_SRC_EXT_PHYS_ADDR
ignore define CEC_OP_SERVICE_ID_METHOD_BY_DIG_ID
ignore define CEC_OP_SERVICE_ID_METHOD_BY_CHANNEL
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_GEN
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_GEN
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_GEN
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_BS
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_CS
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_T
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_CABLE
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_SAT
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_T
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_C
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_S
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_S2
ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_T
ignore define CEC_OP_ANA_BCAST_TYPE_CABLE
ignore define CEC_OP_ANA_BCAST_TYPE_SATELLITE
ignore define CEC_OP_ANA_BCAST_TYPE_TERRESTRIAL
ignore define CEC_OP_BCAST_SYSTEM_PAL_BG
ignore define CEC_OP_BCAST_SYSTEM_SECAM_LQ
ignore define CEC_OP_BCAST_SYSTEM_PAL_M
ignore define CEC_OP_BCAST_SYSTEM_NTSC_M
ignore define CEC_OP_BCAST_SYSTEM_PAL_I
ignore define CEC_OP_BCAST_SYSTEM_SECAM_DK
ignore define CEC_OP_BCAST_SYSTEM_SECAM_BG
ignore define CEC_OP_BCAST_SYSTEM_SECAM_L
ignore define CEC_OP_BCAST_SYSTEM_PAL_DK
ignore define CEC_OP_BCAST_SYSTEM_OTHER
ignore define CEC_OP_CHANNEL_NUMBER_FMT_1_PART
ignore define CEC_OP_CHANNEL_NUMBER_FMT_2_PART
ignore define CEC_MSG_RECORD_STATUS
ignore define CEC_OP_RECORD_STATUS_CUR_SRC
ignore define CEC_OP_RECORD_STATUS_DIG_SERVICE
ignore define CEC_OP_RECORD_STATUS_ANA_SERVICE
ignore define CEC_OP_RECORD_STATUS_EXT_INPUT
ignore define CEC_OP_RECORD_STATUS_NO_DIG_SERVICE
ignore define CEC_OP_RECORD_STATUS_NO_ANA_SERVICE
ignore define CEC_OP_RECORD_STATUS_NO_SERVICE
ignore define CEC_OP_RECORD_STATUS_INVALID_EXT_PLUG
ignore define CEC_OP_RECORD_STATUS_INVALID_EXT_PHYS_ADDR
ignore define CEC_OP_RECORD_STATUS_UNSUP_CA
ignore define CEC_OP_RECORD_STATUS_NO_CA_ENTITLEMENTS
ignore define CEC_OP_RECORD_STATUS_CANT_COPY_SRC
ignore define CEC_OP_RECORD_STATUS_NO_MORE_COPIES
ignore define CEC_OP_RECORD_STATUS_NO_MEDIA
ignore define CEC_OP_RECORD_STATUS_PLAYING
ignore define CEC_OP_RECORD_STATUS_ALREADY_RECORDING
ignore define CEC_OP_RECORD_STATUS_MEDIA_PROT
ignore define CEC_OP_RECORD_STATUS_NO_SIGNAL
ignore define CEC_OP_RECORD_STATUS_MEDIA_PROBLEM
ignore define CEC_OP_RECORD_STATUS_NO_SPACE
ignore define CEC_OP_RECORD_STATUS_PARENTAL_LOCK
ignore define CEC_OP_RECORD_STATUS_TERMINATED_OK
ignore define CEC_OP_RECORD_STATUS_ALREADY_TERM
ignore define CEC_OP_RECORD_STATUS_OTHER
ignore define CEC_MSG_RECORD_TV_SCREEN
ignore define CEC_MSG_CLEAR_ANALOGUE_TIMER
ignore define CEC_OP_REC_SEQ_SUNDAY
ignore define CEC_OP_REC_SEQ_MONDAY
ignore define CEC_OP_REC_SEQ_TUESDAY
ignore define CEC_OP_REC_SEQ_WEDNESDAY
ignore define CEC_OP_REC_SEQ_THURSDAY
ignore define CEC_OP_REC_SEQ_FRIDAY
ignore define CEC_OP_REC_SEQ_SATERDAY
ignore define CEC_OP_REC_SEQ_ONCE_ONLY
ignore define CEC_MSG_CLEAR_DIGITAL_TIMER
ignore define CEC_MSG_CLEAR_EXT_TIMER
ignore define CEC_OP_EXT_SRC_PLUG
ignore define CEC_OP_EXT_SRC_PHYS_ADDR
ignore define CEC_MSG_SET_ANALOGUE_TIMER
ignore define CEC_MSG_SET_DIGITAL_TIMER
ignore define CEC_MSG_SET_EXT_TIMER
ignore define CEC_MSG_SET_TIMER_PROGRAM_TITLE
ignore define CEC_MSG_TIMER_CLEARED_STATUS
ignore define CEC_OP_TIMER_CLR_STAT_RECORDING
ignore define CEC_OP_TIMER_CLR_STAT_NO_MATCHING
ignore define CEC_OP_TIMER_CLR_STAT_NO_INFO
ignore define CEC_OP_TIMER_CLR_STAT_CLEARED
ignore define CEC_MSG_TIMER_STATUS
ignore define CEC_OP_TIMER_OVERLAP_WARNING_NO_OVERLAP
ignore define CEC_OP_TIMER_OVERLAP_WARNING_OVERLAP
ignore define CEC_OP_MEDIA_INFO_UNPROT_MEDIA
ignore define CEC_OP_MEDIA_INFO_PROT_MEDIA
ignore define CEC_OP_MEDIA_INFO_NO_MEDIA
ignore define CEC_OP_PROG_IND_NOT_PROGRAMMED
ignore define CEC_OP_PROG_IND_PROGRAMMED
ignore define CEC_OP_PROG_INFO_ENOUGH_SPACE
ignore define CEC_OP_PROG_INFO_NOT_ENOUGH_SPACE
ignore define CEC_OP_PROG_INFO_MIGHT_NOT_BE_ENOUGH_SPACE
ignore define CEC_OP_PROG_INFO_NONE_AVAILABLE
ignore define CEC_OP_PROG_ERROR_NO_FREE_TIMER
ignore define CEC_OP_PROG_ERROR_DATE_OUT_OF_RANGE
ignore define CEC_OP_PROG_ERROR_REC_SEQ_ERROR
ignore define CEC_OP_PROG_ERROR_INV_EXT_PLUG
ignore define CEC_OP_PROG_ERROR_INV_EXT_PHYS_ADDR
ignore define CEC_OP_PROG_ERROR_CA_UNSUPP
ignore define CEC_OP_PROG_ERROR_INSUF_CA_ENTITLEMENTS
ignore define CEC_OP_PROG_ERROR_RESOLUTION_UNSUPP
ignore define CEC_OP_PROG_ERROR_PARENTAL_LOCK
ignore define CEC_OP_PROG_ERROR_CLOCK_FAILURE
ignore define CEC_OP_PROG_ERROR_DUPLICATE
ignore define CEC_MSG_CEC_VERSION
ignore define CEC_OP_CEC_VERSION_1_3A
ignore define CEC_OP_CEC_VERSION_1_4
ignore define CEC_OP_CEC_VERSION_2_0
ignore define CEC_MSG_GET_CEC_VERSION
ignore define CEC_MSG_GIVE_PHYSICAL_ADDR
ignore define CEC_MSG_GET_MENU_LANGUAGE
ignore define CEC_MSG_REPORT_PHYSICAL_ADDR
ignore define CEC_OP_PRIM_DEVTYPE_TV
ignore define CEC_OP_PRIM_DEVTYPE_RECORD
ignore define CEC_OP_PRIM_DEVTYPE_TUNER
ignore define CEC_OP_PRIM_DEVTYPE_PLAYBACK
ignore define CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM
ignore define CEC_OP_PRIM_DEVTYPE_SWITCH
ignore define CEC_OP_PRIM_DEVTYPE_PROCESSOR
ignore define CEC_MSG_SET_MENU_LANGUAGE
ignore define CEC_MSG_REPORT_FEATURES
ignore define CEC_OP_ALL_DEVTYPE_TV
ignore define CEC_OP_ALL_DEVTYPE_RECORD
ignore define CEC_OP_ALL_DEVTYPE_TUNER
ignore define CEC_OP_ALL_DEVTYPE_PLAYBACK
ignore define CEC_OP_ALL_DEVTYPE_AUDIOSYSTEM
ignore define CEC_OP_ALL_DEVTYPE_SWITCH
ignore define CEC_OP_FEAT_EXT
ignore define CEC_OP_FEAT_RC_TV_PROFILE_NONE
ignore define CEC_OP_FEAT_RC_TV_PROFILE_1
ignore define CEC_OP_FEAT_RC_TV_PROFILE_2
ignore define CEC_OP_FEAT_RC_TV_PROFILE_3
ignore define CEC_OP_FEAT_RC_TV_PROFILE_4
ignore define CEC_OP_FEAT_RC_SRC_HAS_DEV_ROOT_MENU
ignore define CEC_OP_FEAT_RC_SRC_HAS_DEV_SETUP_MENU
ignore define CEC_OP_FEAT_RC_SRC_HAS_CONTENTS_MENU
ignore define CEC_OP_FEAT_RC_SRC_HAS_MEDIA_TOP_MENU
ignore define CEC_OP_FEAT_RC_SRC_HAS_MEDIA_CONTEXT_MENU
ignore define CEC_OP_FEAT_DEV_HAS_RECORD_TV_SCREEN
ignore define CEC_OP_FEAT_DEV_HAS_SET_OSD_STRING
ignore define CEC_OP_FEAT_DEV_HAS_DECK_CONTROL
ignore define CEC_OP_FEAT_DEV_HAS_SET_AUDIO_RATE
ignore define CEC_OP_FEAT_DEV_SINK_HAS_ARC_TX
ignore define CEC_OP_FEAT_DEV_SOURCE_HAS_ARC_RX
ignore define CEC_MSG_GIVE_FEATURES
ignore define CEC_MSG_DECK_CONTROL
ignore define CEC_OP_DECK_CTL_MODE_SKIP_FWD
ignore define CEC_OP_DECK_CTL_MODE_SKIP_REV
ignore define CEC_OP_DECK_CTL_MODE_STOP
ignore define CEC_OP_DECK_CTL_MODE_EJECT
ignore define CEC_MSG_DECK_STATUS
ignore define CEC_OP_DECK_INFO_PLAY
ignore define CEC_OP_DECK_INFO_RECORD
ignore define CEC_OP_DECK_INFO_PLAY_REV
ignore define CEC_OP_DECK_INFO_STILL
ignore define CEC_OP_DECK_INFO_SLOW
ignore define CEC_OP_DECK_INFO_SLOW_REV
ignore define CEC_OP_DECK_INFO_FAST_FWD
ignore define CEC_OP_DECK_INFO_FAST_REV
ignore define CEC_OP_DECK_INFO_NO_MEDIA
ignore define CEC_OP_DECK_INFO_STOP
ignore define CEC_OP_DECK_INFO_SKIP_FWD
ignore define CEC_OP_DECK_INFO_SKIP_REV
ignore define CEC_OP_DECK_INFO_INDEX_SEARCH_FWD
ignore define CEC_OP_DECK_INFO_INDEX_SEARCH_REV
ignore define CEC_OP_DECK_INFO_OTHER
ignore define CEC_MSG_GIVE_DECK_STATUS
ignore define CEC_OP_STATUS_REQ_ON
ignore define CEC_OP_STATUS_REQ_OFF
ignore define CEC_OP_STATUS_REQ_ONCE
ignore define CEC_MSG_PLAY
ignore define CEC_OP_PLAY_MODE_PLAY_FWD
ignore define CEC_OP_PLAY_MODE_PLAY_REV
ignore define CEC_OP_PLAY_MODE_PLAY_STILL
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_FWD_MIN
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_FWD_MED
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_FWD_MAX
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_REV_MIN
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_REV_MED
ignore define CEC_OP_PLAY_MODE_PLAY_FAST_REV_MAX
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_FWD_MIN
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_FWD_MED
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_FWD_MAX
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_REV_MIN
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_REV_MED
ignore define CEC_OP_PLAY_MODE_PLAY_SLOW_REV_MAX
ignore define CEC_MSG_GIVE_TUNER_DEVICE_STATUS
ignore define CEC_MSG_SELECT_ANALOGUE_SERVICE
ignore define CEC_MSG_SELECT_DIGITAL_SERVICE
ignore define CEC_MSG_TUNER_DEVICE_STATUS
ignore define CEC_OP_REC_FLAG_USED
ignore define CEC_OP_REC_FLAG_NOT_USED
ignore define CEC_OP_TUNER_DISPLAY_INFO_DIGITAL
ignore define CEC_OP_TUNER_DISPLAY_INFO_NONE
ignore define CEC_OP_TUNER_DISPLAY_INFO_ANALOGUE
ignore define CEC_MSG_TUNER_STEP_DECREMENT
ignore define CEC_MSG_TUNER_STEP_INCREMENT
ignore define CEC_MSG_DEVICE_VENDOR_ID
ignore define CEC_MSG_GIVE_DEVICE_VENDOR_ID
ignore define CEC_MSG_VENDOR_COMMAND
ignore define CEC_MSG_VENDOR_COMMAND_WITH_ID
ignore define CEC_MSG_VENDOR_REMOTE_BUTTON_DOWN
ignore define CEC_MSG_VENDOR_REMOTE_BUTTON_UP
ignore define CEC_MSG_SET_OSD_STRING
ignore define CEC_OP_DISP_CTL_DEFAULT
ignore define CEC_OP_DISP_CTL_UNTIL_CLEARED
ignore define CEC_OP_DISP_CTL_CLEAR
ignore define CEC_MSG_GIVE_OSD_NAME
ignore define CEC_MSG_SET_OSD_NAME
ignore define CEC_MSG_MENU_REQUEST
ignore define CEC_OP_MENU_REQUEST_ACTIVATE
ignore define CEC_OP_MENU_REQUEST_DEACTIVATE
ignore define CEC_OP_MENU_REQUEST_QUERY
ignore define CEC_MSG_MENU_STATUS
ignore define CEC_OP_MENU_STATE_ACTIVATED
ignore define CEC_OP_MENU_STATE_DEACTIVATED
ignore define CEC_MSG_USER_CONTROL_PRESSED
ignore define CEC_OP_UI_BCAST_TYPE_TOGGLE_ALL
ignore define CEC_OP_UI_BCAST_TYPE_TOGGLE_DIG_ANA
ignore define CEC_OP_UI_BCAST_TYPE_ANALOGUE
ignore define CEC_OP_UI_BCAST_TYPE_ANALOGUE_T
ignore define CEC_OP_UI_BCAST_TYPE_ANALOGUE_CABLE
ignore define CEC_OP_UI_BCAST_TYPE_ANALOGUE_SAT
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL_T
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL_CABLE
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL_SAT
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL_COM_SAT
ignore define CEC_OP_UI_BCAST_TYPE_DIGITAL_COM_SAT2
ignore define CEC_OP_UI_BCAST_TYPE_IP
ignore define CEC_OP_UI_SND_PRES_CTL_DUAL_MONO
ignore define CEC_OP_UI_SND_PRES_CTL_KARAOKE
ignore define CEC_OP_UI_SND_PRES_CTL_DOWNMIX
ignore define CEC_OP_UI_SND_PRES_CTL_REVERB
ignore define CEC_OP_UI_SND_PRES_CTL_EQUALIZER
ignore define CEC_OP_UI_SND_PRES_CTL_BASS_UP
ignore define CEC_OP_UI_SND_PRES_CTL_BASS_NEUTRAL
ignore define CEC_OP_UI_SND_PRES_CTL_BASS_DOWN
ignore define CEC_OP_UI_SND_PRES_CTL_TREBLE_UP
ignore define CEC_OP_UI_SND_PRES_CTL_TREBLE_NEUTRAL
ignore define CEC_OP_UI_SND_PRES_CTL_TREBLE_DOWN
ignore define CEC_MSG_USER_CONTROL_RELEASED
ignore define CEC_MSG_GIVE_DEVICE_POWER_STATUS
ignore define CEC_MSG_REPORT_POWER_STATUS
ignore define CEC_OP_POWER_STATUS_ON
ignore define CEC_OP_POWER_STATUS_STANDBY
ignore define CEC_OP_POWER_STATUS_TO_ON
ignore define CEC_OP_POWER_STATUS_TO_STANDBY
ignore define CEC_MSG_FEATURE_ABORT
ignore define CEC_OP_ABORT_UNRECOGNIZED_OP
ignore define CEC_OP_ABORT_INCORRECT_MODE
ignore define CEC_OP_ABORT_NO_SOURCE
ignore define CEC_OP_ABORT_INVALID_OP
ignore define CEC_OP_ABORT_REFUSED
ignore define CEC_OP_ABORT_UNDETERMINED
ignore define CEC_MSG_ABORT
ignore define CEC_MSG_GIVE_AUDIO_STATUS
ignore define CEC_MSG_GIVE_SYSTEM_AUDIO_MODE_STATUS
ignore define CEC_MSG_REPORT_AUDIO_STATUS
ignore define CEC_OP_AUD_MUTE_STATUS_OFF
ignore define CEC_OP_AUD_MUTE_STATUS_ON
ignore define CEC_MSG_REPORT_SHORT_AUDIO_DESCRIPTOR
ignore define CEC_MSG_REQUEST_SHORT_AUDIO_DESCRIPTOR
ignore define CEC_MSG_SET_SYSTEM_AUDIO_MODE
ignore define CEC_OP_SYS_AUD_STATUS_OFF
ignore define CEC_OP_SYS_AUD_STATUS_ON
ignore define CEC_MSG_SYSTEM_AUDIO_MODE_REQUEST
ignore define CEC_MSG_SYSTEM_AUDIO_MODE_STATUS
ignore define CEC_OP_AUD_FMT_ID_CEA861
ignore define CEC_OP_AUD_FMT_ID_CEA861_CXT
ignore define CEC_MSG_SET_AUDIO_RATE
ignore define CEC_OP_AUD_RATE_OFF
ignore define CEC_OP_AUD_RATE_WIDE_STD
ignore define CEC_OP_AUD_RATE_WIDE_FAST
ignore define CEC_OP_AUD_RATE_WIDE_SLOW
ignore define CEC_OP_AUD_RATE_NARROW_STD
ignore define CEC_OP_AUD_RATE_NARROW_FAST
ignore define CEC_OP_AUD_RATE_NARROW_SLOW
ignore define CEC_MSG_INITIATE_ARC
ignore define CEC_MSG_REPORT_ARC_INITIATED
ignore define CEC_MSG_REPORT_ARC_TERMINATED
ignore define CEC_MSG_REQUEST_ARC_INITIATION
ignore define CEC_MSG_REQUEST_ARC_TERMINATION
ignore define CEC_MSG_TERMINATE_ARC
ignore define CEC_MSG_REQUEST_CURRENT_LATENCY
ignore define CEC_MSG_REPORT_CURRENT_LATENCY
ignore define CEC_OP_LOW_LATENCY_MODE_OFF
ignore define CEC_OP_LOW_LATENCY_MODE_ON
ignore define CEC_OP_AUD_OUT_COMPENSATED_NA
ignore define CEC_OP_AUD_OUT_COMPENSATED_DELAY
ignore define CEC_OP_AUD_OUT_COMPENSATED_NO_DELAY
ignore define CEC_OP_AUD_OUT_COMPENSATED_PARTIAL_DELAY
ignore define CEC_MSG_CDC_MESSAGE
ignore define CEC_MSG_CDC_HEC_INQUIRE_STATE
ignore define CEC_MSG_CDC_HEC_REPORT_STATE
ignore define CEC_OP_HEC_FUNC_STATE_NOT_SUPPORTED
ignore define CEC_OP_HEC_FUNC_STATE_INACTIVE
ignore define CEC_OP_HEC_FUNC_STATE_ACTIVE
ignore define CEC_OP_HEC_FUNC_STATE_ACTIVATION_FIELD
ignore define CEC_OP_HOST_FUNC_STATE_NOT_SUPPORTED
ignore define CEC_OP_HOST_FUNC_STATE_INACTIVE
ignore define CEC_OP_HOST_FUNC_STATE_ACTIVE
ignore define CEC_OP_ENC_FUNC_STATE_EXT_CON_NOT_SUPPORTED
ignore define CEC_OP_ENC_FUNC_STATE_EXT_CON_INACTIVE
ignore define CEC_OP_ENC_FUNC_STATE_EXT_CON_ACTIVE
ignore define CEC_OP_CDC_ERROR_CODE_NONE
ignore define CEC_OP_CDC_ERROR_CODE_CAP_UNSUPPORTED
ignore define CEC_OP_CDC_ERROR_CODE_WRONG_STATE
ignore define CEC_OP_CDC_ERROR_CODE_OTHER
ignore define CEC_OP_HEC_SUPPORT_NO
ignore define CEC_OP_HEC_SUPPORT_YES
ignore define CEC_OP_HEC_ACTIVATION_ON
ignore define CEC_OP_HEC_ACTIVATION_OFF
ignore define CEC_MSG_CDC_HEC_SET_STATE_ADJACENT
ignore define CEC_MSG_CDC_HEC_SET_STATE
ignore define CEC_OP_HEC_SET_STATE_DEACTIVATE
ignore define CEC_OP_HEC_SET_STATE_ACTIVATE
ignore define CEC_MSG_CDC_HEC_REQUEST_DEACTIVATION
ignore define CEC_MSG_CDC_HEC_NOTIFY_ALIVE
ignore define CEC_MSG_CDC_HEC_DISCOVER
ignore define CEC_MSG_CDC_HPD_SET_STATE
ignore define CEC_OP_HPD_STATE_CP_EDID_DISABLE
ignore define CEC_OP_HPD_STATE_CP_EDID_ENABLE
ignore define CEC_OP_HPD_STATE_CP_EDID_DISABLE_ENABLE
ignore define CEC_OP_HPD_STATE_EDID_DISABLE
ignore define CEC_OP_HPD_STATE_EDID_ENABLE
ignore define CEC_OP_HPD_STATE_EDID_DISABLE_ENABLE
ignore define CEC_MSG_CDC_HPD_REPORT_STATE
ignore define CEC_OP_HPD_ERROR_NONE
ignore define CEC_OP_HPD_ERROR_INITIATOR_NOT_CAPABLE
ignore define CEC_OP_HPD_ERROR_INITIATOR_WRONG_STATE
ignore define CEC_OP_HPD_ERROR_OTHER
ignore define CEC_OP_HPD_ERROR_NONE_NO_VIDEO
# 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
HOWTO: Get An Avermedia DVB-T working under Linux
-------------------------------------------------
February 14th 2006
.. note::
This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
There's a section there specific for Avermedia boards at:
https://linuxtv.org/wiki/index.php/AVerMedia
Assumptions and Introduction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is assumed that the reader understands the basic structure
of the Linux Kernel DVB drivers and the general principles of
Digital TV.
One significant difference between Digital TV and Analogue TV
that the unwary (like myself) should consider is that,
although the component structure of budget DVB-T cards are
substantially similar to Analogue TV cards, they function in
substantially different ways.
The purpose of an Analogue TV is to receive and display an
Analogue Television signal. An Analogue TV signal (otherwise
known as composite video) is an analogue encoding of a
sequence of image frames (25 per second) rasterised using an
interlacing technique. Interlacing takes two fields to
represent one frame. Computers today are at their best when
dealing with digital signals, not analogue signals and a
composite video signal is about as far removed from a digital
data stream as you can get. Therefore, an Analogue TV card for
a PC has the following purpose:
* Tune the receiver to receive a broadcast signal
* demodulate the broadcast signal
* demultiplex the analogue video signal and analogue audio
signal. **NOTE:** some countries employ a digital audio signal
embedded within the modulated composite analogue signal -
NICAM.)
* digitize the analogue video signal and make the resulting
datastream available to the data bus.
The digital datastream from an Analogue TV card is generated
by circuitry on the card and is often presented uncompressed.
For a PAL TV signal encoded at a resolution of 768x576 24-bit
color pixels over 25 frames per second - a fair amount of data
is generated and must be processed by the PC before it can be
displayed on the video monitor screen. Some Analogue TV cards
for PCs have onboard MPEG2 encoders which permit the raw
digital data stream to be presented to the PC in an encoded
and compressed form - similar to the form that is used in
Digital TV.
The purpose of a simple budget digital TV card (DVB-T,C or S)
is to simply:
* Tune the received to receive a broadcast signal.
* Extract the encoded digital datastream from the broadcast
signal.
* Make the encoded digital datastream (MPEG2) available to
the data bus.
The significant difference between the two is that the tuner
on the analogue TV card spits out an Analogue signal, whereas
the tuner on the digital TV card spits out a compressed
encoded digital datastream. As the signal is already
digitised, it is trivial to pass this datastream to the PC
databus with minimal additional processing and then extract
the digital video and audio datastreams passing them to the
appropriate software or hardware for decoding and viewing.
The Avermedia DVB-T
~~~~~~~~~~~~~~~~~~~
The Avermedia DVB-T is a budget PCI DVB card. It has 3 inputs:
* RF Tuner Input
* Composite Video Input (RCA Jack)
* SVIDEO Input (Mini-DIN)
The RF Tuner Input is the input to the tuner module of the
card. The Tuner is otherwise known as the "Frontend" . The
Frontend of the Avermedia DVB-T is a Microtune 7202D. A timely
post to the linux-dvb mailing list ascertained that the
Microtune 7202D is supported by the sp887x driver which is
found in the dvb-hw CVS module.
The DVB-T card is based around the BT878 chip which is a very
common multimedia bridge and often found on Analogue TV cards.
There is no on-board MPEG2 decoder, which means that all MPEG2
decoding must be done in software, or if you have one, on an
MPEG2 hardware decoding card or chipset.
Getting the card going
~~~~~~~~~~~~~~~~~~~~~~
In order to fire up the card, it is necessary to load a number
of modules from the DVB driver set. Prior to this it will have
been necessary to download these drivers from the linuxtv CVS
server and compile them successfully.
Depending on the card's feature set, the Device Driver API for
DVB under Linux will expose some of the following device files
in the /dev tree:
* /dev/dvb/adapter0/audio0
* /dev/dvb/adapter0/ca0
* /dev/dvb/adapter0/demux0
* /dev/dvb/adapter0/dvr0
* /dev/dvb/adapter0/frontend0
* /dev/dvb/adapter0/net0
* /dev/dvb/adapter0/osd0
* /dev/dvb/adapter0/video0
The primary device nodes that we are interested in (at this
stage) for the Avermedia DVB-T are:
* /dev/dvb/adapter0/dvr0
* /dev/dvb/adapter0/frontend0
The dvr0 device node is used to read the MPEG2 Data Stream and
the frontend0 node is used to tune the frontend tuner module.
At this stage, it has not been able to ascertain the
functionality of the remaining device nodes in respect of the
Avermedia DVBT. However, full functionality in respect of
tuning, receiving and supplying the MPEG2 data stream is
possible with the currently available versions of the driver.
It may be possible that additional functionality is available
from the card (i.e. viewing the additional analogue inputs
that the card presents), but this has not been tested yet. If
I get around to this, I'll update the document with whatever I
find.
To power up the card, load the following modules in the
following order:
* modprobe bttv (normally loaded automatically)
* modprobe dvb-bt8xx (or place dvb-bt8xx in /etc/modules)
Insertion of these modules into the running kernel will
activate the appropriate DVB device nodes. It is then possible
to start accessing the card with utilities such as scan, tzap,
dvbstream etc.
The frontend module sp887x.o, requires an external firmware.
Please use the command "get_dvb_firmware sp887x" to download
it. Then copy it to /usr/lib/hotplug/firmware or /lib/firmware/
(depending on configuration of firmware hotplug).
Receiving DVB-T in Australia
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have no experience of DVB-T in other countries other than
Australia, so I will attempt to explain how it works here in
Melbourne and how this affects the configuration of the DVB-T
card.
The Digital Broadcasting Australia website has a Reception
locatortool which provides information on transponder channels
and frequencies. My local transmitter happens to be Mount
Dandenong.
The frequencies broadcast by Mount Dandenong are:
Table 1. Transponder Frequencies Mount Dandenong, Vic, Aus.
Broadcaster Channel Frequency
ABC VHF 12 226.5 MHz
TEN VHF 11 219.5 MHz
NINE VHF 8 191.625 MHz
SEVEN VHF 6 177.5 MHz
SBS UHF 29 536.5 MHz
The Scan utility has a set of compiled-in defaults for various
countries and regions, but if they do not suit, or if you have
a pre-compiled scan binary, you can specify a data file on the
command line which contains the transponder frequencies. Here
is a sample file for the above channel transponders:
::
# Data file for DVB scan program
#
# C Frequency SymbolRate FEC QAM
# S Frequency Polarisation SymbolRate FEC
# T Frequency Bandwidth FEC FEC2 QAM Mode Guard Hier
T 226500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 191625000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 219500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 177500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
T 536500000 7MHz 2/3 NONE QAM64 8k 1/8 NONE
The defaults for the transponder frequency and other
modulation parameters were obtained from www.dba.org.au.
When Scan runs, it will output channels.conf information for
any channel's transponders which the card's frontend can lock
onto. (i.e. any whose signal is strong enough at your
antenna).
Here's my channels.conf file for anyone who's interested:
::
ABC HDTV:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:2307:0:560
ABC TV Melbourne:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:561
ABC TV 2:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:562
ABC TV 3:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:563
ABC TV 4:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:564
ABC DiG Radio:226500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:0:2311:566
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1585
TEN Digital 1:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1586
TEN Digital 2:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1587
TEN Digital 3:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1588
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1589
TEN Digital 4:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1590
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1591
TEN HD:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:0:1592
TEN Digital:219500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:650:1593
Nine Digital:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:660:1072
Nine Digital HD:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:512:0:1073
Nine Guide:191625000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:514:670:1074
7 Digital:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1328
7 Digital 1:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1329
7 Digital 2:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1330
7 Digital 3:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:769:770:1331
7 HD Digital:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:833:834:1332
7 Program Guide:177500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:865:866:1334
SBS HD:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:102:103:784
SBS DIGITAL 1:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:161:81:785
SBS DIGITAL 2:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:162:83:786
SBS EPG:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:163:85:787
SBS RADIO 1:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:201:798
SBS RADIO 2:536500000:INVERSION_OFF:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:202:799
Known Limitations
~~~~~~~~~~~~~~~~~
At present I can say with confidence that the frontend tunes
via /dev/dvb/adapter{x}/frontend0 and supplies an MPEG2 stream
via /dev/dvb/adapter{x}/dvr0. I have not tested the
functionality of any other part of the card yet. I will do so
over time and update this document.
There are some limitations in the i2c layer due to a returned
error message inconsistency. Although this generates errors in
dmesg and the system logs, it does not appear to affect the
ability of the frontend to function correctly.
Further Update
~~~~~~~~~~~~~~
dvbstream and VideoLAN Client on windows works a treat with
DVB, in fact this is currently serving as my main way of
viewing DVB-T at the moment. Additionally, VLC is happily
decoding HDTV signals, although the PC is dropping the odd
frame here and there - I assume due to processing capability -
as all the decoding is being done under windows in software.
Many thanks to Nigel Pearson for the updates to this document
since the recent revision of the driver.
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,63 +49,74 @@ 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
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
0x20: card has a conditional access slot for scrambled channels
.. 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
0x20: card has a conditional access slot for scrambled channels
The autodetected values are determined by the cards' "response string".
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
out of the box with every card, because of different wiring.
This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
Note 2: 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.
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.
#) 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.
- Frontends drivers:
o 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::
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.
(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.
ca_zap
~~~~~~
(2) one requires a userspace application, ca_zap. This small userland
application is in charge of sending the descrambling related information
to the CAM.
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.
eg: $ szap -c channels.conf -r "TMC" -x
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
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.
(b) a channels.conf containing a valid PMT PID
eg: TMC:11996:h:0:27500:278:512:650:321
c) after running a szap, you have to run ca_zap, for the
descrambler to function,
here 278 is a valid PMT PID. the rest of the values are the
same ones that szap uses.
eg: $ ca_zap channels.conf "TMC"
(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
a FTA card.
(d) Hopefully enjoy your favourite subscribed channel as you do with
a FTA card.
.. note::
(3) Currently ca_zap, and dst_test, both are meant for demonstration
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
typedef struct ca_slot_info {
int num; /* slot number */
The CI interface is defined in the DVB API in ca.h as:
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 */
.. code-block:: c
unsigned int flags;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
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 */
unsigned int flags;
#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 {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
/* 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;
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)
Documentation for dvb-usb-framework module and its devices
Idea behind the dvb-usb-framework
=================================
In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs and a firmware.
.. note::
#) This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
#) **deprecated:** Newer DVB USB drivers should use the dvb-usb-v2 framework.
In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs
and a firmware.
Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
After reading some specs and doing some USB snooping, it realized, that the
......@@ -40,80 +46,184 @@ TODO: dynamic enabling and disabling of the pid-filter in regard to number of
feeds requested.
Supported devices
========================
-----------------
See the LinuxTV DVB Wiki at www.linuxtv.org for a complete list of
See the LinuxTV DVB Wiki at https://linuxtv.org for a complete list of
cards/drivers/firmwares:
https://linuxtv.org/wiki/index.php/DVB_USB
0. History & News:
2005-06-30 - added support for WideView WT-220U (Thanks to Steve Chang)
2005-05-30 - added basic isochronous support to the dvb-usb-framework
added support for Conexant Hybrid reference design and Nebula DigiTV USB
2005-04-17 - all dibusb devices ported to make use of the dvb-usb-framework
2005-04-02 - re-enabled and improved remote control code.
2005-03-31 - ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
2005-03-30 - first commit of the dvb-usb-module based on the dibusb-source. First device is a new driver for the
TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
(change from dvb-dibusb to dvb-usb)
2005-03-28 - added support for the AVerMedia AverTV DVB-T USB2.0 device (Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
2005-03-14 - added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron
2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2
2005-01-31 - distorted streaming is gone for USB1.1 devices
2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb
- first almost working version for HanfTek UMT-010
- found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010
2005-01-10 - refactoring completed, now everything is very delightful
- tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a
Panasonic Tuner assembled). Tunerprobing implemented. Thanks a lot to Gunnar Wittich.
2004-12-29 - after several days of struggling around bug of no returning URBs fixed.
2004-12-26 - refactored the dibusb-driver, splitted into separate files
- i2c-probing enabled
2004-12-06 - possibility for demod i2c-address probing
- new usb IDs (Compro, Artec)
2004-11-23 - merged changes from DiB3000MC_ver2.1
- revised the debugging
- possibility to deliver the complete TS for USB2.0
2004-11-21 - first working version of the dib3000mc/p frontend driver.
2004-11-12 - added additional remote control keys. Thanks to Uwe Hanke.
2004-11-07 - added remote control support. Thanks to David Matthews.
2004-11-05 - added support for a new devices (Grandtec/Avermedia/Artec)
- merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
better settled there (added xfer_ops-struct)
- created a common files for frontends (mc/p/mb)
2004-09-28 - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
to Amaury Demol for reporting
- changed usb TS transfer method (several urbs, stopping transfer
before setting a new pid)
2004-09-13 - added support for a new device (Artec T1 USB TVBOX), thanks
to Christian Motschke for reporting
2004-09-05 - released the dibusb device and dib3000mb-frontend driver
(old news for vp7041.c)
2004-07-15 - found out, by accident, that the device has a TUA6010XS for
PLL
2004-07-12 - figured out, that the driver should also work with the
CTS Portable (Chinese Television System)
2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
properly with firmware extracted from 2.422
- #if for 2.6.4 (dvb), compile issue
- changed firmware handling, see vp7041.txt sec 1.1
2004-07-02 - some tuner modifications, v0.1, cleanups, first public
2004-06-28 - now using the dvb_dmx_swfilter_packets, everything
runs fine now
2004-06-27 - able to watch and switching channels (pre-alpha)
- no section filtering yet
2004-06-06 - first TS received, but kernel oops :/
2004-05-14 - firmware loader is working
2004-05-11 - start writing the driver
1. How to use?
1.1. Firmware
2005-06-30
- added support for WideView WT-220U (Thanks to Steve Chang)
2005-05-30
- added basic isochronous support to the dvb-usb-framework
- added support for Conexant Hybrid reference design and Nebula
DigiTV USB
2005-04-17
- all dibusb devices ported to make use of the dvb-usb-framework
2005-04-02
- re-enabled and improved remote control code.
2005-03-31
- ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
2005-03-30
- first commit of the dvb-usb-module based on the dibusb-source.
First device is a new driver for the
TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
- (change from dvb-dibusb to dvb-usb)
2005-03-28
- added support for the AVerMedia AverTV DVB-T USB2.0 device
(Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
2005-03-14
- added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
2005-02-11
- added support for the KWorld/ADSTech Instant DVB-T USB2.0.
Thanks a lot to Joachim von Caron
2005-02-02
- added support for the Hauppauge Win-TV Nova-T USB2
2005-01-31
- distorted streaming is gone for USB1.1 devices
2005-01-13
- moved the mirrored pid_filter_table back to dvb-dibusb
first almost working version for HanfTek UMT-010
found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010
2005-01-10
- refactoring completed, now everything is very delightful
- tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a
Panasonic Tuner assembled). Tunerprobing implemented.
Thanks a lot to Gunnar Wittich.
2004-12-29
- after several days of struggling around bug of no returning URBs fixed.
2004-12-26
- refactored the dibusb-driver, splitted into separate files
- i2c-probing enabled
2004-12-06
- possibility for demod i2c-address probing
- new usb IDs (Compro, Artec)
2004-11-23
- merged changes from DiB3000MC_ver2.1
- revised the debugging
- possibility to deliver the complete TS for USB2.0
2004-11-21
- first working version of the dib3000mc/p frontend driver.
2004-11-12
- added additional remote control keys. Thanks to Uwe Hanke.
2004-11-07
- added remote control support. Thanks to David Matthews.
2004-11-05
- added support for a new devices (Grandtec/Avermedia/Artec)
- merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
better settled there (added xfer_ops-struct)
- created a common files for frontends (mc/p/mb)
2004-09-28
- added support for a new device (Unknown, vendor ID is Hyper-Paltek)
2004-09-20
- added support for a new device (Compro DVB-U2000), thanks
to Amaury Demol for reporting
- changed usb TS transfer method (several urbs, stopping transfer
before setting a new pid)
2004-09-13
- added support for a new device (Artec T1 USB TVBOX), thanks
to Christian Motschke for reporting
2004-09-05
- released the dibusb device and dib3000mb-frontend driver
(old news for vp7041.c)
2004-07-15
- found out, by accident, that the device has a TUA6010XS for PLL
2004-07-12
- figured out, that the driver should also work with the
CTS Portable (Chinese Television System)
2004-07-08
- firmware-extraction-2.422-problem solved, driver is now working
properly with firmware extracted from 2.422
- #if for 2.6.4 (dvb), compile issue
- changed firmware handling, see vp7041.txt sec 1.1
2004-07-02
- some tuner modifications, v0.1, cleanups, first public
2004-06-28
- now using the dvb_dmx_swfilter_packets, everything runs fine now
2004-06-27
- able to watch and switching channels (pre-alpha)
- no section filtering yet
2004-06-06
- first TS received, but kernel oops :/
2004-05-14
- firmware loader is working
2004-05-11
- start writing the driver
How to use?
-----------
Firmware
~~~~~~~~
Most of the USB drivers need to download a firmware to the device before start
working.
......@@ -123,7 +233,8 @@ you need for your device:
https://linuxtv.org/wiki/index.php/DVB_USB
1.2. Compiling
Compiling
~~~~~~~~~
Since the driver is in the linux kernel, activating the driver in
your favorite config-environment should sufficient. I recommend
......@@ -132,7 +243,8 @@ to compile the driver as module. Hotplug does the rest.
If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
load' afterwards.
1.3. Loading the drivers
Loading the drivers
~~~~~~~~~~~~~~~~~~~
Hotplug is able to load the driver, when it is needed (because you plugged
in the device).
......@@ -142,13 +254,18 @@ from within the dvb-kernel cvs repository.
first have a look, which debug level are available:
modinfo dvb-usb
modinfo dvb-usb-vp7045
etc.
.. code-block:: none
modprobe dvb-usb debug=<level>
modprobe dvb-usb-vp7045 debug=<level>
etc.
# modinfo dvb-usb
# modinfo dvb-usb-vp7045
etc.
.. code-block:: none
modprobe dvb-usb debug=<level>
modprobe dvb-usb-vp7045 debug=<level>
etc.
should do the trick.
......@@ -160,16 +277,19 @@ At this point you should be able to start a dvb-capable application. I'm use
(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
long-term test scenario.
2. Known problems and bugs
Known problems and bugs
-----------------------
- Don't remove the USB device while running an DVB application, your system
will go crazy or die most likely.
2.1. Adding support for devices
Adding support for devices
~~~~~~~~~~~~~~~~~~~~~~~~~~
TODO
2.2. USB1.1 Bandwidth limitation
USB1.1 Bandwidth limitation
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A lot of the currently supported devices are USB1.1 and thus they have a
maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
......@@ -185,48 +305,51 @@ definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
working like charm now with VDR. Sometimes I even was able to record a channel
and watch another one.
2.3. Comments
Comments
~~~~~~~~
Patches, comments and suggestions are very very welcome.
3. Acknowledgements
-------------------
Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for
providing specs, code and help, on which the dvb-dibusb, dib3000mb and
dib3000mc are based.
providing specs, code and help, on which the dvb-dibusb, dib3000mb and
dib3000mc are based.
David Matthews for identifying a new device type (Artec T1 with AN2235)
and for extending dibusb with remote control event handling. Thank you.
and for extending dibusb with remote control event handling. Thank you.
Alex Woods for frequently answering question about usb and dvb
stuff, a big thank you.
stuff, a big thank you.
Bernd Wagner for helping with huge bug reports and discussions.
Gunnar Wittich and Joachim von Caron for their trust for providing
root-shells on their machines to implement support for new devices.
root-shells on their machines to implement support for new devices.
Allan Third and Michael Hutchinson for their help to write the Nebula
digitv-driver.
digitv-driver.
Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
Jung from AVerMedia who kindly provided a special firmware to get the device
up and running in Linux.
Jung from AVerMedia who kindly provided a special firmware to get the device
up and running in Linux.
Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
writing the vp7045-driver.
writing the vp7045-driver.
Steve Chang from WideView for providing information for new devices and
firmware files.
firmware files.
Michael Paxton for submitting remote control keymaps.
Some guys on the linux-dvb mailing list for encouraging me.
Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
user-level firmware loader, which saves a lot of time
(when writing the vp7041 driver)
user-level firmware loader, which saves a lot of time
(when writing the vp7041 driver)
Ulf Hermenau for helping me out with traditional chinese.
André Smoktun and Christian Frömmel for supporting me with
hardware and listening to my problems very patiently.
hardware and listening to my problems very patiently.
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
V4L2 Controls
=============
Introduction
============
------------
The V4L2 control API seems simple enough, but quickly becomes very hard to
implement correctly in drivers. But much of the code needed to handle controls
......@@ -26,7 +29,7 @@ for V4L2 drivers and struct v4l2_subdev for sub-device drivers.
Objects in the framework
========================
------------------------
There are two main objects:
......@@ -39,12 +42,14 @@ controls, possibly to controls owned by other handlers.
Basic usage for V4L2 and sub-device drivers
===========================================
-------------------------------------------
1) Prepare the driver:
1.1) Add the handler to your driver's top-level struct:
.. code-block:: none
struct foo_dev {
...
struct v4l2_ctrl_handler ctrl_handler;
......@@ -55,16 +60,20 @@ Basic usage for V4L2 and sub-device drivers
1.2) Initialize the handler:
.. code-block:: none
v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
The second argument is a hint telling the function how many controls this
handler is expected to handle. It will allocate a hashtable based on this
information. It is a hint only.
The second argument is a hint telling the function how many controls this
handler is expected to handle. It will allocate a hashtable based on this
information. It is a hint only.
1.3) Hook the control handler into the driver:
1.3.1) For V4L2 drivers do this:
.. code-block:: none
struct foo_dev {
...
struct v4l2_device v4l2_dev;
......@@ -75,15 +84,17 @@ Basic usage for V4L2 and sub-device drivers
foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler;
Where foo->v4l2_dev is of type struct v4l2_device.
Where foo->v4l2_dev is of type struct v4l2_device.
Finally, remove all control functions from your v4l2_ioctl_ops (if any):
vidioc_queryctrl, vidioc_query_ext_ctrl, vidioc_querymenu, vidioc_g_ctrl,
vidioc_s_ctrl, vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls.
Those are now no longer needed.
Finally, remove all control functions from your v4l2_ioctl_ops (if any):
vidioc_queryctrl, vidioc_query_ext_ctrl, vidioc_querymenu, vidioc_g_ctrl,
vidioc_s_ctrl, vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls.
Those are now no longer needed.
1.3.2) For sub-device drivers do this:
.. code-block:: none
struct foo_dev {
...
struct v4l2_subdev sd;
......@@ -94,10 +105,12 @@ Basic usage for V4L2 and sub-device drivers
foo->sd.ctrl_handler = &foo->ctrl_handler;
Where foo->sd is of type struct v4l2_subdev.
Where foo->sd is of type struct v4l2_subdev.
1.4) Clean up the handler at the end:
.. code-block:: none
v4l2_ctrl_handler_free(&foo->ctrl_handler);
......@@ -105,12 +118,16 @@ Basic usage for V4L2 and sub-device drivers
You add non-menu controls by calling v4l2_ctrl_new_std:
.. code-block:: none
struct v4l2_ctrl *v4l2_ctrl_new_std(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 min, s32 max, u32 step, s32 def);
Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu:
.. code-block:: none
struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 skip_mask, s32 def);
......@@ -118,6 +135,8 @@ Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu:
Menu controls with a driver specific menu are added by calling
v4l2_ctrl_new_std_menu_items:
.. code-block:: none
struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
......@@ -126,12 +145,16 @@ v4l2_ctrl_new_std_menu_items:
Integer menu controls with a driver specific menu can be added by calling
v4l2_ctrl_new_int_menu:
.. code-block:: none
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
These functions are typically called right after the v4l2_ctrl_handler_init:
.. code-block:: none
static const s64 exp_bias_qmenu[] = {
-2, -1, 0, 1, 2
};
......@@ -208,6 +231,8 @@ a bit faster that way.
3) Optionally force initial control setup:
.. code-block:: none
v4l2_ctrl_handler_setup(&foo->ctrl_handler);
This will call s_ctrl for all controls unconditionally. Effectively this
......@@ -217,12 +242,16 @@ the hardware are in sync.
4) Finally: implement the v4l2_ctrl_ops
.. code-block:: none
static const struct v4l2_ctrl_ops foo_ctrl_ops = {
.s_ctrl = foo_s_ctrl,
};
Usually all you need is s_ctrl:
.. code-block:: none
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler);
......@@ -247,16 +276,14 @@ to do any validation of control values, or implement QUERYCTRL, QUERY_EXT_CTRL
and QUERYMENU. And G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported.
==============================================================================
The remainder of this document deals with more advanced topics and scenarios.
In practice the basic usage as described above is sufficient for most drivers.
.. note::
===============================================================================
The remainder sections deal with more advanced controls topics and scenarios.
In practice the basic usage as described above is sufficient for most drivers.
Inheriting Controls
===================
-------------------
When a sub-device is registered with a V4L2 driver by calling
v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev
......@@ -271,21 +298,25 @@ of v4l2_device.
Accessing Control Values
========================
------------------------
The following union is used inside the control framework to access control
values:
union v4l2_ctrl_ptr {
s32 *p_s32;
s64 *p_s64;
char *p_char;
void *p;
};
.. code-block:: none
union v4l2_ctrl_ptr {
s32 *p_s32;
s64 *p_s64;
char *p_char;
void *p;
};
The v4l2_ctrl struct contains these fields that can be used to access both
current and new values:
.. code-block:: none
s32 val;
struct {
s32 val;
......@@ -297,6 +328,8 @@ current and new values:
If the control has a simple s32 type type, then:
.. code-block:: none
&ctrl->val == ctrl->p_new.p_s32
&ctrl->cur.val == ctrl->p_cur.p_s32
......@@ -319,6 +352,8 @@ exception is for controls that return a volatile register such as a signal
strength read-out that changes continuously. In that case you will need to
implement g_volatile_ctrl like this:
.. code-block:: none
static int foo_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
switch (ctrl->id) {
......@@ -335,6 +370,8 @@ changes.
To mark a control as volatile you have to set V4L2_CTRL_FLAG_VOLATILE:
.. code-block:: none
ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...);
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
......@@ -354,6 +391,8 @@ not to introduce deadlocks.
Outside of the control ops you have to go through to helper functions to get
or set a single control value safely in your driver:
.. code-block:: none
s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
......@@ -363,6 +402,8 @@ will result in a deadlock since these helpers lock the handler as well.
You can also take the handler lock yourself:
.. code-block:: none
mutex_lock(&state->ctrl_handler.lock);
pr_info("String value is '%s'\n", ctrl1->p_cur.p_char);
pr_info("Integer value is '%s'\n", ctrl2->cur.val);
......@@ -370,10 +411,12 @@ You can also take the handler lock yourself:
Menu Controls
=============
-------------
The v4l2_ctrl struct contains this union:
.. code-block:: none
union {
u32 step;
u32 menu_skip_mask;
......@@ -396,10 +439,12 @@ control, or by calling v4l2_ctrl_new_std_menu().
Custom Controls
===============
---------------
Driver specific controls can be created using v4l2_ctrl_new_custom():
.. code-block:: none
static const struct v4l2_ctrl_config ctrl_filter = {
.ops = &ctrl_custom_ops,
.id = V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER,
......@@ -422,7 +467,7 @@ control and will fill in the name, type and flags fields accordingly.
Active and Grabbed Controls
===========================
---------------------------
If you get more complex relationships between controls, then you may have to
activate and deactivate controls. For example, if the Chroma AGC control is
......@@ -446,16 +491,18 @@ starts or stops streaming.
Control Clusters
================
----------------
By default all controls are independent from the others. But in more
complex scenarios you can get dependencies from one control to another.
In that case you need to 'cluster' them:
.. code-block:: none
struct foo {
struct v4l2_ctrl_handler ctrl_handler;
#define AUDIO_CL_VOLUME (0)
#define AUDIO_CL_MUTE (1)
#define AUDIO_CL_VOLUME (0)
#define AUDIO_CL_MUTE (1)
struct v4l2_ctrl *audio_cluster[2];
...
};
......@@ -474,6 +521,8 @@ composite control. Similar to how a 'struct' works in C.
So when s_ctrl is called with V4L2_CID_AUDIO_VOLUME as argument, you should set
all two controls belonging to the audio_cluster:
.. code-block:: none
static int foo_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler);
......@@ -494,12 +543,16 @@ all two controls belonging to the audio_cluster:
In the example above the following are equivalent for the VOLUME case:
.. code-block:: none
ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == state->audio_cluster[AUDIO_CL_VOLUME]
ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE]
In practice using cluster arrays like this becomes very tiresome. So instead
the following equivalent method is used:
.. code-block:: none
struct {
/* audio cluster */
struct v4l2_ctrl *volume;
......@@ -510,6 +563,8 @@ The anonymous struct is used to clearly 'cluster' these two control pointers,
but it serves no other purpose. The effect is the same as creating an
array with two control pointers. So you can just do:
.. code-block:: none
state->volume = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
state->mute = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
v4l2_ctrl_cluster(2, &state->volume);
......@@ -539,7 +594,7 @@ The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
Handling autogain/gain-type Controls with Auto Clusters
=======================================================
-------------------------------------------------------
A common type of control cluster is one that handles 'auto-foo/foo'-type
controls. Typical examples are autogain/gain, autoexposure/exposure,
......@@ -564,8 +619,10 @@ changing that control affects the control flags of the manual controls.
In order to simplify this a special variation of v4l2_ctrl_cluster was
introduced:
void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
u8 manual_val, bool set_volatile);
.. code-block:: none
void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
u8 manual_val, bool set_volatile);
The first two arguments are identical to v4l2_ctrl_cluster. The third argument
tells the framework which value switches the cluster into manual mode. The
......@@ -582,7 +639,7 @@ flag and volatile handling.
VIDIOC_LOG_STATUS Support
=========================
-------------------------
This ioctl allow you to dump the current status of a driver to the kernel log.
The v4l2_ctrl_handler_log_status(ctrl_handler, prefix) can be used to dump the
......@@ -592,7 +649,7 @@ for you.
Different Handlers for Different Video Nodes
============================================
--------------------------------------------
Usually the V4L2 driver has just one control handler that is global for
all video nodes. But you can also specify different control handlers for
......@@ -617,6 +674,8 @@ of another handler (e.g. for a video device node), then you should first add
the controls to the first handler, add the other controls to the second
handler and finally add the first handler to the second. For example:
.. code-block:: none
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...);
......@@ -629,6 +688,8 @@ all controls.
Or you can add specific controls to a handler:
.. code-block:: none
volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_CONTRAST, ...);
......@@ -636,6 +697,8 @@ Or you can add specific controls to a handler:
What you should not do is make two identical controls for two handlers.
For example:
.. code-block:: none
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_AUDIO_MUTE, ...);
......@@ -645,7 +708,7 @@ can twiddle.
Finding Controls
================
----------------
Normally you have created the controls yourself and you can store the struct
v4l2_ctrl pointer into your own struct.
......@@ -655,6 +718,8 @@ not own. For example, if you have to find a volume control from a subdev.
You can do that by calling v4l2_ctrl_find:
.. code-block:: none
struct v4l2_ctrl *volume;
volume = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_AUDIO_VOLUME);
......@@ -662,6 +727,8 @@ You can do that by calling v4l2_ctrl_find:
Since v4l2_ctrl_find will lock the handler you have to be careful where you
use it. For example, this is not a good idea:
.. code-block:: none
struct v4l2_ctrl_handler ctrl_handler;
v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...);
......@@ -669,6 +736,8 @@ use it. For example, this is not a good idea:
...and in video_ops.s_ctrl:
.. code-block:: none
case V4L2_CID_BRIGHTNESS:
contrast = v4l2_find_ctrl(&ctrl_handler, V4L2_CID_CONTRAST);
...
......@@ -680,7 +749,7 @@ It is recommended not to use this function from inside the control ops.
Inheriting Controls
===================
-------------------
When one control handler is added to another using v4l2_ctrl_add_handler, then
by default all controls from one are merged to the other. But a subdev might
......@@ -689,6 +758,8 @@ not when it is used in consumer-level hardware. In that case you want to keep
those low-level controls local to the subdev. You can do this by simply
setting the 'is_private' flag of the control to 1:
.. code-block:: none
static const struct v4l2_ctrl_config ctrl_private = {
.ops = &ctrl_custom_ops,
.id = V4L2_CID_...,
......@@ -705,7 +776,7 @@ These controls will now be skipped when v4l2_ctrl_add_handler is called.
V4L2_CTRL_TYPE_CTRL_CLASS Controls
==================================
----------------------------------
Controls of this type can be used by GUIs to get the name of the control class.
A fully featured GUI can make a dialog with multiple tabs with each tab
......@@ -718,14 +789,16 @@ class is added.
Adding Notify Callbacks
=======================
-----------------------
Sometimes the platform or bridge driver needs to be notified when a control
from a sub-device driver changes. You can set a notify callback by calling
this function:
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
.. code-block:: none
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
Whenever the give control changes value the notify callback will be called
with a pointer to the control and the priv pointer that was passed with
......@@ -734,3 +807,8 @@ notify function is called.
There can be only one notify function per control handler. Any attempt
to set another notify function will cause a WARN_ON.
v4l2_ctrl functions and data structures
---------------------------------------
.. kernel-doc:: include/media/v4l2-ctrls.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
Video device' s internal representation
=======================================
The actual device nodes in the ``/dev`` directory are created using the
:c:type:`video_device` struct (``v4l2-dev.h``). This struct can either be
allocated dynamically or embedded in a larger struct.
To allocate it dynamically use :c:func:`video_device_alloc`:
.. code-block:: c
struct video_device *vdev = video_device_alloc();
if (vdev == NULL)
return -ENOMEM;
vdev->release = video_device_release;
If you embed it in a larger struct, then you must set the ``release()``
callback to your own function:
.. code-block:: c
struct video_device *vdev = &my_vdev->vdev;
vdev->release = my_vdev_release;
The ``release()`` callback must be set and it is called when the last user
of the video device exits.
The default :c:func:`video_device_release` callback currently
just calls ``kfree`` to free the allocated memory.
There is also a ::c:func:`video_device_release_empty` function that does
nothing (is empty) and should be used if the struct is embedded and there
is nothing to do when it is released.
You should also set these fields of :c:type:`video_device`:
- :c:type:`video_device`->v4l2_dev: must be set to the :c:type:`v4l2_device`
parent device.
- :c:type:`video_device`->name: set to something descriptive and unique.
- :c:type:`video_device`->vfl_dir: set this to ``VFL_DIR_RX`` for capture
devices (``VFL_DIR_RX`` has value 0, so this is normally already the
default), set to ``VFL_DIR_TX`` for output devices and ``VFL_DIR_M2M`` for mem2mem (codec) devices.
- :c:type:`video_device`->fops: set to the :c:type:`v4l2_file_operations`
struct.
- :c:type:`video_device`->ioctl_ops: if you use the :c:type:`v4l2_ioctl_ops`
to simplify ioctl maintenance (highly recommended to use this and it might
become compulsory in the future!), then set this to your
:c:type:`v4l2_ioctl_ops` struct. The :c:type:`video_device`->vfl_type and
:c:type:`video_device`->vfl_dir fields are used to disable ops that do not
match the type/dir combination. E.g. VBI ops are disabled for non-VBI nodes,
and output ops are disabled for a capture device. This makes it possible to
provide just one :c:type:`v4l2_ioctl_ops struct` for both vbi and
video nodes.
- :c:type:`video_device`->lock: leave to ``NULL`` if you want to do all the
locking in the driver. Otherwise you give it a pointer to a struct
``mutex_lock`` and before the :c:type:`video_device`->unlocked_ioctl
file operation is called this lock will be taken by the core and released
afterwards. See the next section for more details.
- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue`
associated with this device node.
If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock
is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``,
``QBUF``, ``DQBUF``, ``QUERYBUF``, ``PREPARE_BUF``, ``STREAMON`` and
``STREAMOFF``) instead of the lock above.
That way the :ref:`vb2 <vb2_framework>` queuing framework does not have
to wait for other ioctls. This queue pointer is also used by the
:ref:`vb2 <vb2_framework>` helper functions to check for
queuing ownership (i.e. is the filehandle calling it allowed to do the
operation).
- :c:type:`video_device`->prio: keeps track of the priorities. Used to
implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``.
If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state`
in :c:type:`v4l2_device`. If you want to have a separate priority state per
(group of) device node(s), then you can point it to your own struct
:c:type:`v4l2_prio_state`.
- :c:type:`video_device`->dev_parent: you only set this if v4l2_device was
registered with ``NULL`` as the parent ``device`` struct. This only happens
in cases where one hardware device has multiple PCI devices that all share
the same :c:type:`v4l2_device` core.
The cx88 driver is an example of this: one core :c:type:`v4l2_device` struct,
but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
(cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI
devices at the same time it is setup without a parent device. But when the
struct :c:type:`video_device` is initialized you **do** know which parent
PCI device to use and so you set ``dev_device`` to the correct PCI device.
If you use :c:type:`v4l2_ioctl_ops`, then you should set
:c:type:`video_device`->unlocked_ioctl to :c:func:`video_ioctl2` in your
:c:type:`v4l2_file_operations` struct.
In some cases you want to tell the core that a function you had specified in
your :c:type:`v4l2_ioctl_ops` should be ignored. You can mark such ioctls by
calling this function before :c:func:`video_register_device` is called:
:c:func:`v4l2_disable_ioctl <v4l2_disable_ioctl>`
(:c:type:`vdev <video_device>`, cmd).
This tends to be needed if based on external factors (e.g. which card is
being used) you want to turns off certain features in :c:type:`v4l2_ioctl_ops`
without having to make a new struct.
The :c:type:`v4l2_file_operations` struct is a subset of file_operations.
The main difference is that the inode argument is omitted since it is never
used.
If integration with the media framework is needed, you must initialize the
:c:type:`media_entity` struct embedded in the :c:type:`video_device` struct
(entity field) by calling :c:func:`media_entity_pads_init`:
.. code-block:: c
struct media_pad *pad = &my_vdev->pad;
int err;
err = media_entity_pads_init(&vdev->entity, 1, pad);
The pads array must have been previously initialized. There is no need to
manually set the struct media_entity type and name fields.
A reference to the entity will be automatically acquired/released when the
video device is opened/closed.
ioctls and locking
------------------
The V4L core provides optional locking services. The main service is the
lock field in struct :c:type:`video_device`, which is a pointer to a mutex.
If you set this pointer, then that will be used by unlocked_ioctl to
serialize all ioctls.
If you are using the :ref:`videobuf2 framework <vb2_framework>`, then there
is a second lock that you can set: :c:type:`video_device`->queue->lock. If
set, then this lock will be used instead of :c:type:`video_device`->lock
to serialize all queuing ioctls (see the previous section
for the full list of those ioctls).
The advantage of using a different lock for the queuing ioctls is that for some
drivers (particularly USB drivers) certain commands such as setting controls
can take a long time, so you want to use a separate lock for the buffer queuing
ioctls. That way your ``VIDIOC_DQBUF`` doesn't stall because the driver is busy
changing the e.g. exposure of the webcam.
Of course, you can always do all the locking yourself by leaving both lock
pointers at ``NULL``.
If you use the old :ref:`videobuf framework <vb_framework>` then you must
pass the :c:type:`video_device`->lock to the videobuf queue initialize
function: if videobuf has to wait for a frame to arrive, then it will
temporarily unlock the lock and relock it afterwards. If your driver also
waits in the code, then you should do the same to allow other
processes to access the device node while the first process is waiting for
something.
In the case of :ref:`videobuf2 <vb2_framework>` you will need to implement the
``wait_prepare()`` and ``wait_finish()`` callbacks to unlock/lock if applicable.
If you use the ``queue->lock`` pointer, then you can use the helper functions
:c:func:`vb2_ops_wait_prepare` and :cpp:func:`vb2_ops_wait_finish`.
The implementation of a hotplug disconnect should also take the lock from
:c:type:`video_device` before calling v4l2_device_disconnect. If you are also
using :c:type:`video_device`->queue->lock, then you have to first lock
:c:type:`video_device`->queue->lock followed by :c:type:`video_device`->lock.
That way you can be sure no ioctl is running when you call
:c:type:`v4l2_device_disconnect`.
Video device registration
-------------------------
Next you register the video device with :c:func:`video_register_device`.
This will create the character device for you.
.. code-block:: c
err = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
if (err) {
video_device_release(vdev); /* or kfree(my_vdev); */
return err;
}
If the :c:type:`v4l2_device` parent device has a not ``NULL`` mdev field,
the video device entity will be automatically registered with the media
device.
Which device is registered depends on the type argument. The following
types exist:
- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed captions, teletext)
- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
The last argument gives you a certain amount of control over the device
device node number used (i.e. the X in ``videoX``). Normally you will pass -1
to let the v4l2 framework pick the first free number. But sometimes users
want to select a specific node number. It is common that drivers allow
the user to select a specific device node number through a driver module
option. That number is then passed to this function and video_register_device
will attempt to select that device node number. If that number was already
in use, then the next free device node number will be selected and it
will send a warning to the kernel log.
Another use-case is if a driver creates many devices. In that case it can
be useful to place different video devices in separate ranges. For example,
video capture devices start at 0, video output devices start at 16.
So you can use the last argument to specify a minimum device node number
and the v4l2 framework will try to pick the first free number that is equal
or higher to what you passed. If that fails, then it will just pick the
first free number.
Since in this case you do not care about a warning about not being able
to select the specified device node number, you can call the function
:c:func:`video_register_device_no_warn` instead.
Whenever a device node is created some attributes are also created for you.
If you look in ``/sys/class/video4linux`` you see the devices. Go into e.g.
``video0`` and you will see 'name', 'dev_debug' and 'index' attributes. The
'name' attribute is the 'name' field of the video_device struct. The
'dev_debug' attribute can be used to enable core debugging. See the next
section for more detailed information on this.
The 'index' attribute is the index of the device node: for each call to
:c:func:`video_register_device()` the index is just increased by 1. The
first video device node you register always starts with index 0.
Users can setup udev rules that utilize the index attribute to make fancy
device names (e.g. '``mpegX``' for MPEG video capture device nodes).
After the device was successfully registered, then you can use these fields:
- :c:type:`video_device`->vfl_type: the device type passed to
:c:func:`video_register_device`.
- :c:type:`video_device`->minor: the assigned device minor number.
- :c:type:`video_device`->num: the device node number (i.e. the X in
``videoX``).
- :c:type:`video_device`->index: the device index number.
If the registration failed, then you need to call
:c:func:`video_device_release` to free the allocated :c:type:`video_device`
struct, or free your own struct if the :c:type:`video_device` was embedded in
it. The ``vdev->release()`` callback will never be called if the registration
failed, nor should you ever attempt to unregister the device if the
registration failed.
video device debugging
----------------------
The 'dev_debug' attribute that is created for each video, vbi, radio or swradio
device in ``/sys/class/video4linux/<devX>/`` allows you to enable logging of
file operations.
It is a bitmask and the following bits can be set:
===== ================================================================
Mask Description
===== ================================================================
0x01 Log the ioctl name and error code. VIDIOC_(D)QBUF ioctls are
only logged if bit 0x08 is also set.
0x02 Log the ioctl name arguments and error code. VIDIOC_(D)QBUF
ioctls are
only logged if bit 0x08 is also set.
0x04 Log the file operations open, release, read, write, mmap and
get_unmapped_area. The read and write operations are only
logged if bit 0x08 is also set.
0x08 Log the read and write file operations and the VIDIOC_QBUF and
VIDIOC_DQBUF ioctls.
0x10 Log the poll file operation.
===== ================================================================
Video device cleanup
--------------------
When the video device nodes have to be removed, either during the unload
of the driver or because the USB device was disconnected, then you should
unregister them with:
:c:func:`video_unregister_device`
(:c:type:`vdev <video_device>`);
This will remove the device nodes from sysfs (causing udev to remove them
from ``/dev``).
After :c:func:`video_unregister_device` returns no new opens can be done.
However, in the case of USB devices some application might still have one of
these device nodes open. So after the unregister all file operations (except
release, of course) will return an error as well.
When the last user of the video device node exits, then the ``vdev->release()``
callback is called and you can do the final cleanup there.
Don't forget to cleanup the media entity associated with the video device if
it has been initialized:
:c:func:`media_entity_cleanup <media_entity_cleanup>`
(&vdev->entity);
This can be done from the release callback.
helper functions
----------------
There are a few useful helper functions:
- file and :c:type:`video_device` private data
You can set/get driver private data in the video_device struct using:
:c:func:`video_get_drvdata <video_get_drvdata>`
(:c:type:`vdev <video_device>`);
:c:func:`video_set_drvdata <video_set_drvdata>`
(:c:type:`vdev <video_device>`);
Note that you can safely call :c:func:`video_set_drvdata` before calling
:c:func:`video_register_device`.
And this function:
:c:func:`video_devdata <video_devdata>`
(struct file \*file);
returns the video_device belonging to the file struct.
The :c:func:`video_devdata` function combines :cpp:func:`video_get_drvdata`
with :c:func:`video_devdata`:
:c:func:`video_drvdata <video_drvdata>`
(struct file \*file);
You can go from a :c:type:`video_device` struct to the v4l2_device struct using:
.. code-block:: c
struct v4l2_device *v4l2_dev = vdev->v4l2_dev;
- Device node name
The :c:type:`video_device` node kernel name can be retrieved using:
:c:func:`video_device_node_name <video_device_node_name>`
(:c:type:`vdev <video_device>`);
The name is used as a hint by userspace tools such as udev. The function
should be used where possible instead of accessing the video_device::num and
video_device::minor fields.
video_device functions and data structures
------------------------------------------
.. kernel-doc:: include/media/v4l2-dev.h
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
此差异已折叠。
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
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册