diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 58af32b01b909c5988e8315bb7ab4a9d108023f8..7febdeb08159167751dd45c0b210100153502b52 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -247,64 +247,6 @@ X!Isound/sound_firmware.c --> - - Media Devices - - Video2Linux devices -!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 - - Digital TV (DVB) devices - Digital TV Common functions -!Idrivers/media/dvb-core/dvb_math.h -!Idrivers/media/dvb-core/dvb_ringbuffer.h -!Idrivers/media/dvb-core/dvbdev.h - - Digital TV Frontend kABI -!Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend -!Idrivers/media/dvb-core/dvb_frontend.h - - Digital TV Demux kABI -!Pdrivers/media/dvb-core/demux.h Digital TV Demux - Demux Callback API -!Pdrivers/media/dvb-core/demux.h Demux Callback - -!Idrivers/media/dvb-core/demux.h - - Digital TV Conditional Access kABI -!Idrivers/media/dvb-core/dvb_ca_en50221.h - - - Remote Controller devices -!Iinclude/media/rc-core.h -!Iinclude/media/lirc_dev.h - - Media Controller devices -!Pinclude/media/media-device.h Media Controller -!Iinclude/media/media-device.h -!Iinclude/media/media-devnode.h -!Iinclude/media/media-entity.h - - Consumer Electronics Control devices -!Iinclude/media/cec-edid.h - - - 16x50 UART Driver diff --git a/Documentation/DocBook/media/v4l/fdl-appendix.xml b/Documentation/DocBook/media/v4l/fdl-appendix.xml index ae22394ba997d878ded4debdfa028b6c6c084543..71299a3897c4f0e3caa2e984cf96f594694346ed 100644 --- a/Documentation/DocBook/media/v4l/fdl-appendix.xml +++ b/Documentation/DocBook/media/v4l/fdl-appendix.xml @@ -526,7 +526,7 @@ 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. diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml index 71f9dbb81ec7ed5a6f22eb34675adaed86417e3c..f53ad58027a707392385c54babdad9fe572899c0 100644 --- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml @@ -114,7 +114,7 @@ on working with the default settings initially. 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. diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index d8d13c92a1789eb89422fa3397e4e2953d15d765..fd565e1f13681d23ee573c969b7f1b16e14895ab 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -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: diff --git a/Documentation/conf.py b/Documentation/conf.py index 792b6338ef197e2f0e26347673a4e3ae54247492..96b7aa66c89ca68c5f891d6fb3f2744dd80c6ca7 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -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 diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb deleted file mode 100644 index 6f4b12f7b8444cc121ece7f6de89ebb217e64461..0000000000000000000000000000000000000000 --- a/Documentation/dvb/README.dvb-usb +++ /dev/null @@ -1,232 +0,0 @@ -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. - -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 -dibusb-driver would be a complete mess afterwards. So I decided to do it in a -different way: With the help of a dvb-usb-framework. - -The framework provides generic functions (mostly kernel API calls), such as: - -- Transport Stream URB handling in conjunction with dvb-demux-feed-control - (bulk and isoc are supported) -- registering the device for the DVB-API -- registering an I2C-adapter if applicable -- remote-control/input-device handling -- firmware requesting and loading (currently just for the Cypress USB - controllers) -- other functions/methods which can be shared by several drivers (such as - functions for bulk-control-commands) -- TODO: a I2C-chunker. It creates device-specific chunks of register-accesses - depending on length of a register and the number of values that can be - multi-written and multi-read. - -The source code of the particular DVB USB devices does just the communication -with the device via the bus. The connection between the DVB-API-functionality -is done via callbacks, assigned in a static device-description (struct -dvb_usb_device) each device-driver has to have. - -For an example have a look in drivers/media/usb/dvb-usb/vp7045*. - -Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the -ttusb; flexcop-usb already benefits from the generic flexcop-device) to use -the dvb-usb-lib. - -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 -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 - -Most of the USB drivers need to download a firmware to the device before start -working. - -Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmware -you need for your device: - -https://linuxtv.org/wiki/index.php/DVB_USB - -1.2. Compiling - -Since the driver is in the linux kernel, activating the driver in -your favorite config-environment should sufficient. I recommend -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 - -Hotplug is able to load the driver, when it is needed (because you plugged -in the device). - -If you want to enable debug output, you have to load the driver manually and -from within the dvb-kernel cvs repository. - -first have a look, which debug level are available: - -modinfo dvb-usb -modinfo dvb-usb-vp7045 -etc. - -modprobe dvb-usb debug= -modprobe dvb-usb-vp7045 debug= -etc. - -should do the trick. - -When the driver is loaded successfully, the firmware file was in -the right place and the device is connected, the "Power"-LED should be -turned on. - -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 - -- 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 - -TODO - -2.2. 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. -This is not enough for receiving the complete transport stream of a -DVB-T channel (which is about 16 MBit/s). Normally this is not a -problem, if you only want to watch TV (this does not apply for HDTV), -but watching a channel while recording another channel on the same -frequency simply does not work very well. This applies to all USB1.1 -DVB-T devices, not just the dvb-usb-devices) - -The bug, where the TS is distorted by a heavy usage of the device is gone -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 - -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. - - David Matthews for identifying a new device type (Artec T1 with AN2235) - 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. - - 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. - - Allan Third and Michael Hutchinson for their help to write the Nebula - 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. - - Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by - writing the vp7045-driver. - - Steve Chang from WideView for providing information for new devices and - 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) - - 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. diff --git a/Documentation/dvb/avermedia.txt b/Documentation/dvb/avermedia.txt deleted file mode 100644 index e44c009ac6c5ef8dcf7cd5d295631b17ecc90e4f..0000000000000000000000000000000000000000 --- a/Documentation/dvb/avermedia.txt +++ /dev/null @@ -1,301 +0,0 @@ -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 diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt deleted file mode 100644 index b7b1d1b1da469a527eb4940ce86b9834deb8a8ee..0000000000000000000000000000000000000000 --- a/Documentation/dvb/bt8xx.txt +++ /dev/null @@ -1,98 +0,0 @@ -How to get the bt8xx cards working -================================== - -1) 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. - -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: -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 -================== - -Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically. -Exceptions are: -- Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom. -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 ------------------------------- - - $ 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 - -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 --------------------------- - -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: - $ 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 --------------------------------------------------- -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 - - $ echo 109e 0878 $subvendor $subdevice > \ - /sys/bus/pci/drivers/bt878/new_id - -109e: PCI_VENDOR_ID_BROOKTREE -0878: PCI_DEVICE_ID_BROOKTREE_878 - -Authors: Richard Walker, - Jamie Honan, - Michael Hunold, - Manu Abraham, - Uwe Bugla, - Michael Krufky diff --git a/Documentation/dvb/contributors.txt b/Documentation/dvb/contributors.txt deleted file mode 100644 index 731a009723c7cd88a2b4102cce597628758d8bbe..0000000000000000000000000000000000000000 --- a/Documentation/dvb/contributors.txt +++ /dev/null @@ -1,96 +0,0 @@ -Thanks go to the following people for patches and contributions: - -Michael Hunold - for the initial saa7146 driver and its recent overhaul - -Christian Theiss - for his work on the initial Linux DVB driver - -Marcus Metzler -Ralph Metzler - for their continuing work on the DVB driver - -Michael Holzt - for his contributions to the dvb-net driver - -Diego Picciani - 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 - for patching the cable card decoder driver - -Klaus Schmidinger - for various fixes regarding tuning, OSD and CI stuff and his work on VDR - -Steve Brown - for his AFC kernel thread - -Christoph Martin - for his LIRC infrared handler - -Andreas Oberritter -Dennis Noermann -Felix Domke -Florian Schirmer -Ronny Strutz <3des@elitedvb.de> -Wolfram Joost -...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 - for many bugfixes - -Andrew de Quincey - for the tda1004x frontend driver, and various bugfixes - -Peter Schildmann - for the driver for the Technisat SkyStar2 PCI DVB card - -Vadim Catana -Roberto Ragusa -Augusto Cardoso - for all the work for the FlexCopII chipset by B2C2,Inc. - -Davor Emard - for his work on the budget drivers, the demux code, - the module unloading problems, ... - -Hans-Frieder Vogt - for his work on calculating and checking the crc's for the - TechnoTrend/Hauppauge DEC driver firmware - -Michael Dreher -Andreas 'randy' Weinberger - for the support of the Fujitsu-Siemens Activy budget DVB-S - -Kenneth Aafløy - for adding support for Typhoon DVB-S budget card - -Ernst Peinlich - for tuning/DiSEqC support for the DEC 3000-s - -Peter Beutner - for the IR code for the ttusb-dec driver - -Wilson Michaels - for the lgdt330x frontend driver, and various bugfixes - -Michael Krufky - for maintaining v4l/dvb inter-tree dependencies - -Taylor Jacob - for the nxt2002 frontend driver - -Jean-Francois Thibert - for the nxt2004 frontend driver - -Kirk Lapray - 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) diff --git a/Documentation/dvb/readme.txt b/Documentation/dvb/readme.txt deleted file mode 100644 index 89965041a2667d3b4b2f29aa23b28b6c2f73f57d..0000000000000000000000000000000000000000 --- a/Documentation/dvb/readme.txt +++ /dev/null @@ -1,62 +0,0 @@ -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! diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt deleted file mode 100644 index f0cc4f2d836535ab5fe3acf6fe83bac29f1aa50c..0000000000000000000000000000000000000000 --- a/Documentation/dvb/technisat.txt +++ /dev/null @@ -1,78 +0,0 @@ -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 August 2009 diff --git a/Documentation/dvb/ttusb-dec.txt b/Documentation/dvb/ttusb-dec.txt deleted file mode 100644 index b2f271cd784bc5ce41100ce123a6d1bf9a4f0a64..0000000000000000000000000000000000000000 --- a/Documentation/dvb/ttusb-dec.txt +++ /dev/null @@ -1,45 +0,0 @@ -TechnoTrend/Hauppauge DEC USB Driver -==================================== - -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 - -To Do: - 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" - - -Compilation Notes for 2.4 kernels ---------------------------------- -For 2.4 kernels the firmware for the DECs is compiled into the driver itself. - -Copy the three files downloaded above into the build-2.4 directory. - - -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. - -Copy the three files downloaded above into the /usr/lib/hotplug/firmware or -/lib/firmware directory (depending on configuration of firmware hotplug). diff --git a/Documentation/index.rst b/Documentation/index.rst index f92854f01773fe46f9ba23900c4d217725827ba8..43c722f1529271e4826961b767e8499ad73e6ba9 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -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 ================== diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile new file mode 100644 index 0000000000000000000000000000000000000000..39e2d766dbe32d7ff7f214df6f66dbe34b8d76fa --- /dev/null +++ b/Documentation/media/Makefile @@ -0,0 +1,60 @@ +# 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} diff --git a/Documentation/media/audio.h.rst.exceptions b/Documentation/media/audio.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..8330edcd906dafceeb7c0b3b5e88de923f874dd2 --- /dev/null +++ b/Documentation/media/audio.h.rst.exceptions @@ -0,0 +1,20 @@ +# 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 diff --git a/Documentation/media/ca.h.rst.exceptions b/Documentation/media/ca.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..09c13be67527a93667bffbb5d7d5040612e60363 --- /dev/null +++ b/Documentation/media/ca.h.rst.exceptions @@ -0,0 +1,24 @@ +# 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 diff --git a/Documentation/media/cec.h.rst.exceptions b/Documentation/media/cec.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..b79339433718d8366abcf7ae8dc508f2011defb3 --- /dev/null +++ b/Documentation/media/cec.h.rst.exceptions @@ -0,0 +1,492 @@ +# 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 diff --git a/Documentation/media/dmx.h.rst.exceptions b/Documentation/media/dmx.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..8200653839d20def99ff27d123edf4e9c884bf24 --- /dev/null +++ b/Documentation/media/dmx.h.rst.exceptions @@ -0,0 +1,63 @@ +# 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 diff --git a/Documentation/media/dvb-drivers/avermedia.rst b/Documentation/media/dvb-drivers/avermedia.rst new file mode 100644 index 0000000000000000000000000000000000000000..49cd9c9353071cef0a06c76d8a8a866acfd64fc2 --- /dev/null +++ b/Documentation/media/dvb-drivers/avermedia.rst @@ -0,0 +1,267 @@ +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. diff --git a/Documentation/media/dvb-drivers/bt8xx.rst b/Documentation/media/dvb-drivers/bt8xx.rst new file mode 100644 index 0000000000000000000000000000000000000000..b43958b7340c7303f9ad81a27f7cdfc34ce31032 --- /dev/null +++ b/Documentation/media/dvb-drivers/bt8xx.rst @@ -0,0 +1,122 @@ +How to get the bt8xx cards working +================================== + +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: + +#) ``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`` + + 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`` + + Then please select your card-specific frontend module. + +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: +- Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom. +People running udev please see Documentation/dvb/udev.txt. + +In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary: + +Running TwinHan and Clones +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. code-block:: none + + $ modprobe bttv card=113 + $ modprobe dst + +Useful parameters for verbosity level and debugging the dst module: + +.. 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. + +Running multiple cards +~~~~~~~~~~~~~~~~~~~~~~ + +Examples of card ID's: + +.. 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. + +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 + +.. code-block:: none + + 109e: PCI_VENDOR_ID_BROOKTREE + 0878: PCI_DEVICE_ID_BROOKTREE_878 + diff --git a/Documentation/dvb/cards.txt b/Documentation/media/dvb-drivers/cards.rst similarity index 69% rename from Documentation/dvb/cards.txt rename to Documentation/media/dvb-drivers/cards.rst index 97709e9a3076a582b7c7114fbf2c437414e4dc61..177cbeb2b561cb12680566eca3ed6f3045c310b4 100644 --- a/Documentation/dvb/cards.txt +++ b/Documentation/media/dvb-drivers/cards.rst @@ -1,23 +1,36 @@ 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 diff --git a/Documentation/dvb/ci.txt b/Documentation/media/dvb-drivers/ci.rst similarity index 53% rename from Documentation/dvb/ci.txt rename to Documentation/media/dvb-drivers/ci.rst index 6c3bda50f7dcb122b46d159f22d5f1388e65549f..8124bf5ce5ef826436057156d2b2ddd0359d841b 100644 --- a/Documentation/dvb/ci.txt +++ b/Documentation/media/dvb-drivers/ci.rst @@ -1,52 +1,68 @@ -* 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) ----- diff --git a/Documentation/media/dvb-drivers/contributors.rst b/Documentation/media/dvb-drivers/contributors.rst new file mode 100644 index 0000000000000000000000000000000000000000..5949753008aecb368213811c97fb2a5193de6353 --- /dev/null +++ b/Documentation/media/dvb-drivers/contributors.rst @@ -0,0 +1,129 @@ +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 + + - for the initial saa7146 driver and its recent overhaul + +- Christian Theiss + + - for his work on the initial Linux DVB driver + +- Marcus Metzler and + Ralph Metzler + + - for their continuing work on the DVB driver + +- Michael Holzt + + - for his contributions to the dvb-net driver + +- Diego Picciani + + - 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 + + - for patching the cable card decoder driver + +- Klaus Schmidinger + + - for various fixes regarding tuning, OSD and CI stuff and his work on VDR + +- Steve Brown + + - for his AFC kernel thread + +- Christoph Martin + + - for his LIRC infrared handler + +- Andreas Oberritter , + Dennis Noermann , + Felix Domke , + Florian Schirmer , + Ronny Strutz <3des@elitedvb.de>, + Wolfram Joost + 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 + + - for many bugfixes + +- Andrew de Quincey + + - for the tda1004x frontend driver, and various bugfixes + +- Peter Schildmann + + - for the driver for the Technisat SkyStar2 PCI DVB card + +- Vadim Catana , + Roberto Ragusa and + Augusto Cardoso + + - for all the work for the FlexCopII chipset by B2C2,Inc. + +- Davor Emard + + - for his work on the budget drivers, the demux code, + the module unloading problems, ... + +- Hans-Frieder Vogt + + - for his work on calculating and checking the crc's for the + TechnoTrend/Hauppauge DEC driver firmware + +- Michael Dreher and + Andreas 'randy' Weinberger + + - for the support of the Fujitsu-Siemens Activy budget DVB-S + +- Kenneth Aafløy + + - for adding support for Typhoon DVB-S budget card + +- Ernst Peinlich + + - for tuning/DiSEqC support for the DEC 3000-s + +- Peter Beutner + + - for the IR code for the ttusb-dec driver + +- Wilson Michaels + + - for the lgdt330x frontend driver, and various bugfixes + +- Michael Krufky + + - for maintaining v4l/dvb inter-tree dependencies + +- Taylor Jacob + + - for the nxt2002 frontend driver + +- Jean-Francois Thibert + + - for the nxt2004 frontend driver + +- Kirk Lapray + + - 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) diff --git a/Documentation/media/dvb-drivers/dvb-usb.rst b/Documentation/media/dvb-drivers/dvb-usb.rst new file mode 100644 index 0000000000000000000000000000000000000000..eec99cd07a30821a6bb4d939a3d3a72729a02b36 --- /dev/null +++ b/Documentation/media/dvb-drivers/dvb-usb.rst @@ -0,0 +1,355 @@ +Idea behind the dvb-usb-framework +================================= + +.. 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 +dibusb-driver would be a complete mess afterwards. So I decided to do it in a +different way: With the help of a dvb-usb-framework. + +The framework provides generic functions (mostly kernel API calls), such as: + +- Transport Stream URB handling in conjunction with dvb-demux-feed-control + (bulk and isoc are supported) +- registering the device for the DVB-API +- registering an I2C-adapter if applicable +- remote-control/input-device handling +- firmware requesting and loading (currently just for the Cypress USB + controllers) +- other functions/methods which can be shared by several drivers (such as + functions for bulk-control-commands) +- TODO: a I2C-chunker. It creates device-specific chunks of register-accesses + depending on length of a register and the number of values that can be + multi-written and multi-read. + +The source code of the particular DVB USB devices does just the communication +with the device via the bus. The connection between the DVB-API-functionality +is done via callbacks, assigned in a static device-description (struct +dvb_usb_device) each device-driver has to have. + +For an example have a look in drivers/media/usb/dvb-usb/vp7045*. + +Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the +ttusb; flexcop-usb already benefits from the generic flexcop-device) to use +the dvb-usb-lib. + +TODO: dynamic enabling and disabling of the pid-filter in regard to number of +feeds requested. + +Supported devices +----------------- + +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 + +How to use? +----------- + +Firmware +~~~~~~~~ + +Most of the USB drivers need to download a firmware to the device before start +working. + +Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmware +you need for your device: + +https://linuxtv.org/wiki/index.php/DVB_USB + +Compiling +~~~~~~~~~ + +Since the driver is in the linux kernel, activating the driver in +your favorite config-environment should sufficient. I recommend +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. + +Loading the drivers +~~~~~~~~~~~~~~~~~~~ + +Hotplug is able to load the driver, when it is needed (because you plugged +in the device). + +If you want to enable debug output, you have to load the driver manually and +from within the dvb-kernel cvs repository. + +first have a look, which debug level are available: + +.. code-block:: none + + # modinfo dvb-usb + # modinfo dvb-usb-vp7045 + + etc. + +.. code-block:: none + + modprobe dvb-usb debug= + modprobe dvb-usb-vp7045 debug= + etc. + +should do the trick. + +When the driver is loaded successfully, the firmware file was in +the right place and the device is connected, the "Power"-LED should be +turned on. + +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. + +Known problems and bugs +----------------------- + +- Don't remove the USB device while running an DVB application, your system + will go crazy or die most likely. + +Adding support for devices +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +TODO + +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. +This is not enough for receiving the complete transport stream of a +DVB-T channel (which is about 16 MBit/s). Normally this is not a +problem, if you only want to watch TV (this does not apply for HDTV), +but watching a channel while recording another channel on the same +frequency simply does not work very well. This applies to all USB1.1 +DVB-T devices, not just the dvb-usb-devices) + +The bug, where the TS is distorted by a heavy usage of the device is gone +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. + +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. + + David Matthews for identifying a new device type (Artec T1 with AN2235) + 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. + + 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. + + Allan Third and Michael Hutchinson for their help to write the Nebula + 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. + + Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by + writing the vp7045-driver. + + Steve Chang from WideView for providing information for new devices and + 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) + + 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. diff --git a/Documentation/dvb/faq.txt b/Documentation/media/dvb-drivers/faq.rst similarity index 95% rename from Documentation/dvb/faq.txt rename to Documentation/media/dvb-drivers/faq.rst index a0be92012877d7c55246112c6dd61a104304d253..a8593d3792faaa2c3018bac1f09b5b03b2746a06 100644 --- a/Documentation/dvb/faq.txt +++ b/Documentation/media/dvb-drivers/faq.rst @@ -1,3 +1,11 @@ +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 diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst new file mode 100644 index 0000000000000000000000000000000000000000..ea0da6d63299918ab334cd8df1316d9c61c96380 --- /dev/null +++ b/Documentation/media/dvb-drivers/index.rst @@ -0,0 +1,42 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +############################################## +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 diff --git a/Documentation/media/dvb-drivers/intro.rst b/Documentation/media/dvb-drivers/intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..7681835ea76de74ed2412b460d149c48f665ca38 --- /dev/null +++ b/Documentation/media/dvb-drivers/intro.rst @@ -0,0 +1,21 @@ +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. diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/media/dvb-drivers/lmedm04.rst similarity index 50% rename from Documentation/dvb/lmedm04.txt rename to Documentation/media/dvb-drivers/lmedm04.rst index f4b720a14675cd208e5ed4f29994aa1b3e56ee64..e8913d4481a0c9dfac3a8edcb32eb2bf490d8451 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/media/dvb-drivers/lmedm04.rst @@ -1,7 +1,10 @@ +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 diff --git a/Documentation/dvb/opera-firmware.txt b/Documentation/media/dvb-drivers/opera-firmware.rst similarity index 74% rename from Documentation/dvb/opera-firmware.txt rename to Documentation/media/dvb-drivers/opera-firmware.rst index fb6683188ef7acfac30cffd98ca293071aa83934..41236b43c124eeec13962d752a6c7385e0fe8788 100644 --- a/Documentation/dvb/opera-firmware.txt +++ b/Documentation/media/dvb-drivers/opera-firmware.rst @@ -1,3 +1,8 @@ +Opera firmware +============== + +Author: Marco Gittler + 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 diff --git a/Documentation/media/dvb-drivers/technisat.rst b/Documentation/media/dvb-drivers/technisat.rst new file mode 100644 index 0000000000000000000000000000000000000000..f80f4ecc15601611e3075c4f3c1163b10f1ca022 --- /dev/null +++ b/Documentation/media/dvb-drivers/technisat.rst @@ -0,0 +1,98 @@ +How to set up the Technisat/B2C2 Flexcop devices +================================================ + +.. note:: + + This documentation is outdated. + +Author: Uwe Bugla 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`` + diff --git a/Documentation/media/dvb-drivers/ttusb-dec.rst b/Documentation/media/dvb-drivers/ttusb-dec.rst new file mode 100644 index 0000000000000000000000000000000000000000..84fc2199dc2969b4846e03e682189294da3ac76d --- /dev/null +++ b/Documentation/media/dvb-drivers/ttusb-dec.rst @@ -0,0 +1,43 @@ +TechnoTrend/Hauppauge DEC USB Driver +==================================== + +Driver Status +------------- + +Supported: + + - 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 + +Getting the Firmware +-------------------- +To download the firmware, use the following commands: + +.. code-block:: none + + scripts/get_dvb_firmware dec2000t + scripts/get_dvb_firmware dec2540t + scripts/get_dvb_firmware dec3000s + + +Hotplug Firmware Loading +------------------------ + +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). diff --git a/Documentation/dvb/udev.txt b/Documentation/media/dvb-drivers/udev.rst similarity index 72% rename from Documentation/dvb/udev.txt rename to Documentation/media/dvb-drivers/udev.rst index 412305b7c55792efecb825ebbafd646019f5bf4b..7d7d5d82108a3468a8f04ad07b086fb058fde703 100644 --- a/Documentation/dvb/udev.txt +++ b/Documentation/media/dvb-drivers/udev.rst @@ -1,9 +1,22 @@ +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". diff --git a/Documentation/media/frontend.h.rst.exceptions b/Documentation/media/frontend.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..60f2cbb926564fd0d6fb23614981d1022d48ce17 --- /dev/null +++ b/Documentation/media/frontend.h.rst.exceptions @@ -0,0 +1,47 @@ +# 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 diff --git a/Documentation/media/intro.rst b/Documentation/media/intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..be90bda5b3f3ab8ec36855a36fbd71773df06aa5 --- /dev/null +++ b/Documentation/media/intro.rst @@ -0,0 +1,46 @@ +.. -*- 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 ` covers radio, video capture and output, + cameras, analog TV devices and codecs. + +2. The :ref:`second part ` 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 ` covers the Remote Controller API. + +4. The :ref:`fourth part ` covers the Media Controller API. + +5. The :ref:`fifth part ` 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 `__. For discussing improvements, +reporting troubles, sending new drivers, etc, please mail to: `Linux Media +Mailing List (LMML) `__. diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst new file mode 100644 index 0000000000000000000000000000000000000000..dd96e846fef97b17e83735430a5b8095d0a06733 --- /dev/null +++ b/Documentation/media/kapi/dtv-core.rst @@ -0,0 +1,132 @@ +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 diff --git a/Documentation/media/kapi/mc-core.rst b/Documentation/media/kapi/mc-core.rst new file mode 100644 index 0000000000000000000000000000000000000000..569cfc4f01cd05bd9d5604204ada368556249fc9 --- /dev/null +++ b/Documentation/media/kapi/mc-core.rst @@ -0,0 +1,263 @@ +Media Controller devices +------------------------ + +Media Controller +~~~~~~~~~~~~~~~~ + +The media controller userspace API is documented in +:ref:`the Media Controller uAPI book `. 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 ` +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 ` +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 ` 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 `. + +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 ` 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 ` 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 ` 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`.\ ``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 ` 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 ` +in higher-level pipeline structures and can then access the +pipeline through the :c:type:`struct 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 diff --git a/Documentation/media/kapi/rc-core.rst b/Documentation/media/kapi/rc-core.rst new file mode 100644 index 0000000000000000000000000000000000000000..a4589588625731e59b0c145f31f7b5cdbde791fb --- /dev/null +++ b/Documentation/media/kapi/rc-core.rst @@ -0,0 +1,14 @@ +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 diff --git a/Documentation/media/kapi/v4l2-clocks.rst b/Documentation/media/kapi/v4l2-clocks.rst new file mode 100644 index 0000000000000000000000000000000000000000..b8a895860a8a0c9d1609def6c25a4f3325814664 --- /dev/null +++ b/Documentation/media/kapi/v4l2-clocks.rst @@ -0,0 +1,29 @@ +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. diff --git a/Documentation/media/kapi/v4l2-common.rst b/Documentation/media/kapi/v4l2-common.rst new file mode 100644 index 0000000000000000000000000000000000000000..525d804871ffb72a75547038bccc489abcc663f1 --- /dev/null +++ b/Documentation/media/kapi/v4l2-common.rst @@ -0,0 +1,6 @@ +V4L2 common functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-common.h + +.. kernel-doc:: include/media/v4l2-ioctl.h diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/media/kapi/v4l2-controls.rst similarity index 91% rename from Documentation/video4linux/v4l2-controls.txt rename to Documentation/media/kapi/v4l2-controls.rst index f930b80e9111be77aa9ac8aaa01736743b31e582..07a179eeb2fb5f4c24466e2ceb3749a83ffce001 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/media/kapi/v4l2-controls.rst @@ -1,5 +1,8 @@ +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 diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst new file mode 100644 index 0000000000000000000000000000000000000000..e9677150ed99d45c8922801e37599e8a93133d32 --- /dev/null +++ b/Documentation/media/kapi/v4l2-core.rst @@ -0,0 +1,26 @@ +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 diff --git a/Documentation/media/kapi/v4l2-dev.rst b/Documentation/media/kapi/v4l2-dev.rst new file mode 100644 index 0000000000000000000000000000000000000000..cdfcf0bc78bed135b7cc2cdbc767244e2570163f --- /dev/null +++ b/Documentation/media/kapi/v4l2-dev.rst @@ -0,0 +1,363 @@ +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 ` queuing framework does not have + to wait for other ioctls. This queue pointer is also used by the + :ref:`vb2 ` 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 ` + (:c:type:`vdev `, 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 `, 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 ` 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 ` 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//`` 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 `); + +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 ` + (&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 ` + (:c:type:`vdev `); + + :c:func:`video_set_drvdata ` + (:c:type:`vdev `); + +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 ` + (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 ` + (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 ` + (:c:type:`vdev `); + +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 diff --git a/Documentation/media/kapi/v4l2-device.rst b/Documentation/media/kapi/v4l2-device.rst new file mode 100644 index 0000000000000000000000000000000000000000..6c58bbbaa66f12474c497f96b40307a013cc09db --- /dev/null +++ b/Documentation/media/kapi/v4l2-device.rst @@ -0,0 +1,144 @@ +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 ` + (dev, :c:type:`v4l2_dev `). + +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 ` 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 `\ ->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 `\ ->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 ` 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 `). + +If the dev->driver_data field points to :c:type:`v4l2_dev `, +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 `). + +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 `). + +or: + + :c:func:`v4l2_device_put` + (:c:type:`v4l2_dev `). + +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 diff --git a/Documentation/media/kapi/v4l2-dv-timings.rst b/Documentation/media/kapi/v4l2-dv-timings.rst new file mode 100644 index 0000000000000000000000000000000000000000..55274329d229fbfec07e8f7f1fd623bd0be8c490 --- /dev/null +++ b/Documentation/media/kapi/v4l2-dv-timings.rst @@ -0,0 +1,4 @@ +V4L2 DV Timings functions +^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-dv-timings.h diff --git a/Documentation/media/kapi/v4l2-event.rst b/Documentation/media/kapi/v4l2-event.rst new file mode 100644 index 0000000000000000000000000000000000000000..f962686a7b63ba81fdddbc97d24027ebdb8223d8 --- /dev/null +++ b/Documentation/media/kapi/v4l2-event.rst @@ -0,0 +1,137 @@ + +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 ` + (:c:type:`vdev `, :ref:`ev `) + +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 ` + (:c:type:`fh `, :ref:`sub ` , + elems, :c:type:`ops `) + + +This function is used to implement :c:type:`video_device`-> +:c:type:`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 ` + (:c:type:`fh `, :ref:`sub `) + +This function is used to implement :c:type:`video_device`-> +:c:type:`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 ` + (:c:type:`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 + diff --git a/Documentation/media/kapi/v4l2-fh.rst b/Documentation/media/kapi/v4l2-fh.rst new file mode 100644 index 0000000000000000000000000000000000000000..9e87d5ca3e4ae80d47bd75eb1a249fb62d5e4cdb --- /dev/null +++ b/Documentation/media/kapi/v4l2-fh.rst @@ -0,0 +1,139 @@ +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 ` +(:c:type:`fh `, :c:type:`vdev `) + + +- Initialise the file handle. This **MUST** be performed in the driver's + :c:type:`v4l2_file_operations`->open() handler. + + +:c:func:`v4l2_fh_add ` +(:c:type:`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 ` +(:c:type:`fh `) + +- Unassociate the file handle from :c:type:`video_device`. The file handle + exit function may now be called. + +:c:func:`v4l2_fh_exit ` +(:c:type:`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 ` +(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 ` +(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 ` +(:c:type:`fh `) + +- Returns 1 if the file handle is the only open file handle, else 0. + +:c:func:`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 diff --git a/Documentation/media/kapi/v4l2-flash-led-class.rst b/Documentation/media/kapi/v4l2-flash-led-class.rst new file mode 100644 index 0000000000000000000000000000000000000000..20798bdac3872c0ebc0059e379a031716739b355 --- /dev/null +++ b/Documentation/media/kapi/v4l2-flash-led-class.rst @@ -0,0 +1,4 @@ +V4L2 flash functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-flash-led-class.h diff --git a/Documentation/media/kapi/v4l2-intro.rst b/Documentation/media/kapi/v4l2-intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..e614d8d4ca1c4041963942fc5d08c1e1c311e12d --- /dev/null +++ b/Documentation/media/kapi/v4l2-intro.rst @@ -0,0 +1,74 @@ +Introduction +------------ + +The V4L2 drivers tend to be very complex due to the complexity of the +hardware: most devices have multiple ICs, export multiple device nodes in +/dev, and create also non-V4L2 devices such as DVB, ALSA, FB, I2C and input +(IR) devices. + +Especially the fact that V4L2 drivers have to setup supporting ICs to +do audio/video muxing/encoding/decoding makes it more complex than most. +Usually these ICs are connected to the main bridge driver through one or +more I2C busses, but other busses can also be used. Such devices are +called 'sub-devices'. + +For a long time the framework was limited to the video_device struct for +creating V4L device nodes and video_buf for handling the video buffers +(note that this document does not discuss the video_buf framework). + +This meant that all drivers had to do the setup of device instances and +connecting to sub-devices themselves. Some of this is quite complicated +to do right and many drivers never did do it correctly. + +There is also a lot of common code that could never be refactored due to +the lack of a framework. + +So this framework sets up the basic building blocks that all drivers +need and this same framework should make it much easier to refactor +common code into utility functions shared by all drivers. + +A good example to look at as a reference is the v4l2-pci-skeleton.c +source that is available in samples/v4l/. It is a skeleton driver for +a PCI capture card, and demonstrates how to use the V4L2 driver +framework. It can be used as a template for real PCI video capture driver. + +Structure of a V4L driver +------------------------- + +All drivers have the following structure: + +1) A struct for each device instance containing the device state. + +2) A way of initializing and commanding sub-devices (if any). + +3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX) + and keeping track of device-node specific data. + +4) Filehandle-specific structs containing per-filehandle data; + +5) video buffer handling. + +This is a rough schematic of how it all relates: + +.. code-block:: none + + device instances + | + +-sub-device instances + | + \-V4L2 device nodes + | + \-filehandle instances + + +Structure of the V4L2 framework +------------------------------- + +The framework closely resembles the driver structure: it has a v4l2_device +struct for the device instance data, a v4l2_subdev struct to refer to +sub-device instances, the video_device struct stores V4L2 device node data +and the v4l2_fh struct keeps track of filehandle instances. + +The V4L2 framework also optionally integrates with the media framework. If a +driver sets the struct v4l2_device mdev field, sub-devices and video nodes +will automatically appear in the media framework as entities. diff --git a/Documentation/media/kapi/v4l2-mc.rst b/Documentation/media/kapi/v4l2-mc.rst new file mode 100644 index 0000000000000000000000000000000000000000..8af3470134906e345f7279c26e5c9feac5ac5199 --- /dev/null +++ b/Documentation/media/kapi/v4l2-mc.rst @@ -0,0 +1,4 @@ +V4L2 Media Controller functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-mc.h diff --git a/Documentation/media/kapi/v4l2-mediabus.rst b/Documentation/media/kapi/v4l2-mediabus.rst new file mode 100644 index 0000000000000000000000000000000000000000..e64131906d11711fe0c27bf6d3657bad5bdd5473 --- /dev/null +++ b/Documentation/media/kapi/v4l2-mediabus.rst @@ -0,0 +1,4 @@ +V4L2 Media Bus functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-mediabus.h diff --git a/Documentation/media/kapi/v4l2-mem2mem.rst b/Documentation/media/kapi/v4l2-mem2mem.rst new file mode 100644 index 0000000000000000000000000000000000000000..5536b4a71e5103f558f253b2a836467e1d0c746f --- /dev/null +++ b/Documentation/media/kapi/v4l2-mem2mem.rst @@ -0,0 +1,4 @@ +V4L2 Memory to Memory functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-mem2mem.h diff --git a/Documentation/media/kapi/v4l2-of.rst b/Documentation/media/kapi/v4l2-of.rst new file mode 100644 index 0000000000000000000000000000000000000000..1ddf76b00944da279d137db91ea55651ac85d73c --- /dev/null +++ b/Documentation/media/kapi/v4l2-of.rst @@ -0,0 +1,3 @@ +V4L2 Open Firmware kAPI +^^^^^^^^^^^^^^^^^^^^^^^ +.. kernel-doc:: include/media/v4l2-of.h diff --git a/Documentation/media/kapi/v4l2-rect.rst b/Documentation/media/kapi/v4l2-rect.rst new file mode 100644 index 0000000000000000000000000000000000000000..8df5067ad57dced4a799686fe1160d3855757769 --- /dev/null +++ b/Documentation/media/kapi/v4l2-rect.rst @@ -0,0 +1,4 @@ +V4L2 rect helper functions +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/v4l2-rect.h diff --git a/Documentation/media/kapi/v4l2-subdev.rst b/Documentation/media/kapi/v4l2-subdev.rst new file mode 100644 index 0000000000000000000000000000000000000000..d767b61e984292a3ebcc880b81c58024204736b9 --- /dev/null +++ b/Documentation/media/kapi/v4l2-subdev.rst @@ -0,0 +1,445 @@ +V4L2 sub-devices +---------------- + +Many drivers need to communicate with sub-devices. These devices can do all +sort of tasks, but most commonly they handle audio and/or video muxing, +encoding or decoding. For webcams common sub-devices are sensors and camera +controllers. + +Usually these are I2C devices, but not necessarily. In order to provide the +driver with a consistent interface to these sub-devices the +:c:type:`v4l2_subdev` struct (v4l2-subdev.h) was created. + +Each sub-device driver must have a :c:type:`v4l2_subdev` struct. This struct +can be stand-alone for simple sub-devices or it might be embedded in a larger +struct if more state information needs to be stored. Usually there is a +low-level device struct (e.g. ``i2c_client``) that contains the device data as +setup by the kernel. It is recommended to store that pointer in the private +data of :c:type:`v4l2_subdev` using :c:func:`v4l2_set_subdevdata`. That makes +it easy to go from a :c:type:`v4l2_subdev` to the actual low-level bus-specific +device data. + +You also need a way to go from the low-level struct to :c:type:`v4l2_subdev`. +For the common i2c_client struct the i2c_set_clientdata() call is used to store +a :c:type:`v4l2_subdev` pointer, for other busses you may have to use other +methods. + +Bridges might also need to store per-subdev private data, such as a pointer to +bridge-specific per-subdev private data. The :c:type:`v4l2_subdev` structure +provides host private data for that purpose that can be accessed with +:c:func:`v4l2_get_subdev_hostdata` and :cpp:func:`v4l2_set_subdev_hostdata`. + +From the bridge driver perspective, you load the sub-device module and somehow +obtain the :c:type:`v4l2_subdev` pointer. For i2c devices this is easy: you call +``i2c_get_clientdata()``. For other busses something similar needs to be done. +Helper functions exists for sub-devices on an I2C bus that do most of this +tricky work for you. + +Each :c:type:`v4l2_subdev` contains function pointers that sub-device drivers +can implement (or leave ``NULL`` if it is not applicable). Since sub-devices can +do so many different things and you do not want to end up with a huge ops struct +of which only a handful of ops are commonly implemented, the function pointers +are sorted according to category and each category has its own ops struct. + +The top-level ops struct contains pointers to the category ops structs, which +may be NULL if the subdev driver does not support anything from that category. + +It looks like this: + +.. code-block:: c + + struct v4l2_subdev_core_ops { + int (*log_status)(struct v4l2_subdev *sd); + int (*init)(struct v4l2_subdev *sd, u32 val); + ... + }; + + struct v4l2_subdev_tuner_ops { + ... + }; + + struct v4l2_subdev_audio_ops { + ... + }; + + struct v4l2_subdev_video_ops { + ... + }; + + struct v4l2_subdev_pad_ops { + ... + }; + + struct v4l2_subdev_ops { + const struct v4l2_subdev_core_ops *core; + const struct v4l2_subdev_tuner_ops *tuner; + const struct v4l2_subdev_audio_ops *audio; + const struct v4l2_subdev_video_ops *video; + const struct v4l2_subdev_pad_ops *video; + }; + +The core ops are common to all subdevs, the other categories are implemented +depending on the sub-device. E.g. a video device is unlikely to support the +audio ops and vice versa. + +This setup limits the number of function pointers while still making it easy +to add new ops and categories. + +A sub-device driver initializes the :c:type:`v4l2_subdev` struct using: + + :c:func:`v4l2_subdev_init ` + (:c:type:`sd `, &\ :c:type:`ops `). + + +Afterwards you need to initialize :c:type:`sd `->name with a +unique name and set the module owner. This is done for you if you use the +i2c helper functions. + +If integration with the media framework is needed, you must initialize the +:c:type:`media_entity` struct embedded in the :c:type:`v4l2_subdev` struct +(entity field) by calling :c:func:`media_entity_pads_init`, if the entity has +pads: + +.. code-block:: c + + struct media_pad *pads = &my_sd->pads; + int err; + + err = media_entity_pads_init(&sd->entity, npads, pads); + +The pads array must have been previously initialized. There is no need to +manually set the struct :c:type:`media_entity` function and name fields, but the +revision field must be initialized if needed. + +A reference to the entity will be automatically acquired/released when the +subdev device node (if any) is opened/closed. + +Don't forget to cleanup the media entity before the sub-device is destroyed: + +.. code-block:: c + + media_entity_cleanup(&sd->entity); + +If the subdev driver intends to process video and integrate with the media +framework, it must implement format related functionality using +:c:type:`v4l2_subdev_pad_ops` instead of :c:type:`v4l2_subdev_video_ops`. + +In that case, the subdev driver may set the link_validate field to provide +its own link validation function. The link validation function is called for +every link in the pipeline where both of the ends of the links are V4L2 +sub-devices. The driver is still responsible for validating the correctness +of the format configuration between sub-devices and video nodes. + +If link_validate op is not set, the default function +:c:func:`v4l2_subdev_link_validate_default` is used instead. This function +ensures that width, height and the media bus pixel code are equal on both source +and sink of the link. Subdev drivers are also free to use this function to +perform the checks mentioned above in addition to their own checks. + +There are currently two ways to register subdevices with the V4L2 core. The +first (traditional) possibility is to have subdevices registered by bridge +drivers. This can be done when the bridge driver has the complete information +about subdevices connected to it and knows exactly when to register them. This +is typically the case for internal subdevices, like video data processing units +within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected +to SoCs, which pass information about them to bridge drivers, usually in their +platform data. + +There are however also situations where subdevices have to be registered +asynchronously to bridge devices. An example of such a configuration is a Device +Tree based system where information about subdevices is made available to the +system independently from the bridge devices, e.g. when subdevices are defined +in DT as I2C device nodes. The API used in this second case is described further +below. + +Using one or the other registration method only affects the probing process, the +run-time bridge-subdevice interaction is in both cases the same. + +In the synchronous case a device (bridge) driver needs to register the +:c:type:`v4l2_subdev` with the v4l2_device: + + :c:func:`v4l2_device_register_subdev ` + (:c:type:`v4l2_dev `, :c:type:`sd `). + +This can fail if the subdev module disappeared before it could be registered. +After this function was called successfully the subdev->dev field points to +the :c:type:`v4l2_device`. + +If the v4l2_device parent device has a non-NULL mdev field, the sub-device +entity will be automatically registered with the media device. + +You can unregister a sub-device using: + + :c:func:`v4l2_device_unregister_subdev ` + (:c:type:`sd `). + + +Afterwards the subdev module can be unloaded and +:c:type:`sd `->dev == ``NULL``. + +You can call an ops function either directly: + +.. code-block:: c + + err = sd->ops->core->g_std(sd, &norm); + +but it is better and easier to use this macro: + +.. code-block:: c + + err = v4l2_subdev_call(sd, core, g_std, &norm); + +The macro will to the right ``NULL`` pointer checks and returns ``-ENODEV`` +if :c:type:`sd ` is ``NULL``, ``-ENOIOCTLCMD`` if either +:c:type:`sd `->core or :c:type:`sd `->core->g_std is ``NULL``, or the actual result of the +:c:type:`sd `->ops->core->g_std ops. + +It is also possible to call all or a subset of the sub-devices: + +.. code-block:: c + + v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm); + +Any subdev that does not support this ops is skipped and error results are +ignored. If you want to check for errors use this: + +.. code-block:: c + + err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm); + +Any error except ``-ENOIOCTLCMD`` will exit the loop with that error. If no +errors (except ``-ENOIOCTLCMD``) occurred, then 0 is returned. + +The second argument to both calls is a group ID. If 0, then all subdevs are +called. If non-zero, then only those whose group ID match that value will +be called. Before a bridge driver registers a subdev it can set +:c:type:`sd `->grp_id to whatever value it wants (it's 0 by +default). This value is owned by the bridge driver and the sub-device driver +will never modify or use it. + +The group ID gives the bridge driver more control how callbacks are called. +For example, there may be multiple audio chips on a board, each capable of +changing the volume. But usually only one will actually be used when the +user want to change the volume. You can set the group ID for that subdev to +e.g. AUDIO_CONTROLLER and specify that as the group ID value when calling +``v4l2_device_call_all()``. That ensures that it will only go to the subdev +that needs it. + +If the sub-device needs to notify its v4l2_device parent of an event, then +it can call ``v4l2_subdev_notify(sd, notification, arg)``. This macro checks +whether there is a ``notify()`` callback defined and returns ``-ENODEV`` if not. +Otherwise the result of the ``notify()`` call is returned. + +The advantage of using :c:type:`v4l2_subdev` is that it is a generic struct and +does not contain any knowledge about the underlying hardware. So a driver might +contain several subdevs that use an I2C bus, but also a subdev that is +controlled through GPIO pins. This distinction is only relevant when setting +up the device, but once the subdev is registered it is completely transparent. + +In the asynchronous case subdevice probing can be invoked independently of the +bridge driver availability. The subdevice driver then has to verify whether all +the requirements for a successful probing are satisfied. This can include a +check for a master clock availability. If any of the conditions aren't satisfied +the driver might decide to return ``-EPROBE_DEFER`` to request further reprobing +attempts. Once all conditions are met the subdevice shall be registered using +the :c:func:`v4l2_async_register_subdev` function. Unregistration is +performed using the :c:func:`v4l2_async_unregister_subdev` call. Subdevices +registered this way are stored in a global list of subdevices, ready to be +picked up by bridge drivers. + +Bridge drivers in turn have to register a notifier object with an array of +subdevice descriptors that the bridge device needs for its operation. This is +performed using the :c:func:`v4l2_async_notifier_register` call. To +unregister the notifier the driver has to call +:c:func:`v4l2_async_notifier_unregister`. The former of the two functions +takes two arguments: a pointer to struct :c:type:`v4l2_device` and a pointer to +struct :c:type:`v4l2_async_notifier`. The latter contains a pointer to an array +of pointers to subdevice descriptors of type struct :c:type:`v4l2_async_subdev` +type. The V4L2 core will then use these descriptors to match asynchronously +registered +subdevices to them. If a match is detected the ``.bound()`` notifier callback +is called. After all subdevices have been located the .complete() callback is +called. When a subdevice is removed from the system the .unbind() method is +called. All three callbacks are optional. + +V4L2 sub-device userspace API +----------------------------- + +Beside exposing a kernel API through the :c:type:`v4l2_subdev_ops` structure, +V4L2 sub-devices can also be controlled directly by userspace applications. + +Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access +sub-devices directly. If a sub-device supports direct userspace configuration +it must set the ``V4L2_SUBDEV_FL_HAS_DEVNODE`` flag before being registered. + +After registering sub-devices, the :c:type:`v4l2_device` driver can create +device nodes for all registered sub-devices marked with +``V4L2_SUBDEV_FL_HAS_DEVNODE`` by calling +:c:func:`v4l2_device_register_subdev_nodes`. Those device nodes will be +automatically removed when sub-devices are unregistered. + +The device node handles a subset of the V4L2 API. + +``VIDIOC_QUERYCTRL``, +``VIDIOC_QUERYMENU``, +``VIDIOC_G_CTRL``, +``VIDIOC_S_CTRL``, +``VIDIOC_G_EXT_CTRLS``, +``VIDIOC_S_EXT_CTRLS`` and +``VIDIOC_TRY_EXT_CTRLS``: + + The controls ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + controls implemented in the sub-device. Depending on the driver, those + controls can be also be accessed through one (or several) V4L2 device + nodes. + +``VIDIOC_DQEVENT``, +``VIDIOC_SUBSCRIBE_EVENT`` and +``VIDIOC_UNSUBSCRIBE_EVENT`` + + The events ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + events generated by the sub-device. Depending on the driver, those + events can also be reported by one (or several) V4L2 device nodes. + + Sub-device drivers that want to use events need to set the + ``V4L2_SUBDEV_USES_EVENTS`` :c:type:`v4l2_subdev`.flags and initialize + :c:type:`v4l2_subdev`.nevents to events queue depth before registering + the sub-device. After registration events can be queued as usual on the + :c:type:`v4l2_subdev`.devnode device node. + + To properly support events, the ``poll()`` file operation is also + implemented. + +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + + +I2C sub-device drivers +---------------------- + +Since these drivers are so common, special helper functions are available to +ease the use of these drivers (``v4l2-common.h``). + +The recommended method of adding :c:type:`v4l2_subdev` support to an I2C driver +is to embed the :c:type:`v4l2_subdev` struct into the state struct that is +created for each I2C device instance. Very simple devices have no state +struct and in that case you can just create a :c:type:`v4l2_subdev` directly. + +A typical state struct would look like this (where 'chipname' is replaced by +the name of the chip): + +.. code-block:: c + + struct chipname_state { + struct v4l2_subdev sd; + ... /* additional state fields */ + }; + +Initialize the :c:type:`v4l2_subdev` struct as follows: + +.. code-block:: c + + v4l2_i2c_subdev_init(&state->sd, client, subdev_ops); + +This function will fill in all the fields of :c:type:`v4l2_subdev` ensure that +the :c:type:`v4l2_subdev` and i2c_client both point to one another. + +You should also add a helper inline function to go from a :c:type:`v4l2_subdev` +pointer to a chipname_state struct: + +.. code-block:: c + + static inline struct chipname_state *to_state(struct v4l2_subdev *sd) + { + return container_of(sd, struct chipname_state, sd); + } + +Use this to go from the :c:type:`v4l2_subdev` struct to the ``i2c_client`` +struct: + +.. code-block:: c + + struct i2c_client *client = v4l2_get_subdevdata(sd); + +And this to go from an ``i2c_client`` to a :c:type:`v4l2_subdev` struct: + +.. code-block:: c + + struct v4l2_subdev *sd = i2c_get_clientdata(client); + +Make sure to call +:c:func:`v4l2_device_unregister_subdev`\ (:c:type:`sd `) +when the ``remove()`` callback is called. This will unregister the sub-device +from the bridge driver. It is safe to call this even if the sub-device was +never registered. + +You need to do this because when the bridge driver destroys the i2c adapter +the ``remove()`` callbacks are called of the i2c devices on that adapter. +After that the corresponding v4l2_subdev structures are invalid, so they +have to be unregistered first. Calling +:c:func:`v4l2_device_unregister_subdev`\ (:c:type:`sd `) +from the ``remove()`` callback ensures that this is always done correctly. + + +The bridge driver also has some helper functions it can use: + +.. code-block:: c + + struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, + "module_foo", "chipid", 0x36, NULL); + +This loads the given module (can be ``NULL`` if no module needs to be loaded) +and calls :c:func:`i2c_new_device` with the given ``i2c_adapter`` and +chip/address arguments. If all goes well, then it registers the subdev with +the v4l2_device. + +You can also use the last argument of :c:func:`v4l2_i2c_new_subdev` to pass +an array of possible I2C addresses that it should probe. These probe addresses +are only used if the previous argument is 0. A non-zero argument means that you +know the exact i2c address so in that case no probing will take place. + +Both functions return ``NULL`` if something went wrong. + +Note that the chipid you pass to :c:func:`v4l2_i2c_new_subdev` is usually +the same as the module name. It allows you to specify a chip variant, e.g. +"saa7114" or "saa7115". In general though the i2c driver autodetects this. +The use of chipid is something that needs to be looked at more closely at a +later date. It differs between i2c drivers and as such can be confusing. +To see which chip variants are supported you can look in the i2c driver code +for the i2c_device_id table. This lists all the possibilities. + +There are two more helper functions: + +:c:func:`v4l2_i2c_new_subdev_cfg`: this function adds new irq and +platform_data arguments and has both 'addr' and 'probed_addrs' arguments: +if addr is not 0 then that will be used (non-probing variant), otherwise the +probed_addrs are probed. + +For example: this will probe for address 0x10: + +.. code-block:: c + + struct v4l2_subdev *sd = v4l2_i2c_new_subdev_cfg(v4l2_dev, adapter, + "module_foo", "chipid", 0, NULL, 0, I2C_ADDRS(0x10)); + +:c:func:`v4l2_i2c_new_subdev_board` uses an :c:type:`i2c_board_info` struct +which is passed to the i2c driver and replaces the irq, platform_data and addr +arguments. + +If the subdev supports the s_config core ops, then that op is called with +the irq and platform_data arguments after the subdev was setup. + +The older :c:func:`v4l2_i2c_new_subdev` and +:c:func:`v4l2_i2c_new_probed_subdev` functions will call ``s_config`` as +well, but with irq set to 0 and platform_data set to ``NULL``. + +V4L2 sub-device functions and data structures +--------------------------------------------- + +.. kernel-doc:: include/media/v4l2-subdev.h + +.. kernel-doc:: include/media/v4l2-async.h diff --git a/Documentation/media/kapi/v4l2-tuner.rst b/Documentation/media/kapi/v4l2-tuner.rst new file mode 100644 index 0000000000000000000000000000000000000000..86e89463965142b85423bb46cb0b6e36ed9298c2 --- /dev/null +++ b/Documentation/media/kapi/v4l2-tuner.rst @@ -0,0 +1,6 @@ +Tuner functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/tuner.h + +.. kernel-doc:: include/media/tuner-types.h diff --git a/Documentation/media/kapi/v4l2-tveeprom.rst b/Documentation/media/kapi/v4l2-tveeprom.rst new file mode 100644 index 0000000000000000000000000000000000000000..33422cb26aa716b676ba0c20e94f5f85d2f28ec7 --- /dev/null +++ b/Documentation/media/kapi/v4l2-tveeprom.rst @@ -0,0 +1,4 @@ +Hauppauge TV EEPROM functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/tveeprom.h diff --git a/Documentation/video4linux/videobuf b/Documentation/media/kapi/v4l2-videobuf.rst similarity index 95% rename from Documentation/video4linux/videobuf rename to Documentation/media/kapi/v4l2-videobuf.rst index 3ffe9e960b6f65e1be78e2480573389f1d940f6c..54adfd772d28a9015c72fddc1fd465077fd05088 100644 --- a/Documentation/video4linux/videobuf +++ b/Documentation/media/kapi/v4l2-videobuf.rst @@ -1,7 +1,20 @@ -An introduction to the videobuf layer -Jonathan Corbet +.. _vb_framework: + +Videobuf Framework +================== + +Author: Jonathan Corbet + Current as of 2.6.33 +.. note:: + + The videobuf framework was deprecated in favor of videobuf2. Shouldn't + be used on new drivers. + +Introduction +------------ + The videobuf layer functions as a sort of glue layer between a V4L2 driver and user space. It handles the allocation and management of buffers for the storage of video frames. There is a set of functions which can be used @@ -14,6 +27,7 @@ author, but the payback comes in the form of reduced code in the driver and a consistent implementation of the V4L2 user-space API. Buffer types +------------ Not all video devices use the same kind of buffers. In fact, there are (at least) three common variations: @@ -48,10 +62,13 @@ the kernel and a description of this technique is currently beyond the scope of this document.] Data structures, callbacks, and initialization +---------------------------------------------- Depending on which type of buffers are being used, the driver should include one of the following files: +.. code-block:: none + /* Physically scattered */ /* vmalloc() buffers */ /* Physically contiguous */ @@ -65,6 +82,8 @@ the queue. The next step is to write four simple callbacks to help videobuf deal with the management of buffers: +.. code-block:: none + struct videobuf_queue_ops { int (*buf_setup)(struct videobuf_queue *q, unsigned int *count, unsigned int *size); @@ -91,6 +110,8 @@ passed to buf_prepare(), which should set the buffer's size, width, height, and field fields properly. If the buffer's state field is VIDEOBUF_NEEDS_INIT, the driver should pass it to: +.. code-block:: none + int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb, struct v4l2_framebuffer *fbuf); @@ -110,6 +131,8 @@ Finally, buf_release() is called when a buffer is no longer intended to be used. The driver should ensure that there is no I/O active on the buffer, then pass it to the appropriate free routine(s): +.. code-block:: none + /* Scatter/gather drivers */ int videobuf_dma_unmap(struct videobuf_queue *q, struct videobuf_dmabuf *dma); @@ -124,6 +147,8 @@ then pass it to the appropriate free routine(s): One way to ensure that a buffer is no longer under I/O is to pass it to: +.. code-block:: none + int videobuf_waiton(struct videobuf_buffer *vb, int non_blocking, int intr); Here, vb is the buffer, non_blocking indicates whether non-blocking I/O @@ -131,12 +156,15 @@ should be used (it should be zero in the buf_release() case), and intr controls whether an interruptible wait is used. File operations +--------------- At this point, much of the work is done; much of the rest is slipping videobuf calls into the implementation of the other driver callbacks. The first step is in the open() function, which must initialize the videobuf queue. The function to use depends on the type of buffer used: +.. code-block:: none + void videobuf_queue_sg_init(struct videobuf_queue *q, struct videobuf_queue_ops *ops, struct device *dev, @@ -182,6 +210,8 @@ applications have a chance of working with the device. Videobuf makes it easy to do that with the same code. To implement read(), the driver need only make a call to one of: +.. code-block:: none + ssize_t videobuf_read_one(struct videobuf_queue *q, char __user *data, size_t count, loff_t *ppos, int nonblocking); @@ -201,6 +231,8 @@ anticipation of another read() call happening in the near future). The poll() function can usually be implemented with a direct call to: +.. code-block:: none + unsigned int videobuf_poll_stream(struct file *file, struct videobuf_queue *q, poll_table *wait); @@ -213,6 +245,8 @@ the mmap() system call to enable user space to access the data. In many V4L2 drivers, the often-complex mmap() implementation simplifies to a single call to: +.. code-block:: none + int videobuf_mmap_mapper(struct videobuf_queue *q, struct vm_area_struct *vma); @@ -220,6 +254,8 @@ Everything else is handled by the videobuf code. The release() function requires two separate videobuf calls: +.. code-block:: none + void videobuf_stop(struct videobuf_queue *q); int videobuf_mmap_free(struct videobuf_queue *q); @@ -233,12 +269,15 @@ buffers are still mapped, but every driver in the 2.6.32 kernel cheerfully ignores its return value. ioctl() operations +------------------ The V4L2 API includes a very long list of driver callbacks to respond to the many ioctl() commands made available to user space. A number of these - those associated with streaming I/O - turn almost directly into videobuf calls. The relevant helper functions are: +.. code-block:: none + int videobuf_reqbufs(struct videobuf_queue *q, struct v4l2_requestbuffers *req); int videobuf_querybuf(struct videobuf_queue *q, struct v4l2_buffer *b); @@ -259,6 +298,7 @@ complex, of course, since they will also need to deal with starting and stopping the capture engine. Buffer allocation +----------------- Thus far, we have talked about buffers, but have not looked at how they are allocated. The scatter/gather case is the most complex on this front. For @@ -272,11 +312,15 @@ If the driver needs to do its own memory allocation, it should be done in the vidioc_reqbufs() function, *after* calling videobuf_reqbufs(). The first step is a call to: +.. code-block:: none + struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf); The returned videobuf_dmabuf structure (defined in ) includes a couple of relevant fields: +.. code-block:: none + struct scatterlist *sglist; int sglen; @@ -300,6 +344,7 @@ kernel drivers, or those contained within huge pages, will work with these drivers. Filling the buffers +------------------- The final part of a videobuf implementation has no direct callback - it's the portion of the code which actually puts frame data into the buffers, @@ -331,10 +376,14 @@ For scatter/gather drivers, the needed memory pointers will be found in the scatterlist structure described above. Drivers using the vmalloc() method can get a memory pointer with: +.. code-block:: none + void *videobuf_to_vmalloc(struct videobuf_buffer *buf); For contiguous DMA drivers, the function to use is: +.. code-block:: none + dma_addr_t videobuf_to_dma_contig(struct videobuf_buffer *buf); The contiguous DMA API goes out of its way to hide the kernel-space address diff --git a/Documentation/media/kapi/v4l2-videobuf2.rst b/Documentation/media/kapi/v4l2-videobuf2.rst new file mode 100644 index 0000000000000000000000000000000000000000..3c4cb1e7e05f29b3aae5f13750cfa3c46a67f2b5 --- /dev/null +++ b/Documentation/media/kapi/v4l2-videobuf2.rst @@ -0,0 +1,10 @@ +.. _vb2_framework: + +V4L2 videobuf2 functions and data structures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. kernel-doc:: include/media/videobuf2-core.h + +.. kernel-doc:: include/media/videobuf2-v4l2.h + +.. kernel-doc:: include/media/videobuf2-memops.h diff --git a/Documentation/media/lirc.h.rst.exceptions b/Documentation/media/lirc.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..246c850151d71343b0d212fbbc0f4f631590bfc0 --- /dev/null +++ b/Documentation/media/lirc.h.rst.exceptions @@ -0,0 +1,43 @@ +# Ignore header name +ignore define _LINUX_LIRC_H + +# Ignore helper macros + +ignore define lirc_t + +ignore define LIRC_SPACE +ignore define LIRC_PULSE +ignore define LIRC_FREQUENCY +ignore define LIRC_TIMEOUT +ignore define LIRC_VALUE +ignore define LIRC_MODE2 +ignore define LIRC_IS_SPACE +ignore define LIRC_IS_PULSE +ignore define LIRC_IS_FREQUENCY +ignore define LIRC_IS_TIMEOUT + +ignore define LIRC_MODE2SEND +ignore define LIRC_SEND2MODE +ignore define LIRC_MODE2REC +ignore define LIRC_REC2MODE + +ignore define LIRC_CAN_SEND +ignore define LIRC_CAN_REC + +ignore define LIRC_CAN_SEND_MASK +ignore define LIRC_CAN_REC_MASK +ignore define LIRC_CAN_SET_REC_DUTY_CYCLE + +# Undocumented macros + +ignore define PULSE_BIT +ignore define PULSE_MASK + +ignore define LIRC_MODE2_SPACE +ignore define LIRC_MODE2_PULSE +ignore define LIRC_MODE2_TIMEOUT + +ignore define LIRC_VALUE_MASK +ignore define LIRC_MODE2_MASK + +ignore define LIRC_MODE_RAW diff --git a/Documentation/media/media.h.rst.exceptions b/Documentation/media/media.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..83d7f7c722fb957a6e27058360c74afcfc83c56f --- /dev/null +++ b/Documentation/media/media.h.rst.exceptions @@ -0,0 +1,30 @@ +# Ignore header name +ignore define __LINUX_MEDIA_H + +# Ignore macros +ignore define MEDIA_API_VERSION +ignore define MEDIA_ENT_F_BASE +ignore define MEDIA_ENT_F_OLD_BASE +ignore define MEDIA_ENT_F_OLD_SUBDEV_BASE +ignore define MEDIA_INTF_T_DVB_BASE +ignore define MEDIA_INTF_T_V4L_BASE +ignore define MEDIA_INTF_T_ALSA_BASE + +#ignore legacy entity type macros +ignore define MEDIA_ENT_TYPE_SHIFT +ignore define MEDIA_ENT_TYPE_MASK +ignore define MEDIA_ENT_SUBTYPE_MASK +ignore define MEDIA_ENT_T_DEVNODE_UNKNOWN +ignore define MEDIA_ENT_T_DEVNODE +ignore define MEDIA_ENT_T_DEVNODE_V4L +ignore define MEDIA_ENT_T_DEVNODE_FB +ignore define MEDIA_ENT_T_DEVNODE_ALSA +ignore define MEDIA_ENT_T_DEVNODE_DVB +ignore define MEDIA_ENT_T_UNKNOWN +ignore define MEDIA_ENT_T_V4L2_VIDEO +ignore define MEDIA_ENT_T_V4L2_SUBDEV +ignore define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR +ignore define MEDIA_ENT_T_V4L2_SUBDEV_FLASH +ignore define MEDIA_ENT_T_V4L2_SUBDEV_LENS +ignore define MEDIA_ENT_T_V4L2_SUBDEV_DECODER +ignore define MEDIA_ENT_T_V4L2_SUBDEV_TUNER diff --git a/Documentation/media/media_api_files/typical_media_device.pdf b/Documentation/media/media_api_files/typical_media_device.pdf new file mode 100644 index 0000000000000000000000000000000000000000..eb30458138157e452e701af0bce24d00dd2e17f6 Binary files /dev/null and b/Documentation/media/media_api_files/typical_media_device.pdf differ diff --git a/Documentation/media/media_api_files/typical_media_device.svg b/Documentation/media/media_api_files/typical_media_device.svg new file mode 100644 index 0000000000000000000000000000000000000000..f0c82f72c4b684b82e75c347d794dc904ceb6434 --- /dev/null +++ b/Documentation/media/media_api_files/typical_media_device.svg @@ -0,0 +1,28 @@ + +Audio decoder +Video decoder +Audio encoder +Button Key/IR input logic +EEPROM +Sensor +System Bus +Demux +Conditional Access Module +Video encoder +Radio / Analog TV +Digital TV +PS.: picture is not complete: other blocks may be present +Webcam +Processing blocks +Smartcard +TunerFM/TV +Satellite Equipment Control (SEC) +Demod +I2C Bus (control bus) +Digital TV Frontend + +CPU +PCI, USB, SPI, I2C, ... +Bridge + DMA + diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst new file mode 100644 index 0000000000000000000000000000000000000000..b71e8e8048cad8a492b7573e30ecd652f7a2bb78 --- /dev/null +++ b/Documentation/media/media_kapi.rst @@ -0,0 +1,34 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +=================================== +Media subsystem kernel internal API +=================================== + +**Copyright** |copy| 2009-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; either version 2 of the License, or (at your option) any +later version. + +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: + + kapi/v4l2-core + kapi/dtv-core + kapi/rc-core + kapi/mc-core diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst new file mode 100644 index 0000000000000000000000000000000000000000..fd8ebe002cd200614722616cc0d1b089927b2877 --- /dev/null +++ b/Documentation/media/media_uapi.rst @@ -0,0 +1,31 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +######################################## +Linux Media Infrastructure userspace API +######################################## + +**Copyright** |copy| 2009-2016 : LinuxTV Developers + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.1 or +any later version published by the Free Software Foundation. A copy of +the license is included in the chapter entitled "GNU Free Documentation +License". + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 1 + + intro + uapi/v4l/v4l2 + uapi/dvb/dvbapi + uapi/rc/remote_controllers + uapi/mediactl/media-controller + uapi/cec/cec-api + uapi/gen-errors + uapi/fdl-appendix diff --git a/Documentation/media/net.h.rst.exceptions b/Documentation/media/net.h.rst.exceptions new file mode 100644 index 0000000000000000000000000000000000000000..30a267483aa9600a601e9b3ed9fba0e50448e0b4 --- /dev/null +++ b/Documentation/media/net.h.rst.exceptions @@ -0,0 +1,11 @@ +# Ignore header name +ignore define _DVBNET_H_ + +# Ignore old ioctls/structs +ignore ioctl __NET_ADD_IF_OLD +ignore ioctl __NET_GET_IF_OLD +ignore struct __dvb_net_if_old + +# Macros used at struct dvb_net_if +replace define DVB_NET_FEEDTYPE_MPE dvb-net-if +replace define DVB_NET_FEEDTYPE_ULE dvb-net-if diff --git a/Documentation/media/uapi/cec/cec-api.rst b/Documentation/media/uapi/cec/cec-api.rst new file mode 100644 index 0000000000000000000000000000000000000000..bb018709970cf1ed504f44cc1854bf6643d0c0e1 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-api.rst @@ -0,0 +1,43 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +.. _cec: + +######################################### +Part V - Consumer Electronics Control API +######################################### + +This part describes the CEC: Consumer Electronics Control + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 5 + :numbered: + + cec-intro + cec-funcs + cec-header + + +********************** +Revision and Copyright +********************** +Authors: + +- Verkuil, Hans + + - Initial version. + +**Copyright** |copy| 2016 : Hans Verkuil + +**************** +Revision History +**************** + +:revision: 1.0.0 / 2016-03-17 (*hv*) + +Initial revision diff --git a/Documentation/media/uapi/cec/cec-func-close.rst b/Documentation/media/uapi/cec/cec-func-close.rst new file mode 100644 index 0000000000000000000000000000000000000000..bb94e435891072f329e68d180a48bd8422839e27 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-close.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-close: + +*********** +cec close() +*********** + +Name +==== + +cec-close - Close a cec device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int close( int fd ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +Closes the cec device. Resources associated with the file descriptor are +freed. The device configuration remain unchanged. + + +Return Value +============ + +:c:func:`close()` returns 0 on success. On error, -1 is returned, and +``errno`` is set appropriately. Possible error codes are: + +``EBADF`` + ``fd`` is not a valid open file descriptor. diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst b/Documentation/media/uapi/cec/cec-func-ioctl.rst new file mode 100644 index 0000000000000000000000000000000000000000..d0279e6d2734db1c8c7c1ce9b8b085f3b4ba5ffd --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst @@ -0,0 +1,68 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-ioctl: + +*********** +cec ioctl() +*********** + +Name +==== + +cec-ioctl - Control a cec device + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int ioctl( int fd, int request, void *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC ioctl request code as defined in the cec.h header file, for + example :ref:`CEC_ADAP_G_CAPS`. + +``argp`` + Pointer to a request-specific structure. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +The :c:func:`ioctl()` function manipulates cec device parameters. The +argument ``fd`` must be an open file descriptor. + +The ioctl ``request`` code specifies the cec function to be called. It +has encoded in it whether the argument is an input, output or read/write +parameter, and the size of the argument ``argp`` in bytes. + +Macros and structures definitions specifying cec ioctl requests and +their parameters are located in the cec.h header file. All cec ioctl +requests, their respective function and parameters are specified in +:ref:`cec-user-func`. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +Request-specific error codes are listed in the individual requests +descriptions. + +When an ioctl that takes an output or read/write parameter fails, the +parameter remains unmodified. diff --git a/Documentation/media/uapi/cec/cec-func-open.rst b/Documentation/media/uapi/cec/cec-func-open.rst new file mode 100644 index 0000000000000000000000000000000000000000..38fd7e0cfccd379ba332622a01dec59ab7764d84 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-open.rst @@ -0,0 +1,80 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-open: + +********** +cec open() +********** + +Name +==== + +cec-open - Open a cec device + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int open( const char *device_name, int flags ) + + +Arguments +========= + +``device_name`` + Device to be opened. + +``flags`` + Open flags. Access mode must be ``O_RDWR``. + + When the ``O_NONBLOCK`` flag is given, the + :ref:`CEC_RECEIVE ` and :ref:`CEC_DQEVENT ` ioctls + will return the ``EAGAIN`` error code when no message or event is available, and + ioctls :ref:`CEC_TRANSMIT `, + :ref:`CEC_ADAP_S_PHYS_ADDR ` and + :ref:`CEC_ADAP_S_LOG_ADDRS ` + all return 0. + + Other flags have no effect. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To open a cec device applications call :c:func:`open()` with the +desired device name. The function has no side effects; the device +configuration remain unchanged. + +When the device is opened in read-only mode, attempts to modify its +configuration will result in an error, and ``errno`` will be set to +EBADF. + + +Return Value +============ + +:c:func:`open()` returns the new file descriptor on success. On error, +-1 is returned, and ``errno`` is set appropriately. Possible error codes +include: + +``EACCES`` + The requested access to the file is not allowed. + +``EMFILE`` + The process already has the maximum number of files open. + +``ENFILE`` + The system limit on the total number of open files has been reached. + +``ENOMEM`` + Insufficient kernel memory was available. + +``ENXIO`` + No device corresponding to this device special file exists. diff --git a/Documentation/media/uapi/cec/cec-func-poll.rst b/Documentation/media/uapi/cec/cec-func-poll.rst new file mode 100644 index 0000000000000000000000000000000000000000..fcab65f6d6b8889f02eedc81ebc43a8727159475 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-poll.rst @@ -0,0 +1,70 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-poll: + +********** +cec poll() +********** + +Name +==== + +cec-poll - Wait for some event on a file descriptor + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout ) + +Arguments +========= + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +With the :c:func:`poll()` function applications can wait for CEC +events. + +On success :c:func:`poll()` returns the number of file descriptors +that have been selected (that is, file descriptors for which the +``revents`` field of the respective :c:type:`struct pollfd` structure +is non-zero). CEC devices set the ``POLLIN`` and ``POLLRDNORM`` flags in +the ``revents`` field if there are messages in the receive queue. If the +transmit queue has room for new messages, the ``POLLOUT`` and +``POLLWRNORM`` flags are set. If there are events in the event queue, +then the ``POLLPRI`` flag is set. When the function timed out it returns +a value of zero, on failure it returns -1 and the ``errno`` variable is +set appropriately. + +For more details see the :c:func:`poll()` manual page. + + +Return Value +============ + +On success, :c:func:`poll()` returns the number structures which have +non-zero ``revents`` fields, or zero if the call timed out. On error -1 +is returned, and the ``errno`` variable is set appropriately: + +``EBADF`` + One or more of the ``ufds`` members specify an invalid file + descriptor. + +``EFAULT`` + ``ufds`` references an inaccessible memory area. + +``EINTR`` + The call was interrupted by a signal. + +``EINVAL`` + The ``nfds`` argument is greater than ``OPEN_MAX``. diff --git a/Documentation/media/uapi/cec/cec-funcs.rst b/Documentation/media/uapi/cec/cec-funcs.rst new file mode 100644 index 0000000000000000000000000000000000000000..5b7630f2e076f5046d2bdbe47ef848f883f26a08 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-funcs.rst @@ -0,0 +1,21 @@ +.. _cec-user-func: + +****************** +Function Reference +****************** + + +.. toctree:: + :maxdepth: 1 + :numbered: + + cec-func-open + cec-func-close + cec-func-ioctl + cec-func-poll + cec-ioc-adap-g-caps + cec-ioc-adap-g-log-addrs + cec-ioc-adap-g-phys-addr + cec-ioc-dqevent + cec-ioc-g-mode + cec-ioc-receive diff --git a/Documentation/media/uapi/cec/cec-header.rst b/Documentation/media/uapi/cec/cec-header.rst new file mode 100644 index 0000000000000000000000000000000000000000..d5a9a2828274c5e58126b2a607ebeed6e78e00d8 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-header.rst @@ -0,0 +1,10 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec_header: + +*************** +CEC Header File +*************** + +.. kernel-include:: $BUILDDIR/cec.h.rst + diff --git a/Documentation/media/uapi/cec/cec-intro.rst b/Documentation/media/uapi/cec/cec-intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..afa76f26fdde285f052a9e79c054ff594799c03d --- /dev/null +++ b/Documentation/media/uapi/cec/cec-intro.rst @@ -0,0 +1,31 @@ +.. _cec-intro: + +Introduction +============ + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +HDMI connectors provide a single pin for use by the Consumer Electronics +Control protocol. This protocol allows different devices connected by an +HDMI cable to communicate. The protocol for CEC version 1.4 is defined +in supplements 1 (CEC) and 2 (HEAC or HDMI Ethernet and Audio Return +Channel) of the HDMI 1.4a (:ref:`hdmi`) specification and the +extensions added to CEC version 2.0 are defined in chapter 11 of the +HDMI 2.0 (:ref:`hdmi2`) specification. + +The bitrate is very slow (effectively no more than 36 bytes per second) +and is based on the ancient AV.link protocol used in old SCART +connectors. The protocol closely resembles a crazy Rube Goldberg +contraption and is an unholy mix of low and high level messages. Some +messages, especially those part of the HEAC protocol layered on top of +CEC, need to be handled by the kernel, others can be handled either by +the kernel or by userspace. + +In addition, CEC can be implemented in HDMI receivers, transmitters and +in USB devices that have an HDMI input and an HDMI output and that +control just the CEC pin. + +Drivers that support CEC will create a CEC device node (/dev/cecX) to +give userspace access to the CEC adapter. The +:ref:`CEC_ADAP_G_CAPS` ioctl will tell userspace what it is allowed to do. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst new file mode 100644 index 0000000000000000000000000000000000000000..eaedc63186e6f7088aea28020e1f5cd2e8365f71 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst @@ -0,0 +1,165 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_G_CAPS: + +********************* +ioctl CEC_ADAP_G_CAPS +********************* + +Name +==== + +CEC_ADAP_G_CAPS - Query device capabilities + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_caps *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_ADAP_G_CAPS + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS `. To query +device information, applications call the ioctl with a pointer to a +struct :ref:`cec_caps `. The driver fills the structure and +returns the information to the application. The ioctl never fails. + + +.. _cec-caps: + +.. flat-table:: struct cec_caps + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - char + + - ``driver[32]`` + + - The name of the cec adapter driver. + + - .. row 2 + + - char + + - ``name[32]`` + + - The name of this CEC adapter. The combination ``driver`` and + ``name`` must be unique. + + - .. row 3 + + - __u32 + + - ``capabilities`` + + - The capabilities of the CEC adapter, see + :ref:`cec-capabilities`. + + - .. row 4 + + - __u32 + + - ``version`` + + - CEC Framework API version, formatted with the ``KERNEL_VERSION()`` + macro. + + + +.. _cec-capabilities: + +.. flat-table:: CEC Capabilities Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 8 + + + - .. _`CEC-CAP-PHYS-ADDR`: + + - ``CEC_CAP_PHYS_ADDR`` + + - 0x00000001 + + - Userspace has to configure the physical address by calling + :ref:`ioctl CEC_ADAP_S_PHYS_ADDR `. If + this capability isn't set, then setting the physical address is + handled by the kernel whenever the EDID is set (for an HDMI + receiver) or read (for an HDMI transmitter). + + - .. _`CEC-CAP-LOG-ADDRS`: + + - ``CEC_CAP_LOG_ADDRS`` + + - 0x00000002 + + - Userspace has to configure the logical addresses by calling + :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `. If + this capability isn't set, then the kernel will have configured + this. + + - .. _`CEC-CAP-TRANSMIT`: + + - ``CEC_CAP_TRANSMIT`` + + - 0x00000004 + + - Userspace can transmit CEC messages by calling + :ref:`ioctl CEC_TRANSMIT `. This implies that + userspace can be a follower as well, since being able to transmit + messages is a prerequisite of becoming a follower. If this + capability isn't set, then the kernel will handle all CEC + transmits and process all CEC messages it receives. + + - .. _`CEC-CAP-PASSTHROUGH`: + + - ``CEC_CAP_PASSTHROUGH`` + + - 0x00000008 + + - Userspace can use the passthrough mode by calling + :ref:`ioctl CEC_S_MODE `. + + - .. _`CEC-CAP-RC`: + + - ``CEC_CAP_RC`` + + - 0x00000010 + + - This adapter supports the remote control protocol. + + - .. _`CEC-CAP-MONITOR-ALL`: + + - ``CEC_CAP_MONITOR_ALL`` + + - 0x00000020 + + - The CEC hardware can monitor all messages, not just directed and + broadcast messages. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst new file mode 100644 index 0000000000000000000000000000000000000000..04ee90099676b940608a499e84aaf38d571c0d48 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst @@ -0,0 +1,436 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_LOG_ADDRS: +.. _CEC_ADAP_G_LOG_ADDRS: +.. _CEC_ADAP_S_LOG_ADDRS: + +**************************************************** +ioctls CEC_ADAP_G_LOG_ADDRS and CEC_ADAP_S_LOG_ADDRS +**************************************************** + +Name +==== + +CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - Get or set the logical addresses + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_log_addrs *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To query the current CEC logical addresses, applications call +:ref:`ioctl CEC_ADAP_G_LOG_ADDRS ` with a pointer to a +:c:type:`struct cec_log_addrs` where the driver stores the logical addresses. + +To set new logical addresses, applications fill in +:c:type:`struct cec_log_addrs` and call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` +with a pointer to this struct. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` +is only available if ``CEC_CAP_LOG_ADDRS`` is set (the ``ENOTTY`` error code is +returned otherwise). The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` +can only be called by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear existing logical addresses set ``num_log_addrs`` to 0. All other fields +will be ignored in that case. The adapter will go to the unconfigured state. + +If the physical address is valid (see :ref:`ioctl CEC_ADAP_S_PHYS_ADDR `), +then this ioctl will block until all requested logical +addresses have been claimed. If the file descriptor is in non-blocking mode then it will +not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE ` event is sent when the +logical addresses are claimed or cleared. + +Attempting to call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` when +logical address types are already defined will return with error ``EBUSY``. + + +.. _cec-log-addrs: + +.. flat-table:: struct cec_log_addrs + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u8 + + - ``log_addr[CEC_MAX_LOG_ADDRS]`` + + - The actual logical addresses that were claimed. This is set by the + driver. If no logical address could be claimed, then it is set to + ``CEC_LOG_ADDR_INVALID``. If this adapter is Unregistered, then + ``log_addr[0]`` is set to 0xf and all others to + ``CEC_LOG_ADDR_INVALID``. + + - .. row 2 + + - __u16 + + - ``log_addr_mask`` + + - The bitmask of all logical addresses this adapter has claimed. If + this adapter is Unregistered then ``log_addr_mask`` sets bit 15 + and clears all other bits. If this adapter is not configured at + all, then ``log_addr_mask`` is set to 0. Set by the driver. + + - .. row 3 + + - __u8 + + - ``cec_version`` + + - The CEC version that this adapter shall use. See + :ref:`cec-versions`. Used to implement the + ``CEC_MSG_CEC_VERSION`` and ``CEC_MSG_REPORT_FEATURES`` messages. + Note that :ref:`CEC_OP_CEC_VERSION_1_3A ` is not allowed by the CEC + framework. + + - .. row 4 + + - __u8 + + - ``num_log_addrs`` + + - Number of logical addresses to set up. Must be ≤ + ``available_log_addrs`` as returned by + :ref:`CEC_ADAP_G_CAPS`. All arrays in + this structure are only filled up to index + ``available_log_addrs``-1. The remaining array elements will be + ignored. Note that the CEC 2.0 standard allows for a maximum of 2 + logical addresses, although some hardware has support for more. + ``CEC_MAX_LOG_ADDRS`` is 4. The driver will return the actual + number of logical addresses it could claim, which may be less than + what was requested. If this field is set to 0, then the CEC + adapter shall clear all claimed logical addresses and all other + fields will be ignored. + + - .. row 5 + + - __u32 + + - ``vendor_id`` + + - The vendor ID is a 24-bit number that identifies the specific + vendor or entity. Based on this ID vendor specific commands may be + defined. If you do not want a vendor ID then set it to + ``CEC_VENDOR_ID_NONE``. + + - .. row 6 + + - __u32 + + - ``flags`` + + - Flags. No flags are defined yet, so set this to 0. + + - .. row 7 + + - char + + - ``osd_name[15]`` + + - The On-Screen Display name as is returned by the + ``CEC_MSG_SET_OSD_NAME`` message. + + - .. row 8 + + - __u8 + + - ``primary_device_type[CEC_MAX_LOG_ADDRS]`` + + - Primary device type for each logical address. See + :ref:`cec-prim-dev-types` for possible types. + + - .. row 9 + + - __u8 + + - ``log_addr_type[CEC_MAX_LOG_ADDRS]`` + + - Logical address types. See :ref:`cec-log-addr-types` for + possible types. The driver will update this with the actual + logical address type that it claimed (e.g. it may have to fallback + to :ref:`CEC_LOG_ADDR_TYPE_UNREGISTERED `). + + - .. row 10 + + - __u8 + + - ``all_device_types[CEC_MAX_LOG_ADDRS]`` + + - CEC 2.0 specific: the bit mask of all device types. See + :ref:`cec-all-dev-types-flags`. It is used in the CEC 2.0 + ``CEC_MSG_REPORT_FEATURES`` message. For CEC 1.4 you can either leave + this field to 0, or fill it in according to the CEC 2.0 guidelines to + give the CEC framework more information about the device type, even + though the framework won't use it directly in the CEC message. + + - .. row 11 + + - __u8 + + - ``features[CEC_MAX_LOG_ADDRS][12]`` + + - Features for each logical address. It is used in the CEC 2.0 + ``CEC_MSG_REPORT_FEATURES`` message. The 12 bytes include both the + RC Profile and the Device Features. For CEC 1.4 you can either leave + this field to all 0, or fill it in according to the CEC 2.0 guidelines to + give the CEC framework more information about the device type, even + though the framework won't use it directly in the CEC message. + +.. _cec-versions: + +.. flat-table:: CEC Versions + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-CEC-VERSION-1-3A`: + + - ``CEC_OP_CEC_VERSION_1_3A`` + + - 4 + + - CEC version according to the HDMI 1.3a standard. + + - .. _`CEC-OP-CEC-VERSION-1-4B`: + + - ``CEC_OP_CEC_VERSION_1_4B`` + + - 5 + + - CEC version according to the HDMI 1.4b standard. + + - .. _`CEC-OP-CEC-VERSION-2-0`: + + - ``CEC_OP_CEC_VERSION_2_0`` + + - 6 + + - CEC version according to the HDMI 2.0 standard. + + + +.. _cec-prim-dev-types: + +.. flat-table:: CEC Primary Device Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-PRIM-DEVTYPE-TV`: + + - ``CEC_OP_PRIM_DEVTYPE_TV`` + + - 0 + + - Use for a TV. + + - .. _`CEC-OP-PRIM-DEVTYPE-RECORD`: + + - ``CEC_OP_PRIM_DEVTYPE_RECORD`` + + - 1 + + - Use for a recording device. + + - .. _`CEC-OP-PRIM-DEVTYPE-TUNER`: + + - ``CEC_OP_PRIM_DEVTYPE_TUNER`` + + - 3 + + - Use for a device with a tuner. + + - .. _`CEC-OP-PRIM-DEVTYPE-PLAYBACK`: + + - ``CEC_OP_PRIM_DEVTYPE_PLAYBACK`` + + - 4 + + - Use for a playback device. + + - .. _`CEC-OP-PRIM-DEVTYPE-AUDIOSYSTEM`: + + - ``CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM`` + + - 5 + + - Use for an audio system (e.g. an audio/video receiver). + + - .. _`CEC-OP-PRIM-DEVTYPE-SWITCH`: + + - ``CEC_OP_PRIM_DEVTYPE_SWITCH`` + + - 6 + + - Use for a CEC switch. + + - .. _`CEC-OP-PRIM-DEVTYPE-VIDEOPROC`: + + - ``CEC_OP_PRIM_DEVTYPE_VIDEOPROC`` + + - 7 + + - Use for a video processor device. + + + +.. _cec-log-addr-types: + +.. flat-table:: CEC Logical Address Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-LOG-ADDR-TYPE-TV`: + + - ``CEC_LOG_ADDR_TYPE_TV`` + + - 0 + + - Use for a TV. + + - .. _`CEC-LOG-ADDR-TYPE-RECORD`: + + - ``CEC_LOG_ADDR_TYPE_RECORD`` + + - 1 + + - Use for a recording device. + + - .. _`CEC-LOG-ADDR-TYPE-TUNER`: + + - ``CEC_LOG_ADDR_TYPE_TUNER`` + + - 2 + + - Use for a tuner device. + + - .. _`CEC-LOG-ADDR-TYPE-PLAYBACK`: + + - ``CEC_LOG_ADDR_TYPE_PLAYBACK`` + + - 3 + + - Use for a playback device. + + - .. _`CEC-LOG-ADDR-TYPE-AUDIOSYSTEM`: + + - ``CEC_LOG_ADDR_TYPE_AUDIOSYSTEM`` + + - 4 + + - Use for an audio system device. + + - .. _`CEC-LOG-ADDR-TYPE-SPECIFIC`: + + - ``CEC_LOG_ADDR_TYPE_SPECIFIC`` + + - 5 + + - Use for a second TV or for a video processor device. + + - .. _`CEC-LOG-ADDR-TYPE-UNREGISTERED`: + + - ``CEC_LOG_ADDR_TYPE_UNREGISTERED`` + + - 6 + + - Use this if you just want to remain unregistered. Used for pure + CEC switches or CDC-only devices (CDC: Capability Discovery and + Control). + + + +.. _cec-all-dev-types-flags: + +.. flat-table:: CEC All Device Types Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-ALL-DEVTYPE-TV`: + + - ``CEC_OP_ALL_DEVTYPE_TV`` + + - 0x80 + + - This supports the TV type. + + - .. _`CEC-OP-ALL-DEVTYPE-RECORD`: + + - ``CEC_OP_ALL_DEVTYPE_RECORD`` + + - 0x40 + + - This supports the Recording type. + + - .. _`CEC-OP-ALL-DEVTYPE-TUNER`: + + - ``CEC_OP_ALL_DEVTYPE_TUNER`` + + - 0x20 + + - This supports the Tuner type. + + - .. _`CEC-OP-ALL-DEVTYPE-PLAYBACK`: + + - ``CEC_OP_ALL_DEVTYPE_PLAYBACK`` + + - 0x10 + + - This supports the Playback type. + + - .. _`CEC-OP-ALL-DEVTYPE-AUDIOSYSTEM`: + + - ``CEC_OP_ALL_DEVTYPE_AUDIOSYSTEM`` + + - 0x08 + + - This supports the Audio System type. + + - .. _`CEC-OP-ALL-DEVTYPE-SWITCH`: + + - ``CEC_OP_ALL_DEVTYPE_SWITCH`` + + - 0x04 + + - This supports the CEC Switch or Video Processing type. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst new file mode 100644 index 0000000000000000000000000000000000000000..b955d044b3349cce8daca65f8f4d0e8d48870afa --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst @@ -0,0 +1,82 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_PHYS_ADDR: +.. _CEC_ADAP_G_PHYS_ADDR: +.. _CEC_ADAP_S_PHYS_ADDR: + +**************************************************** +ioctls CEC_ADAP_G_PHYS_ADDR and CEC_ADAP_S_PHYS_ADDR +**************************************************** + +Name +==== + +CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR - Get or set the physical address + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u16 *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To query the current physical address applications call +:ref:`ioctl CEC_ADAP_G_PHYS_ADDR ` with a pointer to a __u16 where the +driver stores the physical address. + +To set a new physical address applications store the physical address in +a __u16 and call :ref:`ioctl CEC_ADAP_S_PHYS_ADDR ` with a pointer to +this integer. The :ref:`ioctl CEC_ADAP_S_PHYS_ADDR ` is only available if +``CEC_CAP_PHYS_ADDR`` is set (the ``ENOTTY`` error code will be returned +otherwise). The :ref:`ioctl CEC_ADAP_S_PHYS_ADDR ` can only be called +by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear an existing physical address use ``CEC_PHYS_ADDR_INVALID``. +The adapter will go to the unconfigured state. + +If logical address types have been defined (see :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `), +then this ioctl will block until all +requested logical addresses have been claimed. If the file descriptor is in non-blocking mode +then it will not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE ` event is sent when the physical address +changes. + +The physical address is a 16-bit number where each group of 4 bits +represent a digit of the physical address a.b.c.d where the most +significant 4 bits represent 'a'. The CEC root device (usually the TV) +has address 0.0.0.0. Every device that is hooked up to an input of the +TV has address a.0.0.0 (where 'a' is ≥ 1), devices hooked up to those in +turn have addresses a.b.0.0, etc. So a topology of up to 5 devices deep +is supported. The physical address a device shall use is stored in the +EDID of the sink. + +For example, the EDID for each HDMI input of the TV will have a +different physical address of the form a.0.0.0 that the sources will +read out and use as their physical address. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst new file mode 100644 index 0000000000000000000000000000000000000000..7a6d6d00ce194572f8053008397daa0395ee05dc --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst @@ -0,0 +1,231 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_DQEVENT: + +***************** +ioctl CEC_DQEVENT +***************** + +Name +==== + +CEC_DQEVENT - Dequeue a CEC event + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_event *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_DQEVENT + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +CEC devices can send asynchronous events. These can be retrieved by +calling :ref:`ioctl CEC_DQEVENT `. If the file descriptor is in +non-blocking mode and no event is pending, then it will return -1 and +set errno to the ``EAGAIN`` error code. + +The internal event queues are per-filehandle and per-event type. If +there is no more room in a queue then the last event is overwritten with +the new one. This means that intermediate results can be thrown away but +that the latest event is always available. This also means that is it +possible to read two successive events that have the same value (e.g. +two :ref:`CEC_EVENT_STATE_CHANGE ` events with +the same state). In that case the intermediate state changes were lost but +it is guaranteed that the state did change in between the two events. + + +.. _cec-event-state-change_s: + +.. flat-table:: struct cec_event_state_change + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 8 + + + - .. row 1 + + - __u16 + + - ``phys_addr`` + + - The current physical address. + + - .. row 2 + + - __u16 + + - ``log_addr_mask`` + + - The current set of claimed logical addresses. + + + +.. _cec-event-lost-msgs_s: + +.. flat-table:: struct cec_event_lost_msgs + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u32 + + - ``lost_msgs`` + + - Set to the number of lost messages since the filehandle was opened + or since the last time this event was dequeued for this + filehandle. The messages lost are the oldest messages. So when a + new message arrives and there is no more room, then the oldest + message is discarded to make room for the new one. The internal + size of the message queue guarantees that all messages received in + the last two seconds will be stored. Since messages should be + replied to within a second according to the CEC specification, + this is more than enough. + + + +.. _cec-event: + +.. flat-table:: struct cec_event + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 1 8 + + + - .. row 1 + + - __u64 + + - ``ts`` + + - Timestamp of the event in ns. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - + + - .. row 2 + + - __u32 + + - ``event`` + + - The CEC event type, see :ref:`cec-events`. + + - + + - .. row 3 + + - __u32 + + - ``flags`` + + - Event flags, see :ref:`cec-event-flags`. + + - + + - .. row 4 + + - union + + - (anonymous) + + - + - + + - .. row 5 + + - + - struct cec_event_state_change + + - ``state_change`` + + - The new adapter state as sent by the :ref:`CEC_EVENT_STATE_CHANGE ` + event. + + - .. row 6 + + - + - struct cec_event_lost_msgs + + - ``lost_msgs`` + + - The number of lost messages as sent by the :ref:`CEC_EVENT_LOST_MSGS ` + event. + + + +.. _cec-events: + +.. flat-table:: CEC Events Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-EVENT-STATE-CHANGE`: + + - ``CEC_EVENT_STATE_CHANGE`` + + - 1 + + - Generated when the CEC Adapter's state changes. When open() is + called an initial event will be generated for that filehandle with + the CEC Adapter's state at that time. + + - .. _`CEC-EVENT-LOST-MSGS`: + + - ``CEC_EVENT_LOST_MSGS`` + + - 2 + + - Generated if one or more CEC messages were lost because the + application didn't dequeue CEC messages fast enough. + + + +.. _cec-event-flags: + +.. flat-table:: CEC Event Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 8 + + + - .. _`CEC-EVENT-FL-INITIAL-VALUE`: + + - ``CEC_EVENT_FL_INITIAL_VALUE`` + + - 1 + + - Set for the initial events that are generated when the device is + opened. See the table above for which events do this. This allows + applications to learn the initial state of the CEC adapter at + open() time. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..f0084d892db67eeb3f5bbe2625063e97a3a4d134 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst @@ -0,0 +1,295 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_MODE: +.. _CEC_G_MODE: +.. _CEC_S_MODE: + +******************************** +ioctls CEC_G_MODE and CEC_S_MODE +******************************** + +CEC_G_MODE, CEC_S_MODE - Get or set exclusive use of the CEC adapter + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_G_MODE, CEC_S_MODE + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +By default any filehandle can use :ref:`CEC_TRANSMIT`, but in order to prevent +applications from stepping on each others toes it must be possible to +obtain exclusive access to the CEC adapter. This ioctl sets the +filehandle to initiator and/or follower mode which can be exclusive +depending on the chosen mode. The initiator is the filehandle that is +used to initiate messages, i.e. it commands other CEC devices. The +follower is the filehandle that receives messages sent to the CEC +adapter and processes them. The same filehandle can be both initiator +and follower, or this role can be taken by two different filehandles. + +When a CEC message is received, then the CEC framework will decide how +it will be processed. If the message is a reply to an earlier +transmitted message, then the reply is sent back to the filehandle that +is waiting for it. In addition the CEC framework will process it. + +If the message is not a reply, then the CEC framework will process it +first. If there is no follower, then the message is just discarded and a +feature abort is sent back to the initiator if the framework couldn't +process it. If there is a follower, then the message is passed on to the +follower who will use :ref:`ioctl CEC_RECEIVE ` to dequeue +the new message. The framework expects the follower to make the right +decisions. + +The CEC framework will process core messages unless requested otherwise +by the follower. The follower can enable the passthrough mode. In that +case, the CEC framework will pass on most core messages without +processing them and the follower will have to implement those messages. +There are some messages that the core will always process, regardless of +the passthrough mode. See :ref:`cec-core-processing` for details. + +If there is no initiator, then any CEC filehandle can use +:ref:`ioctl CEC_TRANSMIT `. If there is an exclusive +initiator then only that initiator can call +:ref:`CEC_TRANSMIT`. The follower can of course +always call :ref:`ioctl CEC_TRANSMIT `. + +Available initiator modes are: + + +.. _cec-mode-initiator_e: + +.. flat-table:: Initiator Modes + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-MODE-NO-INITIATOR`: + + - ``CEC_MODE_NO_INITIATOR`` + + - 0x0 + + - This is not an initiator, i.e. it cannot transmit CEC messages or + make any other changes to the CEC adapter. + + - .. _`CEC-MODE-INITIATOR`: + + - ``CEC_MODE_INITIATOR`` + + - 0x1 + + - This is an initiator (the default when the device is opened) and + it can transmit CEC messages and make changes to the CEC adapter, + unless there is an exclusive initiator. + + - .. _`CEC-MODE-EXCL-INITIATOR`: + + - ``CEC_MODE_EXCL_INITIATOR`` + + - 0x2 + + - This is an exclusive initiator and this file descriptor is the + only one that can transmit CEC messages and make changes to the + CEC adapter. If someone else is already the exclusive initiator + then an attempt to become one will return the ``EBUSY`` error code + error. + + +Available follower modes are: + + +.. _cec-mode-follower_e: + +.. flat-table:: Follower Modes + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-MODE-NO-FOLLOWER`: + + - ``CEC_MODE_NO_FOLLOWER`` + + - 0x00 + + - This is not a follower (the default when the device is opened). + + - .. _`CEC-MODE-FOLLOWER`: + + - ``CEC_MODE_FOLLOWER`` + + - 0x10 + + - This is a follower and it will receive CEC messages unless there + is an exclusive follower. You cannot become a follower if + :ref:`CEC_CAP_TRANSMIT ` is not set or if :ref:`CEC_MODE_NO_INITIATOR ` + was specified, the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-EXCL-FOLLOWER`: + + - ``CEC_MODE_EXCL_FOLLOWER`` + + - 0x20 + + - This is an exclusive follower and only this file descriptor will + receive CEC messages for processing. If someone else is already + the exclusive follower then an attempt to become one will return + the ``EBUSY`` error code. You cannot become a follower if + :ref:`CEC_CAP_TRANSMIT ` is not set or if :ref:`CEC_MODE_NO_INITIATOR ` + was specified, the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-EXCL-FOLLOWER-PASSTHRU`: + + - ``CEC_MODE_EXCL_FOLLOWER_PASSTHRU`` + + - 0x30 + + - This is an exclusive follower and only this file descriptor will + receive CEC messages for processing. In addition it will put the + CEC device into passthrough mode, allowing the exclusive follower + to handle most core messages instead of relying on the CEC + framework for that. If someone else is already the exclusive + follower then an attempt to become one will return the ``EBUSY`` error + code. You cannot become a follower if :ref:`CEC_CAP_TRANSMIT ` + is not set or if :ref:`CEC_MODE_NO_INITIATOR ` was specified, + the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-MONITOR`: + + - ``CEC_MODE_MONITOR`` + + - 0xe0 + + - Put the file descriptor into monitor mode. Can only be used in + combination with :ref:`CEC_MODE_NO_INITIATOR `, otherwise EINVAL error + code will be returned. In monitor mode all messages this CEC + device transmits and all messages it receives (both broadcast + messages and directed messages for one its logical addresses) will + be reported. This is very useful for debugging. This is only + allowed if the process has the ``CAP_NET_ADMIN`` capability. If + that is not set, then the ``EPERM`` error code is returned. + + - .. _`CEC-MODE-MONITOR-ALL`: + + - ``CEC_MODE_MONITOR_ALL`` + + - 0xf0 + + - Put the file descriptor into 'monitor all' mode. Can only be used + in combination with :ref:`CEC_MODE_NO_INITIATOR `, otherwise + the ``EINVAL`` error code will be returned. In 'monitor all' mode all messages + this CEC device transmits and all messages it receives, including + directed messages for other CEC devices will be reported. This is + very useful for debugging, but not all devices support this. This + mode requires that the :ref:`CEC_CAP_MONITOR_ALL ` capability is set, + otherwise the ``EINVAL`` error code is returned. This is only allowed if + the process has the ``CAP_NET_ADMIN`` capability. If that is not + set, then the ``EPERM`` error code is returned. + + +Core message processing details: + + +.. _cec-core-processing: + +.. flat-table:: Core Message Processing + :header-rows: 0 + :stub-columns: 0 + :widths: 1 8 + + + - .. _`CEC-MSG-GET-CEC-VERSION`: + + - ``CEC_MSG_GET_CEC_VERSION`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return the CEC version that was + set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `. + + - .. _`CEC-MSG-GIVE-DEVICE-VENDOR-ID`: + + - ``CEC_MSG_GIVE_DEVICE_VENDOR_ID`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return the vendor ID that was + set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `. + + - .. _`CEC-MSG-ABORT`: + + - ``CEC_MSG_ABORT`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return a feature refused + message as per the specification. + + - .. _`CEC-MSG-GIVE-PHYSICAL-ADDR`: + + - ``CEC_MSG_GIVE_PHYSICAL_ADDR`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current physical + address. + + - .. _`CEC-MSG-GIVE-OSD-NAME`: + + - ``CEC_MSG_GIVE_OSD_NAME`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current OSD name as + was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS `. + + - .. _`CEC-MSG-GIVE-FEATURES`: + + - ``CEC_MSG_GIVE_FEATURES`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current features as + was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` + or the message is ignored if the CEC version was older than 2.0. + + - .. _`CEC-MSG-USER-CONTROL-PRESSED`: + + - ``CEC_MSG_USER_CONTROL_PRESSED`` + + - If :ref:`CEC_CAP_RC ` is set, then generate a remote control key + press. This message is always passed on to userspace. + + - .. _`CEC-MSG-USER-CONTROL-RELEASED`: + + - ``CEC_MSG_USER_CONTROL_RELEASED`` + + - If :ref:`CEC_CAP_RC ` is set, then generate a remote control key + release. This message is always passed on to userspace. + + - .. _`CEC-MSG-REPORT-PHYSICAL-ADDR`: + + - ``CEC_MSG_REPORT_PHYSICAL_ADDR`` + + - The CEC framework will make note of the reported physical address + and then just pass the message on to userspace. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst b/Documentation/media/uapi/cec/cec-ioc-receive.rst new file mode 100644 index 0000000000000000000000000000000000000000..ae5a39ade45ff588420bbd02c0325479f4dc82ff --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst @@ -0,0 +1,360 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_TRANSMIT: +.. _CEC_RECEIVE: + +*********************************** +ioctls CEC_RECEIVE and CEC_TRANSMIT +*********************************** + +Name +==== + +CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_msg *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + CEC_RECEIVE, CEC_TRANSMIT + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To receive a CEC message the application has to fill in the +``timeout`` field of :c:type:`struct cec_msg` and pass it to :ref:`ioctl CEC_RECEIVE `. +If the file descriptor is in non-blocking mode and there are no received +messages pending, then it will return -1 and set errno to the ``EAGAIN`` +error code. If the file descriptor is in blocking mode and ``timeout`` +is non-zero and no message arrived within ``timeout`` milliseconds, then +it will return -1 and set errno to the ``ETIMEDOUT`` error code. + +A received message can be: + +1. a message received from another CEC device (the ``sequence`` field will + be 0). +2. the result of an earlier non-blocking transmit (the ``sequence`` field will + be non-zero). + +To send a CEC message the application has to fill in the +:c:type:`struct cec_msg` and pass it to +:ref:`ioctl CEC_TRANSMIT `. The :ref:`ioctl CEC_TRANSMIT ` is only available if +``CEC_CAP_TRANSMIT`` is set. If there is no more room in the transmit +queue, then it will return -1 and set errno to the ``EBUSY`` error code. +The transmit queue has enough room for 18 messages (about 1 second worth +of 2-byte messages). Note that the CEC kernel framework will also reply +to core messages (see :ref:cec-core-processing), so it is not a good +idea to fully fill up the transmit queue. + +If the file descriptor is in non-blocking mode then the transmit will +return 0 and the result of the transmit will be available via +:ref:`ioctl CEC_RECEIVE ` once the transmit has finished +(including waiting for a reply, if requested). + +The ``sequence`` field is filled in for every transmit and this can be +checked against the received messages to find the corresponding transmit +result. + + +.. _cec-msg: + +.. flat-table:: struct cec_msg + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u64 + + - ``tx_ts`` + + - Timestamp in ns of when the last byte of the message was transmitted. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - .. row 2 + + - __u64 + + - ``rx_ts`` + + - Timestamp in ns of when the last byte of the message was received. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - .. row 3 + + - __u32 + + - ``len`` + + - The length of the message. For :ref:`ioctl CEC_TRANSMIT ` this is filled in + by the application. The driver will fill this in for + :ref:`ioctl CEC_RECEIVE `. For :ref:`ioctl CEC_TRANSMIT ` it will be + filled in by the driver with the length of the reply message if ``reply`` was set. + + - .. row 4 + + - __u32 + + - ``timeout`` + + - The timeout in milliseconds. This is the time the device will wait + for a message to be received before timing out. If it is set to 0, + then it will wait indefinitely when it is called by :ref:`ioctl CEC_RECEIVE `. + If it is 0 and it is called by :ref:`ioctl CEC_TRANSMIT `, + then it will be replaced by 1000 if the ``reply`` is non-zero or + ignored if ``reply`` is 0. + + - .. row 5 + + - __u32 + + - ``sequence`` + + - A non-zero sequence number is automatically assigned by the CEC framework + for all transmitted messages. It is used by the CEC framework when it queues + the transmit result (when transmit was called in non-blocking mode). This + allows the application to associate the received message with the original + transmit. + + - .. row 6 + + - __u32 + + - ``flags`` + + - Flags. No flags are defined yet, so set this to 0. + + - .. row 7 + + - __u8 + + - ``tx_status`` + + - The status bits of the transmitted message. See + :ref:`cec-tx-status` for the possible status values. It is 0 if + this messages was received, not transmitted. + + - .. row 8 + + - __u8 + + - ``msg[16]`` + + - The message payload. For :ref:`ioctl CEC_TRANSMIT ` this is filled in by the + application. The driver will fill this in for :ref:`ioctl CEC_RECEIVE `. + For :ref:`ioctl CEC_TRANSMIT ` it will be filled in by the driver with + the payload of the reply message if ``timeout`` was set. + + - .. row 8 + + - __u8 + + - ``reply`` + + - Wait until this message is replied. If ``reply`` is 0 and the + ``timeout`` is 0, then don't wait for a reply but return after + transmitting the message. Ignored by :ref:`ioctl CEC_RECEIVE `. + The case where ``reply`` is 0 (this is the opcode for the Feature Abort + message) and ``timeout`` is non-zero is specifically allowed to make it + possible to send a message and wait up to ``timeout`` milliseconds for a + Feature Abort reply. In this case ``rx_status`` will either be set + to :ref:`CEC_RX_STATUS_TIMEOUT ` or + :ref:`CEC_RX_STATUS_FEATURE_ABORT `. + + - .. row 9 + + - __u8 + + - ``rx_status`` + + - The status bits of the received message. See + :ref:`cec-rx-status` for the possible status values. It is 0 if + this message was transmitted, not received, unless this is the + reply to a transmitted message. In that case both ``rx_status`` + and ``tx_status`` are set. + + - .. row 10 + + - __u8 + + - ``tx_status`` + + - The status bits of the transmitted message. See + :ref:`cec-tx-status` for the possible status values. It is 0 if + this messages was received, not transmitted. + + - .. row 11 + + - __u8 + + - ``tx_arb_lost_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Arbitration Lost error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_ARB_LOST ` status bit is set. + + - .. row 12 + + - __u8 + + - ``tx_nack_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Not Acknowledged error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_NACK ` status bit is set. + + - .. row 13 + + - __u8 + + - ``tx_low_drive_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Arbitration Lost error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_LOW_DRIVE ` status bit is set. + + - .. row 14 + + - __u8 + + - ``tx_error_cnt`` + + - A counter of the number of transmit errors other than Arbitration + Lost or Not Acknowledged. This is only set if the hardware + supports this, otherwise it is always 0. This counter is only + valid if the :ref:`CEC_TX_STATUS_ERROR ` status bit is set. + + + +.. _cec-tx-status: + +.. flat-table:: CEC Transmit Status + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-TX-STATUS-OK`: + + - ``CEC_TX_STATUS_OK`` + + - 0x01 + + - The message was transmitted successfully. This is mutually + exclusive with :ref:`CEC_TX_STATUS_MAX_RETRIES `. Other bits can still + be set if earlier attempts met with failure before the transmit + was eventually successful. + + - .. _`CEC-TX-STATUS-ARB-LOST`: + + - ``CEC_TX_STATUS_ARB_LOST`` + + - 0x02 + + - CEC line arbitration was lost. + + - .. _`CEC-TX-STATUS-NACK`: + + - ``CEC_TX_STATUS_NACK`` + + - 0x04 + + - Message was not acknowledged. + + - .. _`CEC-TX-STATUS-LOW-DRIVE`: + + - ``CEC_TX_STATUS_LOW_DRIVE`` + + - 0x08 + + - Low drive was detected on the CEC bus. This indicates that a + follower detected an error on the bus and requests a + retransmission. + + - .. _`CEC-TX-STATUS-ERROR`: + + - ``CEC_TX_STATUS_ERROR`` + + - 0x10 + + - Some error occurred. This is used for any errors that do not fit + the previous two, either because the hardware could not tell which + error occurred, or because the hardware tested for other + conditions besides those two. + + - .. _`CEC-TX-STATUS-MAX-RETRIES`: + + - ``CEC_TX_STATUS_MAX_RETRIES`` + + - 0x20 + + - The transmit failed after one or more retries. This status bit is + mutually exclusive with :ref:`CEC_TX_STATUS_OK `. Other bits can still + be set to explain which failures were seen. + + + +.. _cec-rx-status: + +.. flat-table:: CEC Receive Status + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-RX-STATUS-OK`: + + - ``CEC_RX_STATUS_OK`` + + - 0x01 + + - The message was received successfully. + + - .. _`CEC-RX-STATUS-TIMEOUT`: + + - ``CEC_RX_STATUS_TIMEOUT`` + + - 0x02 + + - The reply to an earlier transmitted message timed out. + + - .. _`CEC-RX-STATUS-FEATURE-ABORT`: + + - ``CEC_RX_STATUS_FEATURE_ABORT`` + + - 0x04 + + - The message was received successfully but the reply was + ``CEC_MSG_FEATURE_ABORT``. This status is only set if this message + was the reply to an earlier transmitted message. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-bilingual-channel-select.rst b/Documentation/media/uapi/dvb/audio-bilingual-channel-select.rst new file mode 100644 index 0000000000000000000000000000000000000000..dbe20ff38e83729a97454e6948c2a2075b36c33b --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-bilingual-channel-select.rst @@ -0,0 +1,64 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_BILINGUAL_CHANNEL_SELECT: + +============================== +AUDIO_BILINGUAL_CHANNEL_SELECT +============================== + +Name +---- + +AUDIO_BILINGUAL_CHANNEL_SELECT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_BILINGUAL_CHANNEL_SELECT, audio_channel_select_t) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_BILINGUAL_CHANNEL_SELECT for this command. + + - .. row 3 + + - audio_channel_select_t ch + + - Select the output format of the audio (mono left/right, stereo). + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. It has been replaced +by the V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK`` control +for MPEG decoders controlled through V4L2. + +This ioctl call asks the Audio Device to select the requested channel +for bilingual streams if possible. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-channel-select.rst b/Documentation/media/uapi/dvb/audio-channel-select.rst new file mode 100644 index 0000000000000000000000000000000000000000..69df4c0f2fb25cfef123ab341abeea5c258925ce --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-channel-select.rst @@ -0,0 +1,63 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_CHANNEL_SELECT: + +==================== +AUDIO_CHANNEL_SELECT +==================== + +Name +---- + +AUDIO_CHANNEL_SELECT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_CHANNEL_SELECT, audio_channel_select_t) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_CHANNEL_SELECT for this command. + + - .. row 3 + + - audio_channel_select_t ch + + - Select the output format of the audio (mono left/right, stereo). + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead. + +This ioctl call asks the Audio Device to select the requested channel if +possible. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-clear-buffer.rst b/Documentation/media/uapi/dvb/audio-clear-buffer.rst new file mode 100644 index 0000000000000000000000000000000000000000..a3dec29bdc69856265124d95495ca9bf0b1d4f49 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-clear-buffer.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_CLEAR_BUFFER: + +================== +AUDIO_CLEAR_BUFFER +================== + +Name +---- + +AUDIO_CLEAR_BUFFER + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_CLEAR_BUFFER) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_CLEAR_BUFFER for this command. + + +Description +----------- + +This ioctl call asks the Audio Device to clear all software and hardware +buffers of the audio decoder device. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-continue.rst b/Documentation/media/uapi/dvb/audio-continue.rst new file mode 100644 index 0000000000000000000000000000000000000000..053627dd61e7a993e9d576b5b8fbf53309b53feb --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-continue.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_CONTINUE: + +============== +AUDIO_CONTINUE +============== + +Name +---- + +AUDIO_CONTINUE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_CONTINUE) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_CONTINUE for this command. + + +Description +----------- + +This ioctl restarts the decoding and playing process previously paused +with AUDIO_PAUSE command. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-fclose.rst b/Documentation/media/uapi/dvb/audio-fclose.rst new file mode 100644 index 0000000000000000000000000000000000000000..e5d4225cd9d7989dd16b239ee2c65da467e95870 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-fclose.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_fclose: + +================= +DVB audio close() +================= + +Name +---- + +DVB audio close() + + +Synopsis +-------- + +.. cpp:function:: int close(int fd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + +Description +----------- + +This system call closes a previously opened audio device. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/audio-fopen.rst b/Documentation/media/uapi/dvb/audio-fopen.rst new file mode 100644 index 0000000000000000000000000000000000000000..ec3b23aa79b383dab24bbb11d937ecbc5071a599 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-fopen.rst @@ -0,0 +1,104 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_fopen: + +================ +DVB audio open() +================ + +Name +---- + +DVB audio open() + + +Synopsis +-------- + +.. cpp:function:: int open(const char *deviceName, int flags) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - const char \*deviceName + + - Name of specific audio device. + + - .. row 2 + + - int flags + + - A bit-wise OR of the following flags: + + - .. row 3 + + - + - O_RDONLY read-only access + + - .. row 4 + + - + - O_RDWR read/write access + + - .. row 5 + + - + - O_NONBLOCK open in non-blocking mode + + - .. row 6 + + - + - (blocking mode is the default) + + +Description +----------- + +This system call opens a named audio device (e.g. +/dev/dvb/adapter0/audio0) for subsequent use. When an open() call has +succeeded, the device will be ready for use. The significance of +blocking or non-blocking mode is described in the documentation for +functions where there is a difference. It does not affect the semantics +of the open() call itself. A device opened in blocking mode can later be +put into non-blocking mode (and vice versa) using the F_SETFL command +of the fcntl system call. This is a standard system call, documented in +the Linux manual page for fcntl. Only one user can open the Audio Device +in O_RDWR mode. All other attempts to open the device in this mode will +fail, and an error code will be returned. If the Audio Device is opened +in O_RDONLY mode, the only ioctl call that can be used is +AUDIO_GET_STATUS. All other call will return with an error code. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``ENODEV`` + + - Device driver not loaded/available. + + - .. row 2 + + - ``EBUSY`` + + - Device or resource busy. + + - .. row 3 + + - ``EINVAL`` + + - Invalid argument. diff --git a/Documentation/media/uapi/dvb/audio-fwrite.rst b/Documentation/media/uapi/dvb/audio-fwrite.rst new file mode 100644 index 0000000000000000000000000000000000000000..ca95b9be0c2a5d9dd1ae4e0559b9d5e560a2d7ea --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-fwrite.rst @@ -0,0 +1,82 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_fwrite: + +================= +DVB audio write() +================= + +Name +---- + +DVB audio write() + + +Synopsis +-------- + +.. cpp:function:: size_t write(int fd, const void *buf, size_t count) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - void \*buf + + - Pointer to the buffer containing the PES data. + + - .. row 3 + + - size_t count + + - Size of buf. + + +Description +----------- + +This system call can only be used if AUDIO_SOURCE_MEMORY is selected +in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in +PES format. If O_NONBLOCK is not specified the function will block +until buffer space is available. The amount of data to be transferred is +implied by count. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EPERM`` + + - Mode AUDIO_SOURCE_MEMORY not selected. + + - .. row 2 + + - ``ENOMEM`` + + - Attempted to write more data than the internal buffer can hold. + + - .. row 3 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/audio-get-capabilities.rst b/Documentation/media/uapi/dvb/audio-get-capabilities.rst new file mode 100644 index 0000000000000000000000000000000000000000..e274a8d53785b15cbcdab249c65e2bee99ae1df3 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-get-capabilities.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_GET_CAPABILITIES: + +====================== +AUDIO_GET_CAPABILITIES +====================== + +Name +---- + +AUDIO_GET_CAPABILITIES + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_GET_CAPABILITIES, unsigned int *cap) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_GET_CAPABILITIES for this command. + + - .. row 3 + + - unsigned int \*cap + + - Returns a bit array of supported sound formats. + + +Description +----------- + +This ioctl call asks the Audio Device to tell us about the decoding +capabilities of the audio hardware. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-get-pts.rst b/Documentation/media/uapi/dvb/audio-get-pts.rst new file mode 100644 index 0000000000000000000000000000000000000000..5f875508b833013a10d173232697b7f223b5d9d8 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-get-pts.rst @@ -0,0 +1,69 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_GET_PTS: + +============= +AUDIO_GET_PTS +============= + +Name +---- + +AUDIO_GET_PTS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_GET_PTS, __u64 *pts) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_GET_PTS for this command. + + - .. row 3 + + - __u64 \*pts + + - Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / + ISO/IEC 13818-1. + + The PTS should belong to the currently played frame if possible, + but may also be a value close to it like the PTS of the last + decoded frame or the last PTS extracted by the PES parser. + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. If you need this +functionality, then please contact the linux-media mailing list +(`https://linuxtv.org/lists.php `__). + +This ioctl call asks the Audio Device to return the current PTS +timestamp. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-get-status.rst b/Documentation/media/uapi/dvb/audio-get-status.rst new file mode 100644 index 0000000000000000000000000000000000000000..cbd822773d8589a0f3a9d3f2d545970a7162a71c --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-get-status.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_GET_STATUS: + +================ +AUDIO_GET_STATUS +================ + +Name +---- + +AUDIO_GET_STATUS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_GET_STATUS, struct audio_status *status) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_GET_STATUS for this command. + + - .. row 3 + + - struct audio_status \*status + + - Returns the current state of Audio Device. + + +Description +----------- + +This ioctl call asks the Audio Device to return the current state of the +Audio Device. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-pause.rst b/Documentation/media/uapi/dvb/audio-pause.rst new file mode 100644 index 0000000000000000000000000000000000000000..9ca263e90c6c21df74dc1f8af4ddbbf7656a9acd --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-pause.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_PAUSE: + +=========== +AUDIO_PAUSE +=========== + +Name +---- + +AUDIO_PAUSE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_PAUSE) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_PAUSE for this command. + + +Description +----------- + +This ioctl call suspends the audio stream being played. Decoding and +playing are paused. It is then possible to restart again decoding and +playing process of the audio stream using AUDIO_CONTINUE command. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-play.rst b/Documentation/media/uapi/dvb/audio-play.rst new file mode 100644 index 0000000000000000000000000000000000000000..db4d7203acc5c462e5172eea8c2940c8262162fd --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-play.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_PLAY: + +========== +AUDIO_PLAY +========== + +Name +---- + +AUDIO_PLAY + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_PLAY) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_PLAY for this command. + + +Description +----------- + +This ioctl call asks the Audio Device to start playing an audio stream +from the selected source. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-select-source.rst b/Documentation/media/uapi/dvb/audio-select-source.rst new file mode 100644 index 0000000000000000000000000000000000000000..b806d806a46fef2271a22824c064ac600d768faa --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-select-source.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SELECT_SOURCE: + +=================== +AUDIO_SELECT_SOURCE +=================== + +Name +---- + +AUDIO_SELECT_SOURCE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SELECT_SOURCE, audio_stream_source_t source) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SELECT_SOURCE for this command. + + - .. row 3 + + - audio_stream_source_t source + + - Indicates the source that shall be used for the Audio stream. + + +Description +----------- + +This ioctl call informs the audio device which source shall be used for +the input data. The possible sources are demux or memory. If +AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device +through the write command. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-attributes.rst b/Documentation/media/uapi/dvb/audio-set-attributes.rst new file mode 100644 index 0000000000000000000000000000000000000000..18667cea2cdf4f95584984ca4a8a781561740c72 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-attributes.rst @@ -0,0 +1,71 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_ATTRIBUTES: + +==================== +AUDIO_SET_ATTRIBUTES +==================== + +Name +---- + +AUDIO_SET_ATTRIBUTES + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = AUDIO_SET_ATTRIBUTES, audio_attributes_t attr ) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_ATTRIBUTES for this command. + + - .. row 3 + + - audio_attributes_t attr + + - audio attributes according to section ?? + + +Description +----------- + +This ioctl is intended for DVD playback and allows you to set certain +information about the audio stream. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - attr is not a valid or supported attribute setting. diff --git a/Documentation/media/uapi/dvb/audio-set-av-sync.rst b/Documentation/media/uapi/dvb/audio-set-av-sync.rst new file mode 100644 index 0000000000000000000000000000000000000000..6f7e26fa4cd17a76c4a3351bf3472be6e786b57f --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-av-sync.rst @@ -0,0 +1,70 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_AV_SYNC: + +================= +AUDIO_SET_AV_SYNC +================= + +Name +---- + +AUDIO_SET_AV_SYNC + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SET_AV_SYNC, boolean state) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_AV_SYNC for this command. + + - .. row 3 + + - boolean state + + - Tells the DVB subsystem if A/V synchronization shall be ON or OFF. + + - .. row 4 + + - + - TRUE AV-sync ON + + - .. row 5 + + - + - FALSE AV-sync OFF + + +Description +----------- + +This ioctl call asks the Audio Device to turn ON or OFF A/V +synchronization. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-bypass-mode.rst b/Documentation/media/uapi/dvb/audio-set-bypass-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..30bcaca14c3ffdc6ef0b2f1c9c92afed9c004b0f --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-bypass-mode.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_BYPASS_MODE: + +===================== +AUDIO_SET_BYPASS_MODE +===================== + +Name +---- + +AUDIO_SET_BYPASS_MODE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SET_BYPASS_MODE, boolean mode) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_BYPASS_MODE for this command. + + - .. row 3 + + - boolean mode + + - Enables or disables the decoding of the current Audio stream in + the DVB subsystem. + + - .. row 4 + + - + - TRUE Bypass is disabled + + - .. row 5 + + - + - FALSE Bypass is enabled + + +Description +----------- + +This ioctl call asks the Audio Device to bypass the Audio decoder and +forward the stream without decoding. This mode shall be used if streams +that can’t be handled by the DVB system shall be decoded. Dolby +DigitalTM streams are automatically forwarded by the DVB subsystem if +the hardware can handle it. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-ext-id.rst b/Documentation/media/uapi/dvb/audio-set-ext-id.rst new file mode 100644 index 0000000000000000000000000000000000000000..049414db8ef685e70125eab61b66e696c3a1078c --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-ext-id.rst @@ -0,0 +1,71 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_EXT_ID: + +================ +AUDIO_SET_EXT_ID +================ + +Name +---- + +AUDIO_SET_EXT_ID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = AUDIO_SET_EXT_ID, int id) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_EXT_ID for this command. + + - .. row 3 + + - int id + + - audio sub_stream_id + + +Description +----------- + +This ioctl can be used to set the extension id for MPEG streams in DVD +playback. Only the first 3 bits are recognized. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - id is not a valid id. diff --git a/Documentation/media/uapi/dvb/audio-set-id.rst b/Documentation/media/uapi/dvb/audio-set-id.rst new file mode 100644 index 0000000000000000000000000000000000000000..a664dc1955cbb5fe555ff753f1f869b60b0d0b35 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-id.rst @@ -0,0 +1,65 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_ID: + +============ +AUDIO_SET_ID +============ + +Name +---- + +AUDIO_SET_ID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SET_ID, int id) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_ID for this command. + + - .. row 3 + + - int id + + - audio sub-stream id + + +Description +----------- + +This ioctl selects which sub-stream is to be decoded if a program or +system stream is sent to the video device. If no audio stream type is +set the id has to be in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for +AC3 and in [0xA0,0xA7] for LPCM. More specifications may follow for +other stream types. If the stream type is set the id just specifies the +substream id of the audio stream and only the first 5 bits are +recognized. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-karaoke.rst b/Documentation/media/uapi/dvb/audio-set-karaoke.rst new file mode 100644 index 0000000000000000000000000000000000000000..b55f8380b9cd442e7d1f57f86219a9e44de78410 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-karaoke.rst @@ -0,0 +1,70 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_KARAOKE: + +================= +AUDIO_SET_KARAOKE +================= + +Name +---- + +AUDIO_SET_KARAOKE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = AUDIO_SET_KARAOKE, audio_karaoke_t *karaoke) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_KARAOKE for this command. + + - .. row 3 + + - audio_karaoke_t \*karaoke + + - karaoke settings according to section ??. + + +Description +----------- + +This ioctl allows one to set the mixer settings for a karaoke DVD. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - karaoke is not a valid or supported karaoke setting. diff --git a/Documentation/media/uapi/dvb/audio-set-mixer.rst b/Documentation/media/uapi/dvb/audio-set-mixer.rst new file mode 100644 index 0000000000000000000000000000000000000000..67821729c2b638f59617c7d71ce5c61b36928e1e --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-mixer.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_MIXER: + +=============== +AUDIO_SET_MIXER +=============== + +Name +---- + +AUDIO_SET_MIXER + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SET_MIXER, audio_mixer_t *mix) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_ID for this command. + + - .. row 3 + + - audio_mixer_t \*mix + + - mixer settings. + + +Description +----------- + +This ioctl lets you adjust the mixer settings of the audio decoder. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-mute.rst b/Documentation/media/uapi/dvb/audio-set-mute.rst new file mode 100644 index 0000000000000000000000000000000000000000..ebaba95ee278d9279753bde9a22faf0b88dbd8fb --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-mute.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_MUTE: + +============== +AUDIO_SET_MUTE +============== + +Name +---- + +AUDIO_SET_MUTE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_SET_MUTE, boolean state) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_MUTE for this command. + + - .. row 3 + + - boolean state + + - Indicates if audio device shall mute or not. + + - .. row 4 + + - + - TRUE Audio Mute + + - .. row 5 + + - + - FALSE Audio Un-mute + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 :ref:`VIDIOC_DECODER_CMD` with the +``V4L2_DEC_CMD_START_MUTE_AUDIO`` flag instead. + +This ioctl call asks the audio device to mute the stream that is +currently being played. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio-set-streamtype.rst b/Documentation/media/uapi/dvb/audio-set-streamtype.rst new file mode 100644 index 0000000000000000000000000000000000000000..dfb9a6c00d88ebd9a0d770b1a9d7bd77b27c2feb --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-set-streamtype.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_SET_STREAMTYPE: + +==================== +AUDIO_SET_STREAMTYPE +==================== + +Name +---- + +AUDIO_SET_STREAMTYPE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = AUDIO_SET_STREAMTYPE, int type) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_SET_STREAMTYPE for this command. + + - .. row 3 + + - int type + + - stream type + + +Description +----------- + +This ioctl tells the driver which kind of audio stream to expect. This +is useful if the stream offers several audio sub-streams like LPCM and +AC3. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - type is not a valid or supported stream type. diff --git a/Documentation/media/uapi/dvb/audio-stop.rst b/Documentation/media/uapi/dvb/audio-stop.rst new file mode 100644 index 0000000000000000000000000000000000000000..449127e3f2aa80591521379fcf9ad385649d6b5d --- /dev/null +++ b/Documentation/media/uapi/dvb/audio-stop.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _AUDIO_STOP: + +========== +AUDIO_STOP +========== + +Name +---- + +AUDIO_STOP + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = AUDIO_STOP) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals AUDIO_STOP for this command. + + +Description +----------- + +This ioctl call asks the Audio Device to stop playing the current +stream. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/audio.rst b/Documentation/media/uapi/dvb/audio.rst new file mode 100644 index 0000000000000000000000000000000000000000..155622185ea43fd58aec931ea19ed7a04a2024cb --- /dev/null +++ b/Documentation/media/uapi/dvb/audio.rst @@ -0,0 +1,26 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_audio: + +################ +DVB Audio Device +################ +The DVB audio device controls the MPEG2 audio decoder of the DVB +hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data +types and and ioctl definitions can be accessed by including +``linux/dvb/audio.h`` in your application. + +Please note that some DVB cards don’t have their own MPEG decoder, which +results in the omission of the audio and video device. + +These ioctls were also used by V4L2 to control MPEG decoders implemented +in V4L2. The use of these ioctls for that purpose has been made obsolete +and proper V4L2 ioctls or controls have been created to replace that +functionality. + + +.. toctree:: + :maxdepth: 1 + + audio_data_types + audio_function_calls diff --git a/Documentation/media/uapi/dvb/audio_data_types.rst b/Documentation/media/uapi/dvb/audio_data_types.rst new file mode 100644 index 0000000000000000000000000000000000000000..4a53127eb13ab69e0ef19758f2e4fc563f76c654 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio_data_types.rst @@ -0,0 +1,176 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_data_types: + +**************** +Audio Data Types +**************** + +This section describes the structures, data types and defines used when +talking to the audio device. + + +.. _audio-stream-source-t: + +audio_stream_source_t +===================== + +The audio stream source is set through the AUDIO_SELECT_SOURCE call +and can take the following values, depending on whether we are replaying +from an internal (demux) or external (user write) source. + + +.. code-block:: c + + typedef enum { + AUDIO_SOURCE_DEMUX, + AUDIO_SOURCE_MEMORY + } audio_stream_source_t; + +AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the +frontend or the DVR device) as the source of the video stream. If +AUDIO_SOURCE_MEMORY is selected the stream comes from the application +through the ``write()`` system call. + + +.. _audio-play-state-t: + +audio_play_state_t +================== + +The following values can be returned by the AUDIO_GET_STATUS call +representing the state of audio playback. + + +.. code-block:: c + + typedef enum { + AUDIO_STOPPED, + AUDIO_PLAYING, + AUDIO_PAUSED + } audio_play_state_t; + + +.. _audio-channel-select-t: + +audio_channel_select_t +====================== + +The audio channel selected via AUDIO_CHANNEL_SELECT is determined by +the following values. + + +.. code-block:: c + + typedef enum { + AUDIO_STEREO, + AUDIO_MONO_LEFT, + AUDIO_MONO_RIGHT, + AUDIO_MONO, + AUDIO_STEREO_SWAPPED + } audio_channel_select_t; + + +.. _audio-status: + +struct audio_status +=================== + +The AUDIO_GET_STATUS call returns the following structure informing +about various states of the playback operation. + + +.. code-block:: c + + typedef struct audio_status { + boolean AV_sync_state; + boolean mute_state; + audio_play_state_t play_state; + audio_stream_source_t stream_source; + audio_channel_select_t channel_select; + boolean bypass_mode; + audio_mixer_t mixer_state; + } audio_status_t; + + +.. _audio-mixer: + +struct audio_mixer +================== + +The following structure is used by the AUDIO_SET_MIXER call to set the +audio volume. + + +.. code-block:: c + + typedef struct audio_mixer { + unsigned int volume_left; + unsigned int volume_right; + } audio_mixer_t; + + +.. _audio_encodings: + +audio encodings +=============== + +A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the +following bits set according to the hardwares capabilities. + + +.. code-block:: c + + #define AUDIO_CAP_DTS 1 + #define AUDIO_CAP_LPCM 2 + #define AUDIO_CAP_MP1 4 + #define AUDIO_CAP_MP2 8 + #define AUDIO_CAP_MP3 16 + #define AUDIO_CAP_AAC 32 + #define AUDIO_CAP_OGG 64 + #define AUDIO_CAP_SDDS 128 + #define AUDIO_CAP_AC3 256 + + +.. _audio-karaoke: + +struct audio_karaoke +==================== + +The ioctl AUDIO_SET_KARAOKE uses the following format: + + +.. code-block:: c + + typedef + struct audio_karaoke { + int vocal1; + int vocal2; + int melody; + } audio_karaoke_t; + +If Vocal1 or Vocal2 are non-zero, they get mixed into left and right t +at 70% each. If both, Vocal1 and Vocal2 are non-zero, Vocal1 gets mixed +into the left channel and Vocal2 into the right channel at 100% each. Ff +Melody is non-zero, the melody channel gets mixed into left and right. + + +.. _audio-attributes-t: + +audio attributes +================ + +The following attributes can be set by a call to AUDIO_SET_ATTRIBUTES: + + +.. code-block:: c + + typedef uint16_t audio_attributes_t; + /* bits: descr. */ + /* 15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */ + /* 12 multichannel extension */ + /* 11-10 audio type (0=not spec, 1=language included) */ + /* 9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */ + /* 7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit, */ + /* 5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */ + /* 2- 0 number of audio channels (n+1 channels) */ diff --git a/Documentation/media/uapi/dvb/audio_function_calls.rst b/Documentation/media/uapi/dvb/audio_function_calls.rst new file mode 100644 index 0000000000000000000000000000000000000000..0bb56f0cfed4a7a5527f8879e2202446b91679c8 --- /dev/null +++ b/Documentation/media/uapi/dvb/audio_function_calls.rst @@ -0,0 +1,34 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_function_calls: + +******************** +Audio Function Calls +******************** + +.. toctree:: + :maxdepth: 1 + + audio-fopen + audio-fclose + audio-fwrite + audio-stop + audio-play + audio-pause + audio-continue + audio-select-source + audio-set-mute + audio-set-av-sync + audio-set-bypass-mode + audio-channel-select + audio-bilingual-channel-select + audio-get-pts + audio-get-status + audio-get-capabilities + audio-clear-buffer + audio-set-id + audio-set-mixer + audio-set-streamtype + audio-set-ext-id + audio-set-attributes + audio-set-karaoke diff --git a/Documentation/media/uapi/dvb/audio_h.rst b/Documentation/media/uapi/dvb/audio_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..e00c3010fdf9916896bf81f19cd5100ba402063b --- /dev/null +++ b/Documentation/media/uapi/dvb/audio_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio_h: + +********************* +DVB Audio Header File +********************* + +.. kernel-include:: $BUILDDIR/audio.h.rst diff --git a/Documentation/media/uapi/dvb/ca-fclose.rst b/Documentation/media/uapi/dvb/ca-fclose.rst new file mode 100644 index 0000000000000000000000000000000000000000..16d7a1e76193b94bc7059f427dd0edd6b8bcef7c --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-fclose.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _ca_fclose: + +============== +DVB CA close() +============== + +Name +---- + +DVB CA close() + + +Synopsis +-------- + +.. cpp:function:: int close(int fd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + +Description +----------- + +This system call closes a previously opened audio device. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/ca-fopen.rst b/Documentation/media/uapi/dvb/ca-fopen.rst new file mode 100644 index 0000000000000000000000000000000000000000..f284461cce206944f5ae52d1bf761ff2f3119e1d --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-fopen.rst @@ -0,0 +1,109 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _ca_fopen: + +============= +DVB CA open() +============= + +Name +---- + +DVB CA open() + + +Synopsis +-------- + +.. cpp:function:: int open(const char *deviceName, int flags) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - const char \*deviceName + + - Name of specific video device. + + - .. row 2 + + - int flags + + - A bit-wise OR of the following flags: + + - .. row 3 + + - + - O_RDONLY read-only access + + - .. row 4 + + - + - O_RDWR read/write access + + - .. row 5 + + - + - O_NONBLOCK open in non-blocking mode + + - .. row 6 + + - + - (blocking mode is the default) + + +Description +----------- + +This system call opens a named ca device (e.g. /dev/ost/ca) for +subsequent use. + +When an open() call has succeeded, the device will be ready for use. The +significance of blocking or non-blocking mode is described in the +documentation for functions where there is a difference. It does not +affect the semantics of the open() call itself. A device opened in +blocking mode can later be put into non-blocking mode (and vice versa) +using the F_SETFL command of the fcntl system call. This is a standard +system call, documented in the Linux manual page for fcntl. Only one +user can open the CA Device in O_RDWR mode. All other attempts to open +the device in this mode will fail, and an error code will be returned. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``ENODEV`` + + - Device driver not loaded/available. + + - .. row 2 + + - ``EINTERNAL`` + + - Internal error. + + - .. row 3 + + - ``EBUSY`` + + - Device or resource busy. + + - .. row 4 + + - ``EINVAL`` + + - Invalid argument. diff --git a/Documentation/media/uapi/dvb/ca-get-cap.rst b/Documentation/media/uapi/dvb/ca-get-cap.rst new file mode 100644 index 0000000000000000000000000000000000000000..891fbf2d9a8456b39f44542a1c4830d9b6476e2b --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-get-cap.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_GET_CAP: + +========== +CA_GET_CAP +========== + +Name +---- + +CA_GET_CAP + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_GET_CAP, ca_caps_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_GET_CAP for this command. + + - .. row 3 + + - ca_caps_t * + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-get-descr-info.rst b/Documentation/media/uapi/dvb/ca-get-descr-info.rst new file mode 100644 index 0000000000000000000000000000000000000000..cf8e8242db66d363fe47ea3f1832c0d237438cf9 --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-get-descr-info.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_GET_DESCR_INFO: + +================= +CA_GET_DESCR_INFO +================= + +Name +---- + +CA_GET_DESCR_INFO + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_GET_DESCR_INFO, ca_descr_info_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_GET_DESCR_INFO for this command. + + - .. row 3 + + - ca_descr_info_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-get-msg.rst b/Documentation/media/uapi/dvb/ca-get-msg.rst new file mode 100644 index 0000000000000000000000000000000000000000..56004d5ea3ab40f1f03d0c1aada4d1f70775691a --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-get-msg.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_GET_MSG: + +========== +CA_GET_MSG +========== + +Name +---- + +CA_GET_MSG + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_GET_MSG, ca_msg_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_GET_MSG for this command. + + - .. row 3 + + - ca_msg_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-get-slot-info.rst b/Documentation/media/uapi/dvb/ca-get-slot-info.rst new file mode 100644 index 0000000000000000000000000000000000000000..9fea28ccad0f3a521f5c07411da1c98fe095ed3e --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-get-slot-info.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_GET_SLOT_INFO: + +================ +CA_GET_SLOT_INFO +================ + +Name +---- + +CA_GET_SLOT_INFO + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_GET_SLOT_INFO, ca_slot_info_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_GET_SLOT_INFO for this command. + + - .. row 3 + + - ca_slot_info_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-reset.rst b/Documentation/media/uapi/dvb/ca-reset.rst new file mode 100644 index 0000000000000000000000000000000000000000..d5a50088fc2d7864b2f3a40e25bf1abbaedafa74 --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-reset.rst @@ -0,0 +1,53 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_RESET: + +======== +CA_RESET +======== + +Name +---- + +CA_RESET + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_RESET) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_RESET for this command. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-send-msg.rst b/Documentation/media/uapi/dvb/ca-send-msg.rst new file mode 100644 index 0000000000000000000000000000000000000000..18974e61e78853917a936416db6f30b3e59b791d --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-send-msg.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_SEND_MSG: + +=========== +CA_SEND_MSG +=========== + +Name +---- + +CA_SEND_MSG + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_SEND_MSG, ca_msg_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_SEND_MSG for this command. + + - .. row 3 + + - ca_msg_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst b/Documentation/media/uapi/dvb/ca-set-descr.rst new file mode 100644 index 0000000000000000000000000000000000000000..293e6da5059f49bec86df8698e4becfc1945d43a --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_SET_DESCR: + +============ +CA_SET_DESCR +============ + +Name +---- + +CA_SET_DESCR + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_SET_DESCR, ca_descr_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_SET_DESCR for this command. + + - .. row 3 + + - ca_descr_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca-set-pid.rst b/Documentation/media/uapi/dvb/ca-set-pid.rst new file mode 100644 index 0000000000000000000000000000000000000000..5afa2fae3206667301cc6300098619f0731d142d --- /dev/null +++ b/Documentation/media/uapi/dvb/ca-set-pid.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CA_SET_PID: + +========== +CA_SET_PID +========== + +Name +---- + +CA_SET_PID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = CA_SET_PID, ca_pid_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals CA_SET_PID for this command. + + - .. row 3 + + - ca_pid_t \* + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/ca.rst b/Documentation/media/uapi/dvb/ca.rst new file mode 100644 index 0000000000000000000000000000000000000000..14b14abda1aee663d352fe180ec562d4d8a04320 --- /dev/null +++ b/Documentation/media/uapi/dvb/ca.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_ca: + +############# +DVB CA Device +############# +The DVB CA device controls the conditional access hardware. It can be +accessed through ``/dev/dvb/adapter?/ca?``. Data types and and ioctl +definitions can be accessed by including ``linux/dvb/ca.h`` in your +application. + + +.. toctree:: + :maxdepth: 1 + + ca_data_types + ca_function_calls diff --git a/Documentation/media/uapi/dvb/ca_data_types.rst b/Documentation/media/uapi/dvb/ca_data_types.rst new file mode 100644 index 0000000000000000000000000000000000000000..025f910ae9455d7ea9ef1f1b917222017331a579 --- /dev/null +++ b/Documentation/media/uapi/dvb/ca_data_types.rst @@ -0,0 +1,110 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _ca_data_types: + +************* +CA Data Types +************* + + +.. _ca-slot-info: + +ca_slot_info_t +============== + + +.. code-block:: c + + typedef struct ca_slot_info { + int num; /* slot number */ + + int type; /* CA interface this slot supports */ + #define CA_CI 1 /* CI high level interface */ + #define CA_CI_LINK 2 /* CI link layer level interface */ + #define CA_CI_PHYS 4 /* CI physical layer level interface */ + #define CA_DESCR 8 /* built-in descrambler */ + #define CA_SC 128 /* simple smart card interface */ + + unsigned int flags; + #define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */ + #define CA_CI_MODULE_READY 2 + } ca_slot_info_t; + + +.. _ca-descr-info: + +ca_descr_info_t +=============== + + +.. code-block:: c + + typedef struct ca_descr_info { + unsigned int num; /* number of available descramblers (keys) */ + unsigned int type; /* type of supported scrambling system */ + #define CA_ECD 1 + #define CA_NDS 2 + #define CA_DSS 4 + } ca_descr_info_t; + + +.. _ca-caps: + +ca_caps_t +========= + + +.. code-block:: c + + typedef struct ca_caps { + unsigned int slot_num; /* total number of CA card and module slots */ + unsigned int slot_type; /* OR of all supported types */ + unsigned int descr_num; /* total number of descrambler slots (keys) */ + unsigned int descr_type;/* OR of all supported types */ + } ca_cap_t; + + +.. _ca-msg: + +ca_msg_t +======== + + +.. 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; + + +.. _ca-descr: + +ca_descr_t +========== + + +.. code-block:: c + + typedef struct ca_descr { + unsigned int index; + unsigned int parity; + unsigned char cw[8]; + } ca_descr_t; + + +.. _ca-pid: + +ca-pid +====== + + +.. code-block:: c + + typedef struct ca_pid { + unsigned int pid; + int index; /* -1 == disable*/ + } ca_pid_t; diff --git a/Documentation/media/uapi/dvb/ca_function_calls.rst b/Documentation/media/uapi/dvb/ca_function_calls.rst new file mode 100644 index 0000000000000000000000000000000000000000..c085a0ebbc057cf7c4eeea85c0407e2aad63af9f --- /dev/null +++ b/Documentation/media/uapi/dvb/ca_function_calls.rst @@ -0,0 +1,21 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _ca_function_calls: + +***************** +CA Function Calls +***************** + +.. toctree:: + :maxdepth: 1 + + ca-fopen + ca-fclose + ca-reset + ca-get-cap + ca-get-slot-info + ca-get-descr-info + ca-get-msg + ca-send-msg + ca-set-descr + ca-set-pid diff --git a/Documentation/media/uapi/dvb/ca_h.rst b/Documentation/media/uapi/dvb/ca_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..f513592ef52967d5121b536ae52686e8b994989c --- /dev/null +++ b/Documentation/media/uapi/dvb/ca_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _ca_h: + +********************************** +DVB Conditional Access Header File +********************************** + +.. kernel-include:: $BUILDDIR/ca.h.rst diff --git a/Documentation/media/uapi/dvb/demux.rst b/Documentation/media/uapi/dvb/demux.rst new file mode 100644 index 0000000000000000000000000000000000000000..b12b5a2dac94b21a5a8d7bc781d7c86ab05b557e --- /dev/null +++ b/Documentation/media/uapi/dvb/demux.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_demux: + +################ +DVB Demux Device +################ +The DVB demux device controls the filters of the DVB hardware/software. +It can be accessed through ``/dev/adapter?/demux?``. Data types and and +ioctl definitions can be accessed by including ``linux/dvb/dmx.h`` in +your application. + + +.. toctree:: + :maxdepth: 1 + + dmx_types + dmx_fcalls diff --git a/Documentation/media/uapi/dvb/dmx-add-pid.rst b/Documentation/media/uapi/dvb/dmx-add-pid.rst new file mode 100644 index 0000000000000000000000000000000000000000..6343035653ac21ad458efa8278ffda61690fe01e --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-add-pid.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_ADD_PID: + +=========== +DMX_ADD_PID +=========== + +Name +---- + +DMX_ADD_PID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = DMX_ADD_PID, __u16 *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_ADD_PID for this command. + + - .. row 3 + + - __u16 * + + - PID number to be filtered. + + +Description +----------- + +This ioctl call allows to add multiple PIDs to a transport stream filter +previously set up with DMX_SET_PES_FILTER and output equal to +DMX_OUT_TSDEMUX_TAP. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-fclose.rst b/Documentation/media/uapi/dvb/dmx-fclose.rst new file mode 100644 index 0000000000000000000000000000000000000000..f54c2a1220c15ca2147a778d7d52dcf591e64f20 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-fclose.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_fclose: + +================= +DVB demux close() +================= + +Name +---- + +DVB demux close() + + +Synopsis +-------- + +.. cpp:function:: int close(int fd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + +Description +----------- + +This system call deactivates and deallocates a filter that was +previously allocated via the open() call. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/dmx-fopen.rst b/Documentation/media/uapi/dvb/dmx-fopen.rst new file mode 100644 index 0000000000000000000000000000000000000000..76dbb42713ad3d0dc9774fbe9979aa2f4ec3ad46 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-fopen.rst @@ -0,0 +1,108 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_fopen: + +================ +DVB demux open() +================ + +Name +---- + +DVB demux open() + + +Synopsis +-------- + +.. cpp:function:: int open(const char *deviceName, int flags) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - const char \*deviceName + + - Name of demux device. + + - .. row 2 + + - int flags + + - A bit-wise OR of the following flags: + + - .. row 3 + + - + - O_RDWR read/write access + + - .. row 4 + + - + - O_NONBLOCK open in non-blocking mode + + - .. row 5 + + - + - (blocking mode is the default) + + +Description +----------- + +This system call, used with a device name of /dev/dvb/adapter0/demux0, +allocates a new filter and returns a handle which can be used for +subsequent control of that filter. This call has to be made for each +filter to be used, i.e. every returned file descriptor is a reference to +a single filter. /dev/dvb/adapter0/dvr0 is a logical device to be used +for retrieving Transport Streams for digital video recording. When +reading from this device a transport stream containing the packets from +all PES filters set in the corresponding demux device +(/dev/dvb/adapter0/demux0) having the output set to DMX_OUT_TS_TAP. A +recorded Transport Stream is replayed by writing to this device. + +The significance of blocking or non-blocking mode is described in the +documentation for functions where there is a difference. It does not +affect the semantics of the open() call itself. A device opened in +blocking mode can later be put into non-blocking mode (and vice versa) +using the F_SETFL command of the fcntl system call. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``ENODEV`` + + - Device driver not loaded/available. + + - .. row 2 + + - ``EINVAL`` + + - Invalid argument. + + - .. row 3 + + - ``EMFILE`` + + - “Too many open files”, i.e. no more filters available. + + - .. row 4 + + - ``ENOMEM`` + + - The driver failed to allocate enough memory. diff --git a/Documentation/media/uapi/dvb/dmx-fread.rst b/Documentation/media/uapi/dvb/dmx-fread.rst new file mode 100644 index 0000000000000000000000000000000000000000..d25b19e4f6965333cf92b0d4a7f9956b07054f42 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-fread.rst @@ -0,0 +1,108 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_fread: + +================ +DVB demux read() +================ + +Name +---- + +DVB demux read() + + +Synopsis +-------- + +.. cpp:function:: size_t read(int fd, void *buf, size_t count) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - void \*buf + + - Pointer to the buffer to be used for returned filtered data. + + - .. row 3 + + - size_t count + + - Size of buf. + + +Description +----------- + +This system call returns filtered data, which might be section or PES +data. The filtered data is transferred from the driver’s internal +circular buffer to buf. The maximum amount of data to be transferred is +implied by count. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EWOULDBLOCK`` + + - No data to return and O_NONBLOCK was specified. + + - .. row 2 + + - ``EBADF`` + + - fd is not a valid open file descriptor. + + - .. row 3 + + - ``ECRC`` + + - Last section had a CRC error - no data returned. The buffer is + flushed. + + - .. row 4 + + - ``EOVERFLOW`` + + - + + - .. row 5 + + - + - The filtered data was not read from the buffer in due time, + resulting in non-read data being lost. The buffer is flushed. + + - .. row 6 + + - ``ETIMEDOUT`` + + - The section was not loaded within the stated timeout period. See + ioctl DMX_SET_FILTER for how to set a timeout. + + - .. row 7 + + - ``EFAULT`` + + - The driver failed to write to the callers buffer due to an invalid + \*buf pointer. diff --git a/Documentation/media/uapi/dvb/dmx-fwrite.rst b/Documentation/media/uapi/dvb/dmx-fwrite.rst new file mode 100644 index 0000000000000000000000000000000000000000..9efd81a1b5c84793a356b006b124835d69306c60 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-fwrite.rst @@ -0,0 +1,89 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_fwrite: + +================= +DVB demux write() +================= + +Name +---- + +DVB demux write() + + +Synopsis +-------- + +.. cpp:function:: ssize_t write(int fd, const void *buf, size_t count) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - void \*buf + + - Pointer to the buffer containing the Transport Stream. + + - .. row 3 + + - size_t count + + - Size of buf. + + +Description +----------- + +This system call is only provided by the logical device +/dev/dvb/adapter0/dvr0, associated with the physical demux device that +provides the actual DVR functionality. It is used for replay of a +digitally recorded Transport Stream. Matching filters have to be defined +in the corresponding physical demux device, /dev/dvb/adapter0/demux0. +The amount of data to be transferred is implied by count. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EWOULDBLOCK`` + + - No data was written. This might happen if O_NONBLOCK was + specified and there is no more buffer space available (if + O_NONBLOCK is not specified the function will block until buffer + space is available). + + - .. row 2 + + - ``EBUSY`` + + - This error code indicates that there are conflicting requests. The + corresponding demux device is setup to receive data from the + front- end. Make sure that these filters are stopped and that the + filters with input set to DMX_IN_DVR are started. + + - .. row 3 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/dmx-get-caps.rst b/Documentation/media/uapi/dvb/dmx-get-caps.rst new file mode 100644 index 0000000000000000000000000000000000000000..d0549eb7fbd36bec69ca1d0057a2b094a3ad7a55 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-get-caps.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_GET_CAPS: + +============ +DMX_GET_CAPS +============ + +Name +---- + +DMX_GET_CAPS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = DMX_GET_CAPS, dmx_caps_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_GET_CAPS for this command. + + - .. row 3 + + - dmx_caps_t * + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-get-event.rst b/Documentation/media/uapi/dvb/dmx-get-event.rst new file mode 100644 index 0000000000000000000000000000000000000000..6a7550c63bb5d9146fba4587e2d84939e084f8a6 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-get-event.rst @@ -0,0 +1,76 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_GET_EVENT: + +============= +DMX_GET_EVENT +============= + +Name +---- + +DMX_GET_EVENT + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_GET_EVENT, struct dmx_event *ev) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_GET_EVENT for this command. + + - .. row 3 + + - struct dmx_event \*ev + + - Pointer to the location where the event is to be stored. + + +Description +----------- + +This ioctl call returns an event if available. If an event is not +available, the behavior depends on whether the device is in blocking or +non-blocking mode. In the latter case, the call fails immediately with +errno set to ``EWOULDBLOCK``. In the former case, the call blocks until an +event becomes available. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EWOULDBLOCK`` + + - There is no event pending, and the device is in non-blocking mode. diff --git a/Documentation/media/uapi/dvb/dmx-get-pes-pids.rst b/Documentation/media/uapi/dvb/dmx-get-pes-pids.rst new file mode 100644 index 0000000000000000000000000000000000000000..ba5d30c913c8a7b4a978dd4fb5c4ad57e16df851 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-get-pes-pids.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_GET_PES_PIDS: + +================ +DMX_GET_PES_PIDS +================ + +Name +---- + +DMX_GET_PES_PIDS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = DMX_GET_PES_PIDS, __u16[5]) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_GET_PES_PIDS for this command. + + - .. row 3 + + - __u16[5] + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-get-stc.rst b/Documentation/media/uapi/dvb/dmx-get-stc.rst new file mode 100644 index 0000000000000000000000000000000000000000..bd477bb6708224d78d950f46ffd6ecc085efb948 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-get-stc.rst @@ -0,0 +1,77 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_GET_STC: + +=========== +DMX_GET_STC +=========== + +Name +---- + +DMX_GET_STC + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_GET_STC, struct dmx_stc *stc) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_GET_STC for this command. + + - .. row 3 + + - struct dmx_stc \*stc + + - Pointer to the location where the stc is to be stored. + + +Description +----------- + +This ioctl call returns the current value of the system time counter +(which is driven by a PES filter of type DMX_PES_PCR). Some hardware +supports more than one STC, so you must specify which one by setting the +num field of stc before the ioctl (range 0...n). The result is returned +in form of a ratio with a 64 bit numerator and a 32 bit denominator, so +the real 90kHz STC value is stc->stc / stc->base . + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - Invalid stc number. diff --git a/Documentation/media/uapi/dvb/dmx-remove-pid.rst b/Documentation/media/uapi/dvb/dmx-remove-pid.rst new file mode 100644 index 0000000000000000000000000000000000000000..c8f038b400742e981da1c2b0cf5c89008ce96887 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-remove-pid.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_REMOVE_PID: + +============== +DMX_REMOVE_PID +============== + +Name +---- + +DMX_REMOVE_PID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = DMX_REMOVE_PID, __u16 *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_REMOVE_PID for this command. + + - .. row 3 + + - __u16 * + + - PID of the PES filter to be removed. + + +Description +----------- + +This ioctl call allows to remove a PID when multiple PIDs are set on a +transport stream filter, e. g. a filter previously set up with output +equal to DMX_OUT_TSDEMUX_TAP, created via either +DMX_SET_PES_FILTER or DMX_ADD_PID. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-set-buffer-size.rst b/Documentation/media/uapi/dvb/dmx-set-buffer-size.rst new file mode 100644 index 0000000000000000000000000000000000000000..8ae48cf39cda11183b02cd79eca45ce31ec39f72 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-set-buffer-size.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_SET_BUFFER_SIZE: + +=================== +DMX_SET_BUFFER_SIZE +=================== + +Name +---- + +DMX_SET_BUFFER_SIZE + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_SET_BUFFER_SIZE, unsigned long size) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_SET_BUFFER_SIZE for this command. + + - .. row 3 + + - unsigned long size + + - Size of circular buffer. + + +Description +----------- + +This ioctl call is used to set the size of the circular buffer used for +filtered data. The default size is two maximum sized sections, i.e. if +this function is not called a buffer size of 2 \* 4096 bytes will be +used. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-set-filter.rst b/Documentation/media/uapi/dvb/dmx-set-filter.rst new file mode 100644 index 0000000000000000000000000000000000000000..8c929fa9b98c17b38645f00c949f30ae9306f370 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-set-filter.rst @@ -0,0 +1,68 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_SET_FILTER: + +============== +DMX_SET_FILTER +============== + +Name +---- + +DMX_SET_FILTER + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_SET_FILTER, struct dmx_sct_filter_params *params) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_SET_FILTER for this command. + + - .. row 3 + + - struct dmx_sct_filter_params \*params + + - Pointer to structure containing filter parameters. + + +Description +----------- + +This ioctl call sets up a filter according to the filter and mask +parameters provided. A timeout may be defined stating number of seconds +to wait for a section to be loaded. A value of 0 means that no timeout +should be applied. Finally there is a flag field where it is possible to +state whether a section should be CRC-checked, whether the filter should +be a ”one-shot” filter, i.e. if the filtering operation should be +stopped after the first section is received, and whether the filtering +operation should be started immediately (without waiting for a +DMX_START ioctl call). If a filter was previously set-up, this filter +will be canceled, and the receive buffer will be flushed. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-set-pes-filter.rst b/Documentation/media/uapi/dvb/dmx-set-pes-filter.rst new file mode 100644 index 0000000000000000000000000000000000000000..addc321011ce9ffacdbc10dafad218a7cda3f1e2 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-set-pes-filter.rst @@ -0,0 +1,78 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_SET_PES_FILTER: + +================== +DMX_SET_PES_FILTER +================== + +Name +---- + +DMX_SET_PES_FILTER + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_SET_PES_FILTER, struct dmx_pes_filter_params *params) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_SET_PES_FILTER for this command. + + - .. row 3 + + - struct dmx_pes_filter_params \*params + + - Pointer to structure containing filter parameters. + + +Description +----------- + +This ioctl call sets up a PES filter according to the parameters +provided. By a PES filter is meant a filter that is based just on the +packet identifier (PID), i.e. no PES header or payload filtering +capability is supported. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EBUSY`` + + - This error code indicates that there are conflicting requests. + There are active filters filtering data from another input source. + Make sure that these filters are stopped before starting this + filter. diff --git a/Documentation/media/uapi/dvb/dmx-set-source.rst b/Documentation/media/uapi/dvb/dmx-set-source.rst new file mode 100644 index 0000000000000000000000000000000000000000..99a8d5c82756aa488b14f95c55ee9b9fc783f093 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-set-source.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_SET_SOURCE: + +============== +DMX_SET_SOURCE +============== + +Name +---- + +DMX_SET_SOURCE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = DMX_SET_SOURCE, dmx_source_t *) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_SET_SOURCE for this command. + + - .. row 3 + + - dmx_source_t * + + - Undocumented. + + +Description +----------- + +This ioctl is undocumented. Documentation is welcome. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx-start.rst b/Documentation/media/uapi/dvb/dmx-start.rst new file mode 100644 index 0000000000000000000000000000000000000000..9835d1e784007640579a355fce2a750d1e63309b --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-start.rst @@ -0,0 +1,77 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_START: + +========= +DMX_START +========= + +Name +---- + +DMX_START + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_START) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_START for this command. + + +Description +----------- + +This ioctl call is used to start the actual filtering operation defined +via the ioctl calls DMX_SET_FILTER or DMX_SET_PES_FILTER. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - Invalid argument, i.e. no filtering parameters provided via the + DMX_SET_FILTER or DMX_SET_PES_FILTER functions. + + - .. row 2 + + - ``EBUSY`` + + - This error code indicates that there are conflicting requests. + There are active filters filtering data from another input source. + Make sure that these filters are stopped before starting this + filter. diff --git a/Documentation/media/uapi/dvb/dmx-stop.rst b/Documentation/media/uapi/dvb/dmx-stop.rst new file mode 100644 index 0000000000000000000000000000000000000000..7e4bf09fc83e18ced763d7a31681c9cab2a0e237 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-stop.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _DMX_STOP: + +======== +DMX_STOP +======== + +Name +---- + +DMX_STOP + + +Synopsis +-------- + +.. cpp:function:: int ioctl( int fd, int request = DMX_STOP) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals DMX_STOP for this command. + + +Description +----------- + +This ioctl call is used to stop the actual filtering operation defined +via the ioctl calls DMX_SET_FILTER or DMX_SET_PES_FILTER and +started via the DMX_START command. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst b/Documentation/media/uapi/dvb/dmx_fcalls.rst new file mode 100644 index 0000000000000000000000000000000000000000..77a1554d9834ae0e216315347a8b70721943edc2 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst @@ -0,0 +1,27 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_fcalls: + +******************** +Demux Function Calls +******************** + +.. toctree:: + :maxdepth: 1 + + dmx-fopen + dmx-fclose + dmx-fread + dmx-fwrite + dmx-start + dmx-stop + dmx-set-filter + dmx-set-pes-filter + dmx-set-buffer-size + dmx-get-event + dmx-get-stc + dmx-get-pes-pids + dmx-get-caps + dmx-set-source + dmx-add-pid + dmx-remove-pid diff --git a/Documentation/media/uapi/dvb/dmx_h.rst b/Documentation/media/uapi/dvb/dmx_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..4fd1704a0833cb2f1538b70ea5fa3c840a3d824b --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_h: + +********************* +DVB Demux Header File +********************* + +.. kernel-include:: $BUILDDIR/dmx.h.rst diff --git a/Documentation/media/uapi/dvb/dmx_types.rst b/Documentation/media/uapi/dvb/dmx_types.rst new file mode 100644 index 0000000000000000000000000000000000000000..7a8900af2680d6283f1768d28c6042ecc7bec7d9 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx_types.rst @@ -0,0 +1,242 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dmx_types: + +**************** +Demux Data Types +**************** + + +.. _dmx-output-t: + +Output for the demux +==================== + + +.. _dmx-output: + +.. flat-table:: enum dmx_output + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _DMX-OUT-DECODER: + + DMX_OUT_DECODER + + - Streaming directly to decoder. + + - .. row 3 + + - .. _DMX-OUT-TAP: + + DMX_OUT_TAP + + - Output going to a memory buffer (to be retrieved via the read + command). Delivers the stream output to the demux device on which + the ioctl is called. + + - .. row 4 + + - .. _DMX-OUT-TS-TAP: + + DMX_OUT_TS_TAP + + - Output multiplexed into a new TS (to be retrieved by reading from + the logical DVR device). Routes output to the logical DVR device + ``/dev/dvb/adapter?/dvr?``, which delivers a TS multiplexed from + all filters for which ``DMX_OUT_TS_TAP`` was specified. + + - .. row 5 + + - .. _DMX-OUT-TSDEMUX-TAP: + + DMX_OUT_TSDEMUX_TAP + + - Like :ref:`DMX_OUT_TS_TAP ` but retrieved + from the DMX device. + + + +.. _dmx-input-t: + +dmx_input_t +=========== + + +.. code-block:: c + + typedef enum + { + DMX_IN_FRONTEND, /* Input from a front-end device. */ + DMX_IN_DVR /* Input from the logical DVR device. */ + } dmx_input_t; + + +.. _dmx-pes-type-t: + +dmx_pes_type_t +============== + + +.. code-block:: c + + typedef enum + { + DMX_PES_AUDIO0, + DMX_PES_VIDEO0, + DMX_PES_TELETEXT0, + DMX_PES_SUBTITLE0, + DMX_PES_PCR0, + + DMX_PES_AUDIO1, + DMX_PES_VIDEO1, + DMX_PES_TELETEXT1, + DMX_PES_SUBTITLE1, + DMX_PES_PCR1, + + DMX_PES_AUDIO2, + DMX_PES_VIDEO2, + DMX_PES_TELETEXT2, + DMX_PES_SUBTITLE2, + DMX_PES_PCR2, + + DMX_PES_AUDIO3, + DMX_PES_VIDEO3, + DMX_PES_TELETEXT3, + DMX_PES_SUBTITLE3, + DMX_PES_PCR3, + + DMX_PES_OTHER + } dmx_pes_type_t; + + +.. _dmx-filter: + +struct dmx_filter +================= + + +.. code-block:: c + + typedef struct dmx_filter + { + __u8 filter[DMX_FILTER_SIZE]; + __u8 mask[DMX_FILTER_SIZE]; + __u8 mode[DMX_FILTER_SIZE]; + } dmx_filter_t; + + +.. _dmx-sct-filter-params: + +struct dmx_sct_filter_params +============================ + + +.. code-block:: c + + struct dmx_sct_filter_params + { + __u16 pid; + dmx_filter_t filter; + __u32 timeout; + __u32 flags; + #define DMX_CHECK_CRC 1 + #define DMX_ONESHOT 2 + #define DMX_IMMEDIATE_START 4 + #define DMX_KERNEL_CLIENT 0x8000 + }; + + +.. _dmx-pes-filter-params: + +struct dmx_pes_filter_params +============================ + + +.. code-block:: c + + struct dmx_pes_filter_params + { + __u16 pid; + dmx_input_t input; + dmx_output_t output; + dmx_pes_type_t pes_type; + __u32 flags; + }; + + +.. _dmx-event: + +struct dmx_event +================ + + +.. code-block:: c + + struct dmx_event + { + dmx_event_t event; + time_t timeStamp; + union + { + dmx_scrambling_status_t scrambling; + } u; + }; + + +.. _dmx-stc: + +struct dmx_stc +============== + + +.. code-block:: c + + struct dmx_stc { + unsigned int num; /* input : which STC? 0..N */ + unsigned int base; /* output: divisor for stc to get 90 kHz clock */ + __u64 stc; /* output: stc in 'base'*90 kHz units */ + }; + + +.. _dmx-caps: + +struct dmx_caps +=============== + + +.. code-block:: c + + typedef struct dmx_caps { + __u32 caps; + int num_decoders; + } dmx_caps_t; + + +.. _dmx-source-t: + +enum dmx_source_t +================= + + +.. code-block:: c + + typedef enum { + DMX_SOURCE_FRONT0 = 0, + DMX_SOURCE_FRONT1, + DMX_SOURCE_FRONT2, + DMX_SOURCE_FRONT3, + DMX_SOURCE_DVR0 = 16, + DMX_SOURCE_DVR1, + DMX_SOURCE_DVR2, + DMX_SOURCE_DVR3 + } dmx_source_t; diff --git a/Documentation/media/uapi/dvb/dtv-fe-stats.rst b/Documentation/media/uapi/dvb/dtv-fe-stats.rst new file mode 100644 index 0000000000000000000000000000000000000000..7c105e2ab27e8643101577ab7793acac22696ec9 --- /dev/null +++ b/Documentation/media/uapi/dvb/dtv-fe-stats.rst @@ -0,0 +1,17 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dtv-fe-stats: + +******************* +struct dtv_fe_stats +******************* + + +.. code-block:: c + + #define MAX_DTV_STATS 4 + + struct dtv_fe_stats { + __u8 len; + struct dtv_stats stat[MAX_DTV_STATS]; + } __packed; diff --git a/Documentation/media/uapi/dvb/dtv-properties.rst b/Documentation/media/uapi/dvb/dtv-properties.rst new file mode 100644 index 0000000000000000000000000000000000000000..c13be5de43026837cfb33124bfd227b8a356af24 --- /dev/null +++ b/Documentation/media/uapi/dvb/dtv-properties.rst @@ -0,0 +1,15 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dtv-properties: + +********************* +struct dtv_properties +********************* + + +.. code-block:: c + + struct dtv_properties { + __u32 num; + struct dtv_property *props; + }; diff --git a/Documentation/media/uapi/dvb/dtv-property.rst b/Documentation/media/uapi/dvb/dtv-property.rst new file mode 100644 index 0000000000000000000000000000000000000000..5073a49def2a1ff3395cf5856a308c9dd0df3602 --- /dev/null +++ b/Documentation/media/uapi/dvb/dtv-property.rst @@ -0,0 +1,31 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dtv-property: + +******************* +struct dtv_property +******************* + + +.. code-block:: c + + /* Reserved fields should be set to 0 */ + + struct dtv_property { + __u32 cmd; + __u32 reserved[3]; + union { + __u32 data; + struct dtv_fe_stats st; + struct { + __u8 data[32]; + __u32 len; + __u32 reserved1[3]; + void *reserved2; + } buffer; + } u; + int result; + } __attribute__ ((packed)); + + /* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */ + #define DTV_IOCTL_MAX_MSGS 64 diff --git a/Documentation/media/uapi/dvb/dtv-stats.rst b/Documentation/media/uapi/dvb/dtv-stats.rst new file mode 100644 index 0000000000000000000000000000000000000000..2cfdca00f16452583e338d342bfc43755c8117e4 --- /dev/null +++ b/Documentation/media/uapi/dvb/dtv-stats.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dtv-stats: + +**************** +struct dtv_stats +**************** + + +.. code-block:: c + + struct dtv_stats { + __u8 scale; /* enum fecap_scale_params type */ + union { + __u64 uvalue; /* for counters and relative scales */ + __s64 svalue; /* for 1/1000 dB measures */ + }; + } __packed; diff --git a/Documentation/media/uapi/dvb/dvb-fe-read-status.rst b/Documentation/media/uapi/dvb/dvb-fe-read-status.rst new file mode 100644 index 0000000000000000000000000000000000000000..fcffaa7e1463695e0703dcc64c0ca1261a1522ac --- /dev/null +++ b/Documentation/media/uapi/dvb/dvb-fe-read-status.rst @@ -0,0 +1,23 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb-fe-read-status: + +*************************************** +Querying frontend status and statistics +*************************************** + +Once :ref:`FE_SET_PROPERTY ` is called, the +frontend will run a kernel thread that will periodically check for the +tuner lock status and provide statistics about the quality of the +signal. + +The information about the frontend tuner locking status can be queried +using :ref:`FE_READ_STATUS`. + +Signal statistics are provided via +:ref:`FE_GET_PROPERTY`. + +.. note:: Most statistics require the demodulator to be fully locked + (e. g. with FE_HAS_LOCK bit set). See + :ref:`Frontend statistics indicators ` for + more details. diff --git a/Documentation/media/uapi/dvb/dvb-frontend-event.rst b/Documentation/media/uapi/dvb/dvb-frontend-event.rst new file mode 100644 index 0000000000000000000000000000000000000000..78e72feaa17858852185edc4571f61d045bf573b --- /dev/null +++ b/Documentation/media/uapi/dvb/dvb-frontend-event.rst @@ -0,0 +1,15 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb-frontend-event: + +*************** +frontend events +*************** + + +.. code-block:: c + + struct dvb_frontend_event { + fe_status_t status; + struct dvb_frontend_parameters parameters; + }; diff --git a/Documentation/media/uapi/dvb/dvb-frontend-parameters.rst b/Documentation/media/uapi/dvb/dvb-frontend-parameters.rst new file mode 100644 index 0000000000000000000000000000000000000000..16cb581d5cffa07c65c848c32fe0e2768293324e --- /dev/null +++ b/Documentation/media/uapi/dvb/dvb-frontend-parameters.rst @@ -0,0 +1,119 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb-frontend-parameters: + +******************* +frontend parameters +******************* + +The kind of parameters passed to the frontend device for tuning depend +on the kind of hardware you are using. + +The struct ``dvb_frontend_parameters`` uses an union with specific +per-system parameters. However, as newer delivery systems required more +data, the structure size weren't enough to fit, and just extending its +size would break the existing applications. So, those parameters were +replaced by the usage of +:ref:`FE_GET_PROPERTY/FE_SET_PROPERTY ` +ioctl's. The new API is flexible enough to add new parameters to +existing delivery systems, and to add newer delivery systems. + +So, newer applications should use +:ref:`FE_GET_PROPERTY/FE_SET_PROPERTY ` +instead, in order to be able to support the newer System Delivery like +DVB-S2, DVB-T2, DVB-C2, ISDB, etc. + +All kinds of parameters are combined as an union in the +FrontendParameters structure: + + +.. code-block:: c + + struct dvb_frontend_parameters { + uint32_t frequency; /* (absolute) frequency in Hz for QAM/OFDM */ + /* intermediate frequency in kHz for QPSK */ + fe_spectral_inversion_t inversion; + union { + struct dvb_qpsk_parameters qpsk; + struct dvb_qam_parameters qam; + struct dvb_ofdm_parameters ofdm; + struct dvb_vsb_parameters vsb; + } u; + }; + +In the case of QPSK frontends the ``frequency`` field specifies the +intermediate frequency, i.e. the offset which is effectively added to +the local oscillator frequency (LOF) of the LNB. The intermediate +frequency has to be specified in units of kHz. For QAM and OFDM +frontends the ``frequency`` specifies the absolute frequency and is +given in Hz. + + +.. _dvb-qpsk-parameters: + +QPSK parameters +=============== + +For satellite QPSK frontends you have to use the ``dvb_qpsk_parameters`` +structure: + + +.. code-block:: c + + struct dvb_qpsk_parameters { + uint32_t symbol_rate; /* symbol rate in Symbols per second */ + fe_code_rate_t fec_inner; /* forward error correction (see above) */ + }; + + +.. _dvb-qam-parameters: + +QAM parameters +============== + +for cable QAM frontend you use the ``dvb_qam_parameters`` structure: + + +.. code-block:: c + + struct dvb_qam_parameters { + uint32_t symbol_rate; /* symbol rate in Symbols per second */ + fe_code_rate_t fec_inner; /* forward error correction (see above) */ + fe_modulation_t modulation; /* modulation type (see above) */ + }; + + +.. _dvb-vsb-parameters: + +VSB parameters +============== + +ATSC frontends are supported by the ``dvb_vsb_parameters`` structure: + + +.. code-block:: c + + struct dvb_vsb_parameters { + fe_modulation_t modulation; /* modulation type (see above) */ + }; + + +.. _dvb-ofdm-parameters: + +OFDM parameters +=============== + +DVB-T frontends are supported by the ``dvb_ofdm_parameters`` structure: + + +.. code-block:: c + + struct dvb_ofdm_parameters { + fe_bandwidth_t bandwidth; + fe_code_rate_t code_rate_HP; /* high priority stream code rate */ + fe_code_rate_t code_rate_LP; /* low priority stream code rate */ + fe_modulation_t constellation; /* modulation type (see above) */ + fe_transmit_mode_t transmission_mode; + fe_guard_interval_t guard_interval; + fe_hierarchy_t hierarchy_information; + }; diff --git a/Documentation/media/uapi/dvb/dvbapi.rst b/Documentation/media/uapi/dvb/dvbapi.rst new file mode 100644 index 0000000000000000000000000000000000000000..48e61aba741e32a1cc4d4a501a5597143c1da264 --- /dev/null +++ b/Documentation/media/uapi/dvb/dvbapi.rst @@ -0,0 +1,102 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +.. _dvbapi: + +######################## +Part II - Digital TV API +######################## + +.. note:: This API is also known as **DVB API**, although it is generic + enough to support all digital TV standards. + +**Version 5.10** + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 5 + :numbered: + + intro + frontend + demux + ca + net + legacy_dvb_apis + examples + audio_h + ca_h + dmx_h + frontend_h + net_h + video_h + + +********************** +Revision and Copyright +********************** + +Authors: + +- J. K. Metzler, Ralph + + - Original author of the DVB API documentation. + +- O. C. Metzler, Marcus + + - Original author of the DVB API documentation. + +- Carvalho Chehab, Mauro + + - Ported document to Docbook XML, addition of DVBv5 API, documentation gaps fix. + +**Copyright** |copy| 2002-2003 : Convergence GmbH + +**Copyright** |copy| 2009-2016 : Mauro Carvalho Chehab + +**************** +Revision History +**************** + +:revision: 2.1.0 / 2015-05-29 (*mcc*) + +DocBook improvements and cleanups, in order to document the system calls +on a more standard way and provide more description about the current +DVB API. + +:revision: 2.0.4 / 2011-05-06 (*mcc*) + +Add more information about DVB APIv5, better describing the frontend +GET/SET props ioctl's. + + +:revision: 2.0.3 / 2010-07-03 (*mcc*) + +Add some frontend capabilities flags, present on kernel, but missing at +the specs. + + +:revision: 2.0.2 / 2009-10-25 (*mcc*) + +documents FE_SET_FRONTEND_TUNE_MODE and +FE_DISHETWORK_SEND_LEGACY_CMD ioctls. + + +:revision: 2.0.1 / 2009-09-16 (*mcc*) + +Added ISDB-T test originally written by Patrick Boettcher + + +:revision: 2.0.0 / 2009-09-06 (*mcc*) + +Conversion from LaTex to DocBook XML. The contents is the same as the +original LaTex version. + + +:revision: 1.0.0 / 2003-07-24 (*rjkm*) + +Initial revision on LaTEX. diff --git a/Documentation/media/uapi/dvb/dvbproperty-006.rst b/Documentation/media/uapi/dvb/dvbproperty-006.rst new file mode 100644 index 0000000000000000000000000000000000000000..3343a0f306fe2df57584e8fe865325e6c2a6872c --- /dev/null +++ b/Documentation/media/uapi/dvb/dvbproperty-006.rst @@ -0,0 +1,12 @@ +.. -*- coding: utf-8; mode: rst -*- + +************** +Property types +************** + +On :ref:`FE_GET_PROPERTY and FE_SET_PROPERTY `, +the actual action is determined by the dtv_property cmd/data pairs. +With one single ioctl, is possible to get/set up to 64 properties. The +actual meaning of each property is described on the next sections. + +The available frontend property types are shown on the next section. diff --git a/Documentation/media/uapi/dvb/dvbproperty.rst b/Documentation/media/uapi/dvb/dvbproperty.rst new file mode 100644 index 0000000000000000000000000000000000000000..cd0511b06c2c4842d762700afefeea2905469689 --- /dev/null +++ b/Documentation/media/uapi/dvb/dvbproperty.rst @@ -0,0 +1,116 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend-properties: + +DVB Frontend properties +======================= + +Tuning into a Digital TV physical channel and starting decoding it +requires changing a set of parameters, in order to control the tuner, +the demodulator, the Linear Low-noise Amplifier (LNA) and to set the +antenna subsystem via Satellite Equipment Control (SEC), on satellite +systems. The actual parameters are specific to each particular digital +TV standards, and may change as the digital TV specs evolves. + +In the past, the strategy used was to have a union with the parameters +needed to tune for DVB-S, DVB-C, DVB-T and ATSC delivery systems grouped +there. The problem is that, as the second generation standards appeared, +those structs were not big enough to contain the additional parameters. +Also, the union didn't have any space left to be expanded without +breaking userspace. So, the decision was to deprecate the legacy +union/struct based approach, in favor of a properties set approach. + +.. note:: On Linux DVB API version 3, setting a frontend were done via + :ref:`struct dvb_frontend_parameters `. + This got replaced on version 5 (also called "S2API", as this API were + added originally_enabled to provide support for DVB-S2), because the + old API has a very limited support to new standards and new hardware. + This section describes the new and recommended way to set the frontend, + with suppports all digital TV delivery systems. + +Example: with the properties based approach, in order to set the tuner +to a DVB-C channel at 651 kHz, modulated with 256-QAM, FEC 3/4 and +symbol rate of 5.217 Mbauds, those properties should be sent to +:ref:`FE_SET_PROPERTY ` ioctl: + +- :ref:`DTV_DELIVERY_SYSTEM ` = + SYS_DVBC_ANNEX_A + +- :ref:`DTV_FREQUENCY ` = 651000000 + +- :ref:`DTV_MODULATION ` = QAM_256 + +- :ref:`DTV_INVERSION ` = INVERSION_AUTO + +- :ref:`DTV_SYMBOL_RATE ` = 5217000 + +- :ref:`DTV_INNER_FEC ` = FEC_3_4 + +- :ref:`DTV_TUNE ` + +The code that would that would do the above is show in +:ref:`dtv-prop-example`. + +.. _dtv-prop-example: + +Example: Setting digital TV frontend properties +=============================================== + +.. code-block:: c + + #include + #include + #include + #include + + static struct dtv_property props[] = { + { .cmd = DTV_DELIVERY_SYSTEM, .u.data = SYS_DVBC_ANNEX_A }, + { .cmd = DTV_FREQUENCY, .u.data = 651000000 }, + { .cmd = DTV_MODULATION, .u.data = QAM_256 }, + { .cmd = DTV_INVERSION, .u.data = INVERSION_AUTO }, + { .cmd = DTV_SYMBOL_RATE, .u.data = 5217000 }, + { .cmd = DTV_INNER_FEC, .u.data = FEC_3_4 }, + { .cmd = DTV_TUNE } + }; + + static struct dtv_properties dtv_prop = { + .num = 6, .props = props + }; + + int main(void) + { + int fd = open("/dev/dvb/adapter0/frontend0", O_RDWR); + + if (!fd) { + perror ("open"); + return -1; + } + if (ioctl(fd, FE_SET_PROPERTY, &dtv_prop) == -1) { + perror("ioctl"); + return -1; + } + printf("Frontend set\\n"); + return 0; + } + +.. attention:: While it is possible to directly call the Kernel code like the + above example, it is strongly recommended to use + `libdvbv5 `__, as it + provides abstraction to work with the supported digital TV standards and + provides methods for usual operations like program scanning and to + read/write channel descriptor files. + + +.. toctree:: + :maxdepth: 1 + + dtv-stats + dtv-fe-stats + dtv-property + dtv-properties + dvbproperty-006 + fe_property_parameters + frontend-stat-properties + frontend-property-terrestrial-systems + frontend-property-cable-systems + frontend-property-satellite-systems diff --git a/Documentation/media/uapi/dvb/examples.rst b/Documentation/media/uapi/dvb/examples.rst new file mode 100644 index 0000000000000000000000000000000000000000..bf0a8617de9244a4794f4e37c2d217c14ebb8a38 --- /dev/null +++ b/Documentation/media/uapi/dvb/examples.rst @@ -0,0 +1,380 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_examples: + +******** +Examples +******** + +In this section we would like to present some examples for using the DVB +API. + +..note:: This section is out of date, and the code below won't even + compile. Please refer to the + `libdvbv5 `__ for + updated/recommended examples. + + +.. _tuning: + +Example: Tuning +=============== + +We will start with a generic tuning subroutine that uses the frontend +and SEC, as well as the demux devices. The example is given for QPSK +tuners, but can easily be adjusted for QAM. + + +.. code-block:: c + + #include + #include + #include + #include + #include + #include + #include + #include + + #include + #include + #include + #include + + #define DMX "/dev/dvb/adapter0/demux1" + #define FRONT "/dev/dvb/adapter0/frontend1" + #define SEC "/dev/dvb/adapter0/sec1" + + /* routine for checking if we have a signal and other status information*/ + int FEReadStatus(int fd, fe_status_t *stat) + { + int ans; + + if ( (ans = ioctl(fd,FE_READ_STATUS,stat) < 0)){ + perror("FE READ STATUS: "); + return -1; + } + + if (*stat & FE_HAS_POWER) + printf("FE HAS POWER\\n"); + + if (*stat & FE_HAS_SIGNAL) + printf("FE HAS SIGNAL\\n"); + + if (*stat & FE_SPECTRUM_INV) + printf("SPEKTRUM INV\\n"); + + return 0; + } + + + /* tune qpsk */ + /* freq: frequency of transponder */ + /* vpid, apid, tpid: PIDs of video, audio and teletext TS packets */ + /* diseqc: DiSEqC address of the used LNB */ + /* pol: Polarisation */ + /* srate: Symbol Rate */ + /* fec. FEC */ + /* lnb_lof1: local frequency of lower LNB band */ + /* lnb_lof2: local frequency of upper LNB band */ + /* lnb_slof: switch frequency of LNB */ + + int set_qpsk_channel(int freq, int vpid, int apid, int tpid, + int diseqc, int pol, int srate, int fec, int lnb_lof1, + int lnb_lof2, int lnb_slof) + { + struct secCommand scmd; + struct secCmdSequence scmds; + struct dmx_pes_filter_params pesFilterParams; + FrontendParameters frp; + struct pollfd pfd[1]; + FrontendEvent event; + int demux1, demux2, demux3, front; + + frequency = (uint32_t) freq; + symbolrate = (uint32_t) srate; + + if((front = open(FRONT,O_RDWR)) < 0){ + perror("FRONTEND DEVICE: "); + return -1; + } + + if((sec = open(SEC,O_RDWR)) < 0){ + perror("SEC DEVICE: "); + return -1; + } + + if (demux1 < 0){ + if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux2 < 0){ + if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux3 < 0){ + if ((demux3=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (freq < lnb_slof) { + frp.Frequency = (freq - lnb_lof1); + scmds.continuousTone = SEC_TONE_OFF; + } else { + frp.Frequency = (freq - lnb_lof2); + scmds.continuousTone = SEC_TONE_ON; + } + frp.Inversion = INVERSION_AUTO; + if (pol) scmds.voltage = SEC_VOLTAGE_18; + else scmds.voltage = SEC_VOLTAGE_13; + + scmd.type=0; + scmd.u.diseqc.addr=0x10; + scmd.u.diseqc.cmd=0x38; + scmd.u.diseqc.numParams=1; + scmd.u.diseqc.params[0] = 0xF0 | ((diseqc * 4) & 0x0F) | + (scmds.continuousTone == SEC_TONE_ON ? 1 : 0) | + (scmds.voltage==SEC_VOLTAGE_18 ? 2 : 0); + + scmds.miniCommand=SEC_MINI_NONE; + scmds.numCommands=1; + scmds.commands=&scmd; + if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ + perror("SEC SEND: "); + return -1; + } + + if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ + perror("SEC SEND: "); + return -1; + } + + frp.u.qpsk.SymbolRate = srate; + frp.u.qpsk.FEC_inner = fec; + + if (ioctl(front, FE_SET_FRONTEND, &frp) < 0){ + perror("QPSK TUNE: "); + return -1; + } + + pfd[0].fd = front; + pfd[0].events = POLLIN; + + if (poll(pfd,1,3000)){ + if (pfd[0].revents & POLLIN){ + printf("Getting QPSK event\\n"); + if ( ioctl(front, FE_GET_EVENT, &event) + + == -EOVERFLOW){ + perror("qpsk get event"); + return -1; + } + printf("Received "); + switch(event.type){ + case FE_UNEXPECTED_EV: + printf("unexpected event\\n"); + return -1; + case FE_FAILURE_EV: + printf("failure event\\n"); + return -1; + + case FE_COMPLETION_EV: + printf("completion event\\n"); + } + } + } + + + pesFilterParams.pid = vpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_VIDEO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_vpid"); + return -1; + } + + pesFilterParams.pid = apid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_AUDIO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_apid"); + return -1; + } + + pesFilterParams.pid = tpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_TELETEXT; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux3, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_tpid"); + return -1; + } + + return has_signal(fds); + } + +The program assumes that you are using a universal LNB and a standard +DiSEqC switch with up to 4 addresses. Of course, you could build in some +more checking if tuning was successful and maybe try to repeat the +tuning process. Depending on the external hardware, i.e. LNB and DiSEqC +switch, and weather conditions this may be necessary. + + +.. _the_dvr_device: + +Example: The DVR device +======================== + +The following program code shows how to use the DVR device for +recording. + + +.. code-block:: c + + #include + #include + #include + #include + #include + #include + #include + #include + + #include + #include + #include + #define DVR "/dev/dvb/adapter0/dvr1" + #define AUDIO "/dev/dvb/adapter0/audio1" + #define VIDEO "/dev/dvb/adapter0/video1" + + #define BUFFY (188*20) + #define MAX_LENGTH (1024*1024*5) /* record 5MB */ + + + /* switch the demuxes to recording, assuming the transponder is tuned */ + + /* demux1, demux2: file descriptor of video and audio filters */ + /* vpid, apid: PIDs of video and audio channels */ + + int switch_to_record(int demux1, int demux2, uint16_t vpid, uint16_t apid) + { + struct dmx_pes_filter_params pesFilterParams; + + if (demux1 < 0){ + if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux2 < 0){ + if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + pesFilterParams.pid = vpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_TS_TAP; + pesFilterParams.pes_type = DMX_PES_VIDEO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("DEMUX DEVICE"); + return -1; + } + pesFilterParams.pid = apid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_TS_TAP; + pesFilterParams.pes_type = DMX_PES_AUDIO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("DEMUX DEVICE"); + return -1; + } + return 0; + } + + /* start recording MAX_LENGTH , assuming the transponder is tuned */ + + /* demux1, demux2: file descriptor of video and audio filters */ + /* vpid, apid: PIDs of video and audio channels */ + int record_dvr(int demux1, int demux2, uint16_t vpid, uint16_t apid) + { + int i; + int len; + int written; + uint8_t buf[BUFFY]; + uint64_t length; + struct pollfd pfd[1]; + int dvr, dvr_out; + + /* open dvr device */ + if ((dvr = open(DVR, O_RDONLY|O_NONBLOCK)) < 0){ + perror("DVR DEVICE"); + return -1; + } + + /* switch video and audio demuxes to dvr */ + printf ("Switching dvr on\\n"); + i = switch_to_record(demux1, demux2, vpid, apid); + printf("finished: "); + + printf("Recording %2.0f MB of test file in TS format\\n", + MAX_LENGTH/(1024.0*1024.0)); + length = 0; + + /* open output file */ + if ((dvr_out = open(DVR_FILE,O_WRONLY|O_CREAT + |O_TRUNC, S_IRUSR|S_IWUSR + |S_IRGRP|S_IWGRP|S_IROTH| + S_IWOTH)) < 0){ + perror("Can't open file for dvr test"); + return -1; + } + + pfd[0].fd = dvr; + pfd[0].events = POLLIN; + + /* poll for dvr data and write to file */ + while (length < MAX_LENGTH ) { + if (poll(pfd,1,1)){ + if (pfd[0].revents & POLLIN){ + len = read(dvr, buf, BUFFY); + if (len < 0){ + perror("recording"); + return -1; + } + if (len > 0){ + written = 0; + while (written < len) + written += + write (dvr_out, + buf, len); + length += len; + printf("written %2.0f MB\\r", + length/1024./1024.); + } + } + } + } + return 0; + } diff --git a/Documentation/media/uapi/dvb/fe-bandwidth-t.rst b/Documentation/media/uapi/dvb/fe-bandwidth-t.rst new file mode 100644 index 0000000000000000000000000000000000000000..8edaf1a8fbc8281f1717de5661f3cd6efcb57803 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-bandwidth-t.rst @@ -0,0 +1,77 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _fe-bandwidth-t: + +****************** +Frontend bandwidth +****************** + + +.. _fe-bandwidth: + +.. flat-table:: enum fe_bandwidth + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _BANDWIDTH-AUTO: + + ``BANDWIDTH_AUTO`` + + - Autodetect bandwidth (if supported) + + - .. row 3 + + - .. _BANDWIDTH-1-712-MHZ: + + ``BANDWIDTH_1_712_MHZ`` + + - 1.712 MHz + + - .. row 4 + + - .. _BANDWIDTH-5-MHZ: + + ``BANDWIDTH_5_MHZ`` + + - 5 MHz + + - .. row 5 + + - .. _BANDWIDTH-6-MHZ: + + ``BANDWIDTH_6_MHZ`` + + - 6 MHz + + - .. row 6 + + - .. _BANDWIDTH-7-MHZ: + + ``BANDWIDTH_7_MHZ`` + + - 7 MHz + + - .. row 7 + + - .. _BANDWIDTH-8-MHZ: + + ``BANDWIDTH_8_MHZ`` + + - 8 MHz + + - .. row 8 + + - .. _BANDWIDTH-10-MHZ: + + ``BANDWIDTH_10_MHZ`` + + - 10 MHz diff --git a/Documentation/media/uapi/dvb/fe-diseqc-recv-slave-reply.rst b/Documentation/media/uapi/dvb/fe-diseqc-recv-slave-reply.rst new file mode 100644 index 0000000000000000000000000000000000000000..7bd02ac7bff43c0951538448106e4a6ff889189a --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-diseqc-recv-slave-reply.rst @@ -0,0 +1,83 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_DISEQC_RECV_SLAVE_REPLY: + +******************************** +ioctl FE_DISEQC_RECV_SLAVE_REPLY +******************************** + +Name +==== + +FE_DISEQC_RECV_SLAVE_REPLY - Receives reply from a DiSEqC 2.0 command + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dvb_diseqc_slave_reply *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_DISEQC_RECV_SLAVE_REPLY + +``argp`` + pointer to struct + :ref:`dvb_diseqc_slave_reply ` + + +Description +=========== + +Receives reply from a DiSEqC 2.0 command. + +.. _dvb-diseqc-slave-reply: + +struct dvb_diseqc_slave_reply +----------------------------- + +.. flat-table:: struct dvb_diseqc_slave_reply + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - uint8_t + + - msg[4] + + - DiSEqC message (framing, data[3]) + + - .. row 2 + + - uint8_t + + - msg_len + + - Length of the DiSEqC message. Valid values are 0 to 4, where 0 + means no msg + + - .. row 3 + + - int + + - timeout + + - Return from ioctl after timeout ms with errorcode when no message + was received + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-diseqc-reset-overload.rst b/Documentation/media/uapi/dvb/fe-diseqc-reset-overload.rst new file mode 100644 index 0000000000000000000000000000000000000000..cab157054c1361e9e46d1f7ccc9fcb5b25b5759e --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-diseqc-reset-overload.rst @@ -0,0 +1,45 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_DISEQC_RESET_OVERLOAD: + +****************************** +ioctl FE_DISEQC_RESET_OVERLOAD +****************************** + +Name +==== + +FE_DISEQC_RESET_OVERLOAD - Restores the power to the antenna subsystem, if it was powered off due - to power overload. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, NULL ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_DISEQC_RESET_OVERLOAD + + +Description +=========== + +If the bus has been automatically powered off due to power overload, +this ioctl call restores the power to the bus. The call requires +read/write access to the device. This call has no effect if the device +is manually powered off. Not all DVB adapters support this ioctl. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-diseqc-send-burst.rst b/Documentation/media/uapi/dvb/fe-diseqc-send-burst.rst new file mode 100644 index 0000000000000000000000000000000000000000..9b476545ef89a7e502be197aa117443a4d4916a5 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-diseqc-send-burst.rst @@ -0,0 +1,84 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_DISEQC_SEND_BURST: + +************************** +ioctl FE_DISEQC_SEND_BURST +************************** + +Name +==== + +FE_DISEQC_SEND_BURST - Sends a 22KHz tone burst for 2x1 mini DiSEqC satellite selection. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, enum fe_sec_mini_cmd *tone ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_DISEQC_SEND_BURST + +``tone`` + pointer to enum :ref:`fe_sec_mini_cmd ` + + +Description +=========== + +This ioctl is used to set the generation of a 22kHz tone burst for mini +DiSEqC satellite selection for 2x1 switches. This call requires +read/write permissions. + +It provides support for what's specified at +`Digital Satellite Equipment Control (DiSEqC) - Simple "ToneBurst" Detection Circuit specification. `__ + +.. _fe-sec-mini-cmd-t: + +enum fe_sec_mini_cmd +==================== + +.. _fe-sec-mini-cmd: + +.. flat-table:: enum fe_sec_mini_cmd + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _SEC-MINI-A: + + ``SEC_MINI_A`` + + - Sends a mini-DiSEqC 22kHz '0' Tone Burst to select satellite-A + + - .. row 3 + + - .. _SEC-MINI-B: + + ``SEC_MINI_B`` + + - Sends a mini-DiSEqC 22kHz '1' Data Burst to select satellite-B + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-diseqc-send-master-cmd.rst b/Documentation/media/uapi/dvb/fe-diseqc-send-master-cmd.rst new file mode 100644 index 0000000000000000000000000000000000000000..58a5e6ac10bd046ac94997f4aa2a01e6087200b6 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-diseqc-send-master-cmd.rst @@ -0,0 +1,73 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_DISEQC_SEND_MASTER_CMD: + +******************************* +ioctl FE_DISEQC_SEND_MASTER_CMD +******************************* + +Name +==== + +FE_DISEQC_SEND_MASTER_CMD - Sends a DiSEqC command + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dvb_diseqc_master_cmd *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_DISEQC_SEND_MASTER_CMD + +``argp`` + pointer to struct + :ref:`dvb_diseqc_master_cmd ` + + +Description +=========== + +Sends a DiSEqC command to the antenna subsystem. + +.. _dvb-diseqc-master-cmd: + +struct dvb_diseqc_master_cmd +============================ + +.. flat-table:: struct dvb_diseqc_master_cmd + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - uint8_t + + - msg[6] + + - DiSEqC message (framing, address, command, data[3]) + + - .. row 2 + + - uint8_t + + - msg_len + + - Length of the DiSEqC message. Valid values are 3 to 6 + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + diff --git a/Documentation/media/uapi/dvb/fe-dishnetwork-send-legacy-cmd.rst b/Documentation/media/uapi/dvb/fe-dishnetwork-send-legacy-cmd.rst new file mode 100644 index 0000000000000000000000000000000000000000..d47e9dbf558a2aa5d8377573e97a25204ede768b --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-dishnetwork-send-legacy-cmd.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_DISHNETWORK_SEND_LEGACY_CMD: + +****************************** +FE_DISHNETWORK_SEND_LEGACY_CMD +****************************** + +Name +==== + +FE_DISHNETWORK_SEND_LEGACY_CMD + + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = FE_DISHNETWORK_SEND_LEGACY_CMD, unsigned long cmd) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - unsigned long cmd + + - sends the specified raw cmd to the dish via DISEqC. + + +Description +=========== + +.. warning:: + This is a very obscure legacy command, used only at stv0299 + driver. Should not be used on newer drivers. + +It provides a non-standard method for selecting Diseqc voltage on the +frontend, for Dish Network legacy switches. + +As support for this ioctl were added in 2004, this means that such +dishes were already legacy in 2004. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-enable-high-lnb-voltage.rst b/Documentation/media/uapi/dvb/fe-enable-high-lnb-voltage.rst new file mode 100644 index 0000000000000000000000000000000000000000..de99bf5fbf0eced4490d1ce8579e7f3ddf4c4123 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-enable-high-lnb-voltage.rst @@ -0,0 +1,52 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_ENABLE_HIGH_LNB_VOLTAGE: + +******************************** +ioctl FE_ENABLE_HIGH_LNB_VOLTAGE +******************************** + +Name +==== + +FE_ENABLE_HIGH_LNB_VOLTAGE - Select output DC level between normal LNBf voltages or higher LNBf - voltages. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, unsigned int high ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_ENABLE_HIGH_LNB_VOLTAGE + +``high`` + Valid flags: + + - 0 - normal 13V and 18V. + + - >0 - enables slightly higher voltages instead of 13/18V, in order + to compensate for long antenna cables. + + +Description +=========== + +Select output DC level between normal LNBf voltages or higher LNBf +voltages between 0 (normal) or a value grater than 0 for higher +voltages. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-get-event.rst b/Documentation/media/uapi/dvb/fe-get-event.rst new file mode 100644 index 0000000000000000000000000000000000000000..ffa3d04c6bd49bcd342809c667390c5a1fa957ec --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-get-event.rst @@ -0,0 +1,87 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_GET_EVENT: + +************ +FE_GET_EVENT +************ + +Name +==== + +FE_GET_EVENT + + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = QPSK_GET_EVENT, struct dvb_frontend_event *ev) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals :ref:`FE_GET_EVENT` for this command. + + - .. row 3 + + - struct dvb_frontend_event \*ev + + - Points to the location where the event, + + - .. row 4 + + - + - if any, is to be stored. + + +Description +=========== + +This ioctl call returns a frontend event if available. If an event is +not available, the behavior depends on whether the device is in blocking +or non-blocking mode. In the latter case, the call fails immediately +with errno set to ``EWOULDBLOCK``. In the former case, the call blocks until +an event becomes available. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EWOULDBLOCK`` + + - There is no event pending, and the device is in non-blocking mode. + + - .. row 2 + + - ``EOVERFLOW`` + + - Overflow in event queue - one or more events were lost. diff --git a/Documentation/media/uapi/dvb/fe-get-frontend.rst b/Documentation/media/uapi/dvb/fe-get-frontend.rst new file mode 100644 index 0000000000000000000000000000000000000000..5d2df808df18e01838f16b068cd18527b2d07a95 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-get-frontend.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_GET_FRONTEND: + +*************** +FE_GET_FRONTEND +*************** + +Name +==== + +FE_GET_FRONTEND + + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = FE_GET_FRONTEND, struct dvb_frontend_parameters *p) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals :ref:`FE_SET_FRONTEND` for this + command. + + - .. row 3 + + - struct dvb_frontend_parameters \*p + + - Points to parameters for tuning operation. + + +Description +=========== + +This ioctl call queries the currently effective frontend parameters. For +this command, read-only access to the device is sufficient. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - Maximum supported symbol rate reached. diff --git a/Documentation/media/uapi/dvb/fe-get-info.rst b/Documentation/media/uapi/dvb/fe-get-info.rst new file mode 100644 index 0000000000000000000000000000000000000000..bb6c32e47ce8052a524acd4fb036534687ebcb21 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-get-info.rst @@ -0,0 +1,428 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_GET_INFO: + +***************** +ioctl FE_GET_INFO +***************** + +Name +==== + +FE_GET_INFO - Query DVB frontend capabilities and returns information about the - front-end. This call only requires read-only access to the device + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dvb_frontend_info *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_GET_INFO + +``argp`` + pointer to struct struct + :ref:`dvb_frontend_info ` + + +Description +=========== + +All DVB frontend devices support the ``FE_GET_INFO`` ioctl. It is used +to identify kernel devices compatible with this specification and to +obtain information about driver and hardware capabilities. The ioctl +takes a pointer to dvb_frontend_info which is filled by the driver. +When the driver is not compatible with this specification the ioctl +returns an error. + +.. _dvb-frontend-info: + +struct dvb_frontend_info +======================== + +.. flat-table:: struct dvb_frontend_info + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - char + + - name[128] + + - Name of the frontend + + - .. row 2 + + - fe_type_t + + - type + + - **DEPRECATED**. DVBv3 type. Should not be used on modern programs, + as a frontend may have more than one type. So, the DVBv5 API + should be used instead to enumerate and select the frontend type. + + - .. row 3 + + - uint32_t + + - frequency_min + + - Minimal frequency supported by the frontend + + - .. row 4 + + - uint32_t + + - frequency_max + + - Maximal frequency supported by the frontend + + - .. row 5 + + - uint32_t + + - frequency_stepsize + + - Frequency step - all frequencies are multiple of this value + + - .. row 6 + + - uint32_t + + - frequency_tolerance + + - Tolerance of the frequency + + - .. row 7 + + - uint32_t + + - symbol_rate_min + + - Minimal symbol rate (for Cable/Satellite systems), in bauds + + - .. row 8 + + - uint32_t + + - symbol_rate_max + + - Maximal symbol rate (for Cable/Satellite systems), in bauds + + - .. row 9 + + - uint32_t + + - symbol_rate_tolerance + + - Maximal symbol rate tolerance, in ppm + + - .. row 10 + + - uint32_t + + - notifier_delay + + - **DEPRECATED**. Not used by any driver. + + - .. row 11 + + - enum :ref:`fe_caps ` + + - caps + + - Capabilities supported by the frontend + + +.. note:: The frequencies are specified in Hz for Terrestrial and Cable + systems. They're specified in kHz for Satellite systems + + +.. _fe-caps-t: + +frontend capabilities +===================== + +Capabilities describe what a frontend can do. Some capabilities are +supported only on some specific frontend types. + + +.. _fe-caps: + +.. flat-table:: enum fe_caps + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _FE-IS-STUPID: + + ``FE_IS_STUPID`` + + - There's something wrong at the frontend, and it can't report its + capabilities + + - .. row 3 + + - .. _FE-CAN-INVERSION-AUTO: + + ``FE_CAN_INVERSION_AUTO`` + + - The frontend is capable of auto-detecting inversion + + - .. row 4 + + - .. _FE-CAN-FEC-1-2: + + ``FE_CAN_FEC_1_2`` + + - The frontend supports FEC 1/2 + + - .. row 5 + + - .. _FE-CAN-FEC-2-3: + + ``FE_CAN_FEC_2_3`` + + - The frontend supports FEC 2/3 + + - .. row 6 + + - .. _FE-CAN-FEC-3-4: + + ``FE_CAN_FEC_3_4`` + + - The frontend supports FEC 3/4 + + - .. row 7 + + - .. _FE-CAN-FEC-4-5: + + ``FE_CAN_FEC_4_5`` + + - The frontend supports FEC 4/5 + + - .. row 8 + + - .. _FE-CAN-FEC-5-6: + + ``FE_CAN_FEC_5_6`` + + - The frontend supports FEC 5/6 + + - .. row 9 + + - .. _FE-CAN-FEC-6-7: + + ``FE_CAN_FEC_6_7`` + + - The frontend supports FEC 6/7 + + - .. row 10 + + - .. _FE-CAN-FEC-7-8: + + ``FE_CAN_FEC_7_8`` + + - The frontend supports FEC 7/8 + + - .. row 11 + + - .. _FE-CAN-FEC-8-9: + + ``FE_CAN_FEC_8_9`` + + - The frontend supports FEC 8/9 + + - .. row 12 + + - .. _FE-CAN-FEC-AUTO: + + ``FE_CAN_FEC_AUTO`` + + - The frontend can autodetect FEC. + + - .. row 13 + + - .. _FE-CAN-QPSK: + + ``FE_CAN_QPSK`` + + - The frontend supports QPSK modulation + + - .. row 14 + + - .. _FE-CAN-QAM-16: + + ``FE_CAN_QAM_16`` + + - The frontend supports 16-QAM modulation + + - .. row 15 + + - .. _FE-CAN-QAM-32: + + ``FE_CAN_QAM_32`` + + - The frontend supports 32-QAM modulation + + - .. row 16 + + - .. _FE-CAN-QAM-64: + + ``FE_CAN_QAM_64`` + + - The frontend supports 64-QAM modulation + + - .. row 17 + + - .. _FE-CAN-QAM-128: + + ``FE_CAN_QAM_128`` + + - The frontend supports 128-QAM modulation + + - .. row 18 + + - .. _FE-CAN-QAM-256: + + ``FE_CAN_QAM_256`` + + - The frontend supports 256-QAM modulation + + - .. row 19 + + - .. _FE-CAN-QAM-AUTO: + + ``FE_CAN_QAM_AUTO`` + + - The frontend can autodetect modulation + + - .. row 20 + + - .. _FE-CAN-TRANSMISSION-MODE-AUTO: + + ``FE_CAN_TRANSMISSION_MODE_AUTO`` + + - The frontend can autodetect the transmission mode + + - .. row 21 + + - .. _FE-CAN-BANDWIDTH-AUTO: + + ``FE_CAN_BANDWIDTH_AUTO`` + + - The frontend can autodetect the bandwidth + + - .. row 22 + + - .. _FE-CAN-GUARD-INTERVAL-AUTO: + + ``FE_CAN_GUARD_INTERVAL_AUTO`` + + - The frontend can autodetect the guard interval + + - .. row 23 + + - .. _FE-CAN-HIERARCHY-AUTO: + + ``FE_CAN_HIERARCHY_AUTO`` + + - The frontend can autodetect hierarch + + - .. row 24 + + - .. _FE-CAN-8VSB: + + ``FE_CAN_8VSB`` + + - The frontend supports 8-VSB modulation + + - .. row 25 + + - .. _FE-CAN-16VSB: + + ``FE_CAN_16VSB`` + + - The frontend supports 16-VSB modulation + + - .. row 26 + + - .. _FE-HAS-EXTENDED-CAPS: + + ``FE_HAS_EXTENDED_CAPS`` + + - Currently, unused + + - .. row 27 + + - .. _FE-CAN-MULTISTREAM: + + ``FE_CAN_MULTISTREAM`` + + - The frontend supports multistream filtering + + - .. row 28 + + - .. _FE-CAN-TURBO-FEC: + + ``FE_CAN_TURBO_FEC`` + + - The frontend supports turbo FEC modulation + + - .. row 29 + + - .. _FE-CAN-2G-MODULATION: + + ``FE_CAN_2G_MODULATION`` + + - The frontend supports "2nd generation modulation" (DVB-S2/T2)> + + - .. row 30 + + - .. _FE-NEEDS-BENDING: + + ``FE_NEEDS_BENDING`` + + - Not supported anymore, don't use it + + - .. row 31 + + - .. _FE-CAN-RECOVER: + + ``FE_CAN_RECOVER`` + + - The frontend can recover from a cable unplug automatically + + - .. row 32 + + - .. _FE-CAN-MUTE-TS: + + ``FE_CAN_MUTE_TS`` + + - The frontend can stop spurious TS data output + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-get-property.rst b/Documentation/media/uapi/dvb/fe-get-property.rst new file mode 100644 index 0000000000000000000000000000000000000000..749daafe6b218adc900b577184127f043508557a --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-get-property.rst @@ -0,0 +1,68 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_GET_PROPERTY: + +************************************** +ioctl FE_SET_PROPERTY, FE_GET_PROPERTY +************************************** + +Name +==== + +FE_SET_PROPERTY - FE_GET_PROPERTY - FE_SET_PROPERTY sets one or more frontend properties. - FE_GET_PROPERTY returns one or more frontend properties. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dtv_properties *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_PROPERTY, FE_GET_PROPERTY + +``argp`` + pointer to struct :ref:`dtv_properties ` + + +Description +=========== + +All DVB frontend devices support the ``FE_SET_PROPERTY`` and +``FE_GET_PROPERTY`` ioctls. The supported properties and statistics +depends on the delivery system and on the device: + +- ``FE_SET_PROPERTY:`` + + - This ioctl is used to set one or more frontend properties. + + - This is the basic command to request the frontend to tune into + some frequency and to start decoding the digital TV signal. + + - This call requires read/write access to the device. + + - At return, the values are updated to reflect the actual parameters + used. + +- ``FE_GET_PROPERTY:`` + + - This ioctl is used to get properties and statistics from the + frontend. + + - No properties are changed, and statistics aren't reset. + + - This call only requires read-only access to the device. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-read-ber.rst b/Documentation/media/uapi/dvb/fe-read-ber.rst new file mode 100644 index 0000000000000000000000000000000000000000..c2b5b417f5fbd7c61ce8b750421f59a355abd11d --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-read-ber.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_READ_BER: + +*********** +FE_READ_BER +*********** + +Name +==== + +FE_READ_BER + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = FE_READ_BER, uint32_t *ber) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals :ref:`FE_READ_BER` for this command. + + - .. row 3 + + - uint32_t \*ber + + - The bit error rate is stored into \*ber. + + +Description +=========== + +This ioctl call returns the bit error rate for the signal currently +received/demodulated by the front-end. For this command, read-only +access to the device is sufficient. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-read-signal-strength.rst b/Documentation/media/uapi/dvb/fe-read-signal-strength.rst new file mode 100644 index 0000000000000000000000000000000000000000..0cdee2effc972b872cbe8b4499a779444a35c583 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-read-signal-strength.rst @@ -0,0 +1,63 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_READ_SIGNAL_STRENGTH: + +*********************** +FE_READ_SIGNAL_STRENGTH +*********************** + +Name +==== + +FE_READ_SIGNAL_STRENGTH + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request = FE_READ_SIGNAL_STRENGTH, uint16_t *strength) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals + :ref:`FE_READ_SIGNAL_STRENGTH` + for this command. + + - .. row 3 + + - uint16_t \*strength + + - The signal strength value is stored into \*strength. + + +Description +=========== + +This ioctl call returns the signal strength value for the signal +currently received by the front-end. For this command, read-only access +to the device is sufficient. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-read-snr.rst b/Documentation/media/uapi/dvb/fe-read-snr.rst new file mode 100644 index 0000000000000000000000000000000000000000..5394f9ae90f49f71f904430a302bd420da008156 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-read-snr.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_READ_SNR: + +*********** +FE_READ_SNR +*********** + +Name +==== + +FE_READ_SNR + + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = FE_READ_SNR, int16_t *snr) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals :ref:`FE_READ_SNR` for this command. + + - .. row 3 + + - uint16_t \*snr + + - The signal-to-noise ratio is stored into \*snr. + + +Description +=========== + +This ioctl call returns the signal-to-noise ratio for the signal +currently received by the front-end. For this command, read-only access +to the device is sufficient. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-read-status.rst b/Documentation/media/uapi/dvb/fe-read-status.rst new file mode 100644 index 0000000000000000000000000000000000000000..624ed9d06488e2e64caa6caaad800f9674537f93 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-read-status.rst @@ -0,0 +1,135 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_READ_STATUS: + +******************** +ioctl FE_READ_STATUS +******************** + +Name +==== + +FE_READ_STATUS - Returns status information about the front-end. This call only requires - read-only access to the device + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, unsigned int *status ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_READ_STATUS + +``status`` + pointer to a bitmask integer filled with the values defined by enum + :ref:`fe_status `. + + +Description +=========== + +All DVB frontend devices support the ``FE_READ_STATUS`` ioctl. It is +used to check about the locking status of the frontend after being +tuned. The ioctl takes a pointer to an integer where the status will be +written. + +.. note:: The size of status is actually sizeof(enum fe_status), with + varies according with the architecture. This needs to be fixed in the + future. + + +.. _fe-status-t: + +int fe_status +============= + +The fe_status parameter is used to indicate the current state and/or +state changes of the frontend hardware. It is produced using the enum +:ref:`fe_status ` values on a bitmask + + +.. _fe-status: + +.. flat-table:: enum fe_status + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _FE-HAS-SIGNAL: + + ``FE_HAS_SIGNAL`` + + - The frontend has found something above the noise level + + - .. row 3 + + - .. _FE-HAS-CARRIER: + + ``FE_HAS_CARRIER`` + + - The frontend has found a DVB signal + + - .. row 4 + + - .. _FE-HAS-VITERBI: + + ``FE_HAS_VITERBI`` + + - The frontend FEC inner coding (Viterbi, LDPC or other inner code) + is stable + + - .. row 5 + + - .. _FE-HAS-SYNC: + + ``FE_HAS_SYNC`` + + - Synchronization bytes was found + + - .. row 6 + + - .. _FE-HAS-LOCK: + + ``FE_HAS_LOCK`` + + - The DVB were locked and everything is working + + - .. row 7 + + - .. _FE-TIMEDOUT: + + ``FE_TIMEDOUT`` + + - no lock within the last about 2 seconds + + - .. row 8 + + - .. _FE-REINIT: + + ``FE_REINIT`` + + - The frontend was reinitialized, application is recommended to + reset DiSEqC, tone and parameters + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-read-uncorrected-blocks.rst b/Documentation/media/uapi/dvb/fe-read-uncorrected-blocks.rst new file mode 100644 index 0000000000000000000000000000000000000000..5c29c058dfdc115c7e60ea674de6c447dfce04de --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-read-uncorrected-blocks.rst @@ -0,0 +1,65 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_READ_UNCORRECTED_BLOCKS: + +************************** +FE_READ_UNCORRECTED_BLOCKS +************************** + +Name +==== + +FE_READ_UNCORRECTED_BLOCKS + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request =FE_READ_UNCORRECTED_BLOCKS, uint32_t *ublocks) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals + :ref:`FE_READ_UNCORRECTED_BLOCKS` + for this command. + + - .. row 3 + + - uint32_t \*ublocks + + - The total number of uncorrected blocks seen by the driver so far. + + +Description +=========== + +This ioctl call returns the number of uncorrected blocks detected by the +device driver during its lifetime. For meaningful measurements, the +increment in block count during a specific time interval should be +calculated. For this command, read-only access to the device is +sufficient. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-set-frontend-tune-mode.rst b/Documentation/media/uapi/dvb/fe-set-frontend-tune-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..411abcf4de582cc73e14606ea6c94c2c2b357c8e --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-set-frontend-tune-mode.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_SET_FRONTEND_TUNE_MODE: + +******************************* +ioctl FE_SET_FRONTEND_TUNE_MODE +******************************* + +Name +==== + +FE_SET_FRONTEND_TUNE_MODE - Allow setting tuner mode flags to the frontend. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, unsigned int flags ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_FRONTEND_TUNE_MODE + +``flags`` + Valid flags: + + - 0 - normal tune mode + + - FE_TUNE_MODE_ONESHOT - When set, this flag will disable any + zigzagging or other "normal" tuning behaviour. Additionally, + there will be no automatic monitoring of the lock status, and + hence no frontend events will be generated. If a frontend device + is closed, this flag will be automatically turned off when the + device is reopened read-write. + + +Description +=========== + +Allow setting tuner mode flags to the frontend, between 0 (normal) or +FE_TUNE_MODE_ONESHOT mode + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-set-frontend.rst b/Documentation/media/uapi/dvb/fe-set-frontend.rst new file mode 100644 index 0000000000000000000000000000000000000000..7cb70c38d53465d04b361c097aaa35d36f374fc4 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-set-frontend.rst @@ -0,0 +1,79 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_SET_FRONTEND: + +*************** +FE_SET_FRONTEND +*************** + +Name +==== + +FE_SET_FRONTEND + + +Synopsis +======== + +.. cpp:function:: int ioctl(int fd, int request = FE_SET_FRONTEND, struct dvb_frontend_parameters *p) + + +Arguments +========= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals :ref:`FE_SET_FRONTEND` for this + command. + + - .. row 3 + + - struct dvb_frontend_parameters \*p + + - Points to parameters for tuning operation. + + +Description +=========== + +This ioctl call starts a tuning operation using specified parameters. +The result of this call will be successful if the parameters were valid +and the tuning could be initiated. The result of the tuning operation in +itself, however, will arrive asynchronously as an event (see +documentation for :ref:`FE_GET_EVENT` and +FrontendEvent.) If a new :ref:`FE_SET_FRONTEND` +operation is initiated before the previous one was completed, the +previous operation will be aborted in favor of the new one. This command +requires read/write access to the device. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - Maximum supported symbol rate reached. diff --git a/Documentation/media/uapi/dvb/fe-set-tone.rst b/Documentation/media/uapi/dvb/fe-set-tone.rst new file mode 100644 index 0000000000000000000000000000000000000000..545e2afba2c018130f564110c578ae1b22eb9746 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-set-tone.rst @@ -0,0 +1,91 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_SET_TONE: + +***************** +ioctl FE_SET_TONE +***************** + +Name +==== + +FE_SET_TONE - Sets/resets the generation of the continuous 22kHz tone. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, enum fe_sec_tone_mode *tone ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_TONE + +``tone`` + pointer to enum :ref:`fe_sec_tone_mode ` + + +Description +=========== + +This ioctl is used to set the generation of the continuous 22kHz tone. +This call requires read/write permissions. + +Usually, satellite antenna subsystems require that the digital TV device +to send a 22kHz tone in order to select between high/low band on some +dual-band LNBf. It is also used to send signals to DiSEqC equipment, but +this is done using the DiSEqC ioctls. + +.. attention:: If more than one device is connected to the same antenna, + setting a tone may interfere on other devices, as they may lose the + capability of selecting the band. So, it is recommended that applications + would change to SEC_TONE_OFF when the device is not used. + +.. _fe-sec-tone-mode-t: + +enum fe_sec_tone_mode +===================== + +.. _fe-sec-tone-mode: + +.. flat-table:: enum fe_sec_tone_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _SEC-TONE-ON: + + ``SEC_TONE_ON`` + + - Sends a 22kHz tone burst to the antenna + + - .. row 3 + + - .. _SEC-TONE-OFF: + + ``SEC_TONE_OFF`` + + - Don't send a 22kHz tone to the antenna (except if the + FE_DISEQC_* ioctls are called) + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-set-voltage.rst b/Documentation/media/uapi/dvb/fe-set-voltage.rst new file mode 100644 index 0000000000000000000000000000000000000000..2b19086b660a09bb5713cf1bdc19dc3e06453f34 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-set-voltage.rst @@ -0,0 +1,63 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _FE_SET_VOLTAGE: + +******************** +ioctl FE_SET_VOLTAGE +******************** + +Name +==== + +FE_SET_VOLTAGE - Allow setting the DC level sent to the antenna subsystem. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, enum fe_sec_voltage *voltage ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_VOLTAGE + +``voltage`` + pointer to enum :ref:`fe_sec_voltage ` + + Valid values are described at enum + :ref:`fe_sec_voltage `. + + +Description +=========== + +This ioctl allows to set the DC voltage level sent through the antenna +cable to 13V, 18V or off. + +Usually, a satellite antenna subsystems require that the digital TV +device to send a DC voltage to feed power to the LNBf. Depending on the +LNBf type, the polarization or the intermediate frequency (IF) of the +LNBf can controlled by the voltage level. Other devices (for example, +the ones that implement DISEqC and multipoint LNBf's don't need to +control the voltage level, provided that either 13V or 18V is sent to +power up the LNBf. + +.. attention:: if more than one device is connected to the same antenna, + setting a voltage level may interfere on other devices, as they may lose + the capability of setting polarization or IF. So, on those cases, setting + the voltage to SEC_VOLTAGE_OFF while the device is not is used is + recommended. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/fe-type-t.rst b/Documentation/media/uapi/dvb/fe-type-t.rst new file mode 100644 index 0000000000000000000000000000000000000000..8ca762b42e4d68684cbddebb39eaed6f11d75869 --- /dev/null +++ b/Documentation/media/uapi/dvb/fe-type-t.rst @@ -0,0 +1,91 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _fe-type-t: + +************* +Frontend type +************* + +For historical reasons, frontend types are named by the type of +modulation used in transmission. The fontend types are given by +fe_type_t type, defined as: + + +.. _fe-type: + +.. flat-table:: Frontend types + :header-rows: 1 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. row 1 + + - fe_type + + - Description + + - :ref:`DTV_DELIVERY_SYSTEM ` equivalent + type + + - .. row 2 + + - .. _FE-QPSK: + + ``FE_QPSK`` + + - For DVB-S standard + + - ``SYS_DVBS`` + + - .. row 3 + + - .. _FE-QAM: + + ``FE_QAM`` + + - For DVB-C annex A standard + + - ``SYS_DVBC_ANNEX_A`` + + - .. row 4 + + - .. _FE-OFDM: + + ``FE_OFDM`` + + - For DVB-T standard + + - ``SYS_DVBT`` + + - .. row 5 + + - .. _FE-ATSC: + + ``FE_ATSC`` + + - For ATSC standard (terrestrial) or for DVB-C Annex B (cable) used + in US. + + - ``SYS_ATSC`` (terrestrial) or ``SYS_DVBC_ANNEX_B`` (cable) + + +Newer formats like DVB-S2, ISDB-T, ISDB-S and DVB-T2 are not described +at the above, as they're supported via the new +:ref:`FE_GET_PROPERTY/FE_GET_SET_PROPERTY ` +ioctl's, using the :ref:`DTV_DELIVERY_SYSTEM ` +parameter. + +In the old days, struct :ref:`dvb_frontend_info ` +used to contain ``fe_type_t`` field to indicate the delivery systems, +filled with either FE_QPSK, FE_QAM, FE_OFDM or FE_ATSC. While this +is still filled to keep backward compatibility, the usage of this field +is deprecated, as it can report just one delivery system, but some +devices support multiple delivery systems. Please use +:ref:`DTV_ENUM_DELSYS ` instead. + +On devices that support multiple delivery systems, struct +:ref:`dvb_frontend_info `::``fe_type_t`` is +filled with the currently standard, as selected by the last call to +:ref:`FE_SET_PROPERTY ` using the +:ref:`DTV_DELIVERY_SYSTEM ` property. diff --git a/Documentation/media/uapi/dvb/fe_property_parameters.rst b/Documentation/media/uapi/dvb/fe_property_parameters.rst new file mode 100644 index 0000000000000000000000000000000000000000..f776d62523da39ba075a12a61ce3387c0378d56b --- /dev/null +++ b/Documentation/media/uapi/dvb/fe_property_parameters.rst @@ -0,0 +1,1979 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _fe_property_parameters: + +****************************** +Digital TV property parameters +****************************** + + +.. _DTV-UNDEFINED: + +DTV_UNDEFINED +============= + +Used internally. A GET/SET operation for it won't change or return +anything. + + +.. _DTV-TUNE: + +DTV_TUNE +======== + +Interpret the cache of data, build either a traditional frontend +tunerequest so we can pass validation in the ``FE_SET_FRONTEND`` ioctl. + + +.. _DTV-CLEAR: + +DTV_CLEAR +========= + +Reset a cache of data specific to the frontend here. This does not +effect hardware. + + +.. _DTV-FREQUENCY: + +DTV_FREQUENCY +============= + +Frequency of the digital TV transponder/channel. + +.. note:: + + #. For satellite delivery systems, the frequency is in kHz. + + #. For cable and terrestrial delivery systems, the frequency is in + Hz. + + #. On most delivery systems, the frequency is the center frequency + of the transponder/channel. The exception is for ISDB-T, where + the main carrier has a 1/7 offset from the center. + + #. For ISDB-T, the channels are usually transmitted with an offset of + about 143kHz. E.g. a valid frequency could be 474,143 kHz. The + stepping is bound to the bandwidth of the channel which is + typically 6MHz. + + #. In ISDB-Tsb, the channel consists of only one or three segments the + frequency step is 429kHz, 3*429 respectively. + + +.. _DTV-MODULATION: + +DTV_MODULATION +============== + +Specifies the frontend modulation type for delivery systems that +supports more than one modulation type. The modulation can be one of the +types defined by enum :ref:`fe_modulation `. + + +.. _fe-modulation-t: + +Modulation property +------------------- + +Most of the digital TV standards currently offers more than one possible +modulation (sometimes called as "constellation" on some standards). This +enum contains the values used by the Kernel. Please note that not all +modulations are supported by a given standard. + + +.. _fe-modulation: + +.. flat-table:: enum fe_modulation + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _QPSK: + + ``QPSK`` + + - QPSK modulation + + - .. row 3 + + - .. _QAM-16: + + ``QAM_16`` + + - 16-QAM modulation + + - .. row 4 + + - .. _QAM-32: + + ``QAM_32`` + + - 32-QAM modulation + + - .. row 5 + + - .. _QAM-64: + + ``QAM_64`` + + - 64-QAM modulation + + - .. row 6 + + - .. _QAM-128: + + ``QAM_128`` + + - 128-QAM modulation + + - .. row 7 + + - .. _QAM-256: + + ``QAM_256`` + + - 256-QAM modulation + + - .. row 8 + + - .. _QAM-AUTO: + + ``QAM_AUTO`` + + - Autodetect QAM modulation + + - .. row 9 + + - .. _VSB-8: + + ``VSB_8`` + + - 8-VSB modulation + + - .. row 10 + + - .. _VSB-16: + + ``VSB_16`` + + - 16-VSB modulation + + - .. row 11 + + - .. _PSK-8: + + ``PSK_8`` + + - 8-PSK modulation + + - .. row 12 + + - .. _APSK-16: + + ``APSK_16`` + + - 16-APSK modulation + + - .. row 13 + + - .. _APSK-32: + + ``APSK_32`` + + - 32-APSK modulation + + - .. row 14 + + - .. _DQPSK: + + ``DQPSK`` + + - DQPSK modulation + + - .. row 15 + + - .. _QAM-4-NR: + + ``QAM_4_NR`` + + - 4-QAM-NR modulation + + + +.. _DTV-BANDWIDTH-HZ: + +DTV_BANDWIDTH_HZ +================ + +Bandwidth for the channel, in HZ. + +Possible values: ``1712000``, ``5000000``, ``6000000``, ``7000000``, +``8000000``, ``10000000``. + +.. note:: + + #. DVB-T supports 6, 7 and 8MHz. + + #. DVB-T2 supports 1.172, 5, 6, 7, 8 and 10MHz. + + #. ISDB-T supports 5MHz, 6MHz, 7MHz and 8MHz, although most + places use 6MHz. + + #. On DVB-C and DVB-S/S2, the bandwidth depends on the symbol rate. + So, the Kernel will silently ignore setting :ref:`DTV-BANDWIDTH-HZ`. + + #. For DVB-C and DVB-S/S2, the Kernel will return an estimation of the + bandwidth, calculated from :ref:`DTV-SYMBOL-RATE` and from + the rolloff, with is fixed for DVB-C and DVB-S. + + #. For DVB-S2, the bandwidth estimation will use :ref:`DTV-ROLLOFF`. + + #. For ISDB-Tsb, it can vary depending on the number of connected + segments. + + #. Bandwidth in ISDB-Tsb can be easily derived from other parameters + (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT). + + +.. _DTV-INVERSION: + +DTV_INVERSION +============= + +Specifies if the frontend should do spectral inversion or not. + + +.. _fe-spectral-inversion-t: + +enum fe_modulation: Frontend spectral inversion +----------------------------------------------- + +This parameter indicates if spectral inversion should be presumed or +not. In the automatic setting (``INVERSION_AUTO``) the hardware will try +to figure out the correct setting by itself. If the hardware doesn't +support, the DVB core will try to lock at the carrier first with +inversion off. If it fails, it will try to enable inversion. + + +.. _fe-spectral-inversion: + +.. flat-table:: enum fe_modulation + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _INVERSION-OFF: + + ``INVERSION_OFF`` + + - Don't do spectral band inversion. + + - .. row 3 + + - .. _INVERSION-ON: + + ``INVERSION_ON`` + + - Do spectral band inversion. + + - .. row 4 + + - .. _INVERSION-AUTO: + + ``INVERSION_AUTO`` + + - Autodetect spectral band inversion. + + + +.. _DTV-DISEQC-MASTER: + +DTV_DISEQC_MASTER +================= + +Currently not implemented. + + +.. _DTV-SYMBOL-RATE: + +DTV_SYMBOL_RATE +=============== + +Digital TV symbol rate, in bauds (symbols/second). Used on cable +standards. + + +.. _DTV-INNER-FEC: + +DTV_INNER_FEC +============= + +Used cable/satellite transmissions. The acceptable values are: + + +.. _fe-code-rate-t: + +enum fe_code_rate: type of the Forward Error Correction. +-------------------------------------------------------- + + +.. _fe-code-rate: + +.. flat-table:: enum fe_code_rate + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _FEC-NONE: + + ``FEC_NONE`` + + - No Forward Error Correction Code + + - .. row 3 + + - .. _FEC-AUTO: + + ``FEC_AUTO`` + + - Autodetect Error Correction Code + + - .. row 4 + + - .. _FEC-1-2: + + ``FEC_1_2`` + + - Forward Error Correction Code 1/2 + + - .. row 5 + + - .. _FEC-2-3: + + ``FEC_2_3`` + + - Forward Error Correction Code 2/3 + + - .. row 6 + + - .. _FEC-3-4: + + ``FEC_3_4`` + + - Forward Error Correction Code 3/4 + + - .. row 7 + + - .. _FEC-4-5: + + ``FEC_4_5`` + + - Forward Error Correction Code 4/5 + + - .. row 8 + + - .. _FEC-5-6: + + ``FEC_5_6`` + + - Forward Error Correction Code 5/6 + + - .. row 9 + + - .. _FEC-6-7: + + ``FEC_6_7`` + + - Forward Error Correction Code 6/7 + + - .. row 10 + + - .. _FEC-7-8: + + ``FEC_7_8`` + + - Forward Error Correction Code 7/8 + + - .. row 11 + + - .. _FEC-8-9: + + ``FEC_8_9`` + + - Forward Error Correction Code 8/9 + + - .. row 12 + + - .. _FEC-9-10: + + ``FEC_9_10`` + + - Forward Error Correction Code 9/10 + + - .. row 13 + + - .. _FEC-2-5: + + ``FEC_2_5`` + + - Forward Error Correction Code 2/5 + + - .. row 14 + + - .. _FEC-3-5: + + ``FEC_3_5`` + + - Forward Error Correction Code 3/5 + + + +.. _DTV-VOLTAGE: + +DTV_VOLTAGE +=========== + +The voltage is usually used with non-DiSEqC capable LNBs to switch the +polarzation (horizontal/vertical). When using DiSEqC epuipment this +voltage has to be switched consistently to the DiSEqC commands as +described in the DiSEqC spec. + + +.. _fe-sec-voltage: + +.. flat-table:: enum fe_sec_voltage + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _SEC-VOLTAGE-13: + + ``SEC_VOLTAGE_13`` + + - Set DC voltage level to 13V + + - .. row 3 + + - .. _SEC-VOLTAGE-18: + + ``SEC_VOLTAGE_18`` + + - Set DC voltage level to 18V + + - .. row 4 + + - .. _SEC-VOLTAGE-OFF: + + ``SEC_VOLTAGE_OFF`` + + - Don't send any voltage to the antenna + + + +.. _DTV-TONE: + +DTV_TONE +======== + +Currently not used. + + +.. _DTV-PILOT: + +DTV_PILOT +========= + +Sets DVB-S2 pilot + + +.. _fe-pilot-t: + +fe_pilot type +------------- + + +.. _fe-pilot: + +.. flat-table:: enum fe_pilot + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _PILOT-ON: + + ``PILOT_ON`` + + - Pilot tones enabled + + - .. row 3 + + - .. _PILOT-OFF: + + ``PILOT_OFF`` + + - Pilot tones disabled + + - .. row 4 + + - .. _PILOT-AUTO: + + ``PILOT_AUTO`` + + - Autodetect pilot tones + + + +.. _DTV-ROLLOFF: + +DTV_ROLLOFF +=========== + +Sets DVB-S2 rolloff + + +.. _fe-rolloff-t: + +fe_rolloff type +--------------- + + +.. _fe-rolloff: + +.. flat-table:: enum fe_rolloff + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ROLLOFF-35: + + ``ROLLOFF_35`` + + - Roloff factor: α=35% + + - .. row 3 + + - .. _ROLLOFF-20: + + ``ROLLOFF_20`` + + - Roloff factor: α=20% + + - .. row 4 + + - .. _ROLLOFF-25: + + ``ROLLOFF_25`` + + - Roloff factor: α=25% + + - .. row 5 + + - .. _ROLLOFF-AUTO: + + ``ROLLOFF_AUTO`` + + - Auto-detect the roloff factor. + + + +.. _DTV-DISEQC-SLAVE-REPLY: + +DTV_DISEQC_SLAVE_REPLY +====================== + +Currently not implemented. + + +.. _DTV-FE-CAPABILITY-COUNT: + +DTV_FE_CAPABILITY_COUNT +======================= + +Currently not implemented. + + +.. _DTV-FE-CAPABILITY: + +DTV_FE_CAPABILITY +================= + +Currently not implemented. + + +.. _DTV-DELIVERY-SYSTEM: + +DTV_DELIVERY_SYSTEM +=================== + +Specifies the type of Delivery system + + +.. _fe-delivery-system-t: + +fe_delivery_system type +----------------------- + +Possible values: + + +.. _fe-delivery-system: + +.. flat-table:: enum fe_delivery_system + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _SYS-UNDEFINED: + + ``SYS_UNDEFINED`` + + - Undefined standard. Generally, indicates an error + + - .. row 3 + + - .. _SYS-DVBC-ANNEX-A: + + ``SYS_DVBC_ANNEX_A`` + + - Cable TV: DVB-C following ITU-T J.83 Annex A spec + + - .. row 4 + + - .. _SYS-DVBC-ANNEX-B: + + ``SYS_DVBC_ANNEX_B`` + + - Cable TV: DVB-C following ITU-T J.83 Annex B spec (ClearQAM) + + - .. row 5 + + - .. _SYS-DVBC-ANNEX-C: + + ``SYS_DVBC_ANNEX_C`` + + - Cable TV: DVB-C following ITU-T J.83 Annex C spec + + - .. row 6 + + - .. _SYS-ISDBC: + + ``SYS_ISDBC`` + + - Cable TV: ISDB-C (no drivers yet) + + - .. row 7 + + - .. _SYS-DVBT: + + ``SYS_DVBT`` + + - Terrestral TV: DVB-T + + - .. row 8 + + - .. _SYS-DVBT2: + + ``SYS_DVBT2`` + + - Terrestral TV: DVB-T2 + + - .. row 9 + + - .. _SYS-ISDBT: + + ``SYS_ISDBT`` + + - Terrestral TV: ISDB-T + + - .. row 10 + + - .. _SYS-ATSC: + + ``SYS_ATSC`` + + - Terrestral TV: ATSC + + - .. row 11 + + - .. _SYS-ATSCMH: + + ``SYS_ATSCMH`` + + - Terrestral TV (mobile): ATSC-M/H + + - .. row 12 + + - .. _SYS-DTMB: + + ``SYS_DTMB`` + + - Terrestrial TV: DTMB + + - .. row 13 + + - .. _SYS-DVBS: + + ``SYS_DVBS`` + + - Satellite TV: DVB-S + + - .. row 14 + + - .. _SYS-DVBS2: + + ``SYS_DVBS2`` + + - Satellite TV: DVB-S2 + + - .. row 15 + + - .. _SYS-TURBO: + + ``SYS_TURBO`` + + - Satellite TV: DVB-S Turbo + + - .. row 16 + + - .. _SYS-ISDBS: + + ``SYS_ISDBS`` + + - Satellite TV: ISDB-S + + - .. row 17 + + - .. _SYS-DAB: + + ``SYS_DAB`` + + - Digital audio: DAB (not fully supported) + + - .. row 18 + + - .. _SYS-DSS: + + ``SYS_DSS`` + + - Satellite TV:"DSS (not fully supported) + + - .. row 19 + + - .. _SYS-CMMB: + + ``SYS_CMMB`` + + - Terrestral TV (mobile):CMMB (not fully supported) + + - .. row 20 + + - .. _SYS-DVBH: + + ``SYS_DVBH`` + + - Terrestral TV (mobile): DVB-H (standard deprecated) + + + +.. _DTV-ISDBT-PARTIAL-RECEPTION: + +DTV_ISDBT_PARTIAL_RECEPTION +=========================== + +If ``DTV_ISDBT_SOUND_BROADCASTING`` is '0' this bit-field represents +whether the channel is in partial reception mode or not. + +If '1' ``DTV_ISDBT_LAYERA_*`` values are assigned to the center segment +and ``DTV_ISDBT_LAYERA_SEGMENT_COUNT`` has to be '1'. + +If in addition ``DTV_ISDBT_SOUND_BROADCASTING`` is '1' +``DTV_ISDBT_PARTIAL_RECEPTION`` represents whether this ISDB-Tsb channel +is consisting of one segment and layer or three segments and two layers. + +Possible values: 0, 1, -1 (AUTO) + + +.. _DTV-ISDBT-SOUND-BROADCASTING: + +DTV_ISDBT_SOUND_BROADCASTING +============================ + +This field represents whether the other DTV_ISDBT_*-parameters are +referring to an ISDB-T and an ISDB-Tsb channel. (See also +``DTV_ISDBT_PARTIAL_RECEPTION``). + +Possible values: 0, 1, -1 (AUTO) + + +.. _DTV-ISDBT-SB-SUBCHANNEL-ID: + +DTV_ISDBT_SB_SUBCHANNEL_ID +========================== + +This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'. + +(Note of the author: This might not be the correct description of the +``SUBCHANNEL-ID`` in all details, but it is my understanding of the +technical background needed to program a device) + +An ISDB-Tsb channel (1 or 3 segments) can be broadcasted alone or in a +set of connected ISDB-Tsb channels. In this set of channels every +channel can be received independently. The number of connected ISDB-Tsb +segment can vary, e.g. depending on the frequency spectrum bandwidth +available. + +Example: Assume 8 ISDB-Tsb connected segments are broadcasted. The +broadcaster has several possibilities to put those channels in the air: +Assuming a normal 13-segment ISDB-T spectrum he can align the 8 segments +from position 1-8 to 5-13 or anything in between. + +The underlying layer of segments are subchannels: each segment is +consisting of several subchannels with a predefined IDs. A sub-channel +is used to help the demodulator to synchronize on the channel. + +An ISDB-T channel is always centered over all sub-channels. As for the +example above, in ISDB-Tsb it is no longer as simple as that. + +``The DTV_ISDBT_SB_SUBCHANNEL_ID`` parameter is used to give the +sub-channel ID of the segment to be demodulated. + +Possible values: 0 .. 41, -1 (AUTO) + + +.. _DTV-ISDBT-SB-SEGMENT-IDX: + +DTV_ISDBT_SB_SEGMENT_IDX +======================== + +This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'. + +``DTV_ISDBT_SB_SEGMENT_IDX`` gives the index of the segment to be +demodulated for an ISDB-Tsb channel where several of them are +transmitted in the connected manner. + +Possible values: 0 .. ``DTV_ISDBT_SB_SEGMENT_COUNT`` - 1 + +Note: This value cannot be determined by an automatic channel search. + + +.. _DTV-ISDBT-SB-SEGMENT-COUNT: + +DTV_ISDBT_SB_SEGMENT_COUNT +========================== + +This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'. + +``DTV_ISDBT_SB_SEGMENT_COUNT`` gives the total count of connected +ISDB-Tsb channels. + +Possible values: 1 .. 13 + +Note: This value cannot be determined by an automatic channel search. + + +.. _isdb-hierq-layers: + +DTV-ISDBT-LAYER[A-C] parameters +=============================== + +ISDB-T channels can be coded hierarchically. As opposed to DVB-T in +ISDB-T hierarchical layers can be decoded simultaneously. For that +reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders. + +ISDB-T has 3 hierarchical layers which each can use a part of the +available segments. The total number of segments over all layers has to +13 in ISDB-T. + +There are 3 parameter sets, for Layers A, B and C. + + +.. _DTV-ISDBT-LAYER-ENABLED: + +DTV_ISDBT_LAYER_ENABLED +----------------------- + +Hierarchical reception in ISDB-T is achieved by enabling or disabling +layers in the decoding process. Setting all bits of +``DTV_ISDBT_LAYER_ENABLED`` to '1' forces all layers (if applicable) to +be demodulated. This is the default. + +If the channel is in the partial reception mode +(``DTV_ISDBT_PARTIAL_RECEPTION`` = 1) the central segment can be decoded +independently of the other 12 segments. In that mode layer A has to have +a ``SEGMENT_COUNT`` of 1. + +In ISDB-Tsb only layer A is used, it can be 1 or 3 in ISDB-Tsb according +to ``DTV_ISDBT_PARTIAL_RECEPTION``. ``SEGMENT_COUNT`` must be filled +accordingly. + +Only the values of the first 3 bits are used. Other bits will be silently ignored: + +``DTV_ISDBT_LAYER_ENABLED`` bit 0: layer A enabled + +``DTV_ISDBT_LAYER_ENABLED`` bit 1: layer B enabled + +``DTV_ISDBT_LAYER_ENABLED`` bit 2: layer C enabled + +``DTV_ISDBT_LAYER_ENABLED`` bits 3-31: unused + + +.. _DTV-ISDBT-LAYER-FEC: + +DTV_ISDBT_LAYER[A-C]_FEC +------------------------ + +Possible values: ``FEC_AUTO``, ``FEC_1_2``, ``FEC_2_3``, ``FEC_3_4``, +``FEC_5_6``, ``FEC_7_8`` + + +.. _DTV-ISDBT-LAYER-MODULATION: + +DTV_ISDBT_LAYER[A-C]_MODULATION +------------------------------- + +Possible values: ``QAM_AUTO``, QP\ ``SK, QAM_16``, ``QAM_64``, ``DQPSK`` + +Note: If layer C is ``DQPSK`` layer B has to be ``DQPSK``. If layer B is +``DQPSK`` and ``DTV_ISDBT_PARTIAL_RECEPTION``\ =0 layer has to be +``DQPSK``. + + +.. _DTV-ISDBT-LAYER-SEGMENT-COUNT: + +DTV_ISDBT_LAYER[A-C]_SEGMENT_COUNT +---------------------------------- + +Possible values: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, -1 (AUTO) + +Note: Truth table for ``DTV_ISDBT_SOUND_BROADCASTING`` and +``DTV_ISDBT_PARTIAL_RECEPTION`` and ``LAYER[A-C]_SEGMENT_COUNT`` + + +.. _isdbt-layer_seg-cnt-table: + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - PR + + - SB + + - Layer A width + + - Layer B width + + - Layer C width + + - total width + + - .. row 2 + + - 0 + + - 0 + + - 1 .. 13 + + - 1 .. 13 + + - 1 .. 13 + + - 13 + + - .. row 3 + + - 1 + + - 0 + + - 1 + + - 1 .. 13 + + - 1 .. 13 + + - 13 + + - .. row 4 + + - 0 + + - 1 + + - 1 + + - 0 + + - 0 + + - 1 + + - .. row 5 + + - 1 + + - 1 + + - 1 + + - 2 + + - 0 + + - 13 + + + +.. _DTV-ISDBT-LAYER-TIME-INTERLEAVING: + +DTV_ISDBT_LAYER[A-C]_TIME_INTERLEAVING +-------------------------------------- + +Valid values: 0, 1, 2, 4, -1 (AUTO) + +when DTV_ISDBT_SOUND_BROADCASTING is active, value 8 is also valid. + +Note: The real time interleaving length depends on the mode (fft-size). +The values here are referring to what can be found in the +TMCC-structure, as shown in the table below. + + +.. _isdbt-layer-interleaving-table: + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``DTV_ISDBT_LAYER[A-C]_TIME_INTERLEAVING`` + + - Mode 1 (2K FFT) + + - Mode 2 (4K FFT) + + - Mode 3 (8K FFT) + + - .. row 2 + + - 0 + + - 0 + + - 0 + + - 0 + + - .. row 3 + + - 1 + + - 4 + + - 2 + + - 1 + + - .. row 4 + + - 2 + + - 8 + + - 4 + + - 2 + + - .. row 5 + + - 4 + + - 16 + + - 8 + + - 4 + + + +.. _DTV-ATSCMH-FIC-VER: + +DTV_ATSCMH_FIC_VER +------------------ + +Version number of the FIC (Fast Information Channel) signaling data. + +FIC is used for relaying information to allow rapid service acquisition +by the receiver. + +Possible values: 0, 1, 2, 3, ..., 30, 31 + + +.. _DTV-ATSCMH-PARADE-ID: + +DTV_ATSCMH_PARADE_ID +-------------------- + +Parade identification number + +A parade is a collection of up to eight MH groups, conveying one or two +ensembles. + +Possible values: 0, 1, 2, 3, ..., 126, 127 + + +.. _DTV-ATSCMH-NOG: + +DTV_ATSCMH_NOG +-------------- + +Number of MH groups per MH subframe for a designated parade. + +Possible values: 1, 2, 3, 4, 5, 6, 7, 8 + + +.. _DTV-ATSCMH-TNOG: + +DTV_ATSCMH_TNOG +--------------- + +Total number of MH groups including all MH groups belonging to all MH +parades in one MH subframe. + +Possible values: 0, 1, 2, 3, ..., 30, 31 + + +.. _DTV-ATSCMH-SGN: + +DTV_ATSCMH_SGN +-------------- + +Start group number. + +Possible values: 0, 1, 2, 3, ..., 14, 15 + + +.. _DTV-ATSCMH-PRC: + +DTV_ATSCMH_PRC +-------------- + +Parade repetition cycle. + +Possible values: 1, 2, 3, 4, 5, 6, 7, 8 + + +.. _DTV-ATSCMH-RS-FRAME-MODE: + +DTV_ATSCMH_RS_FRAME_MODE +------------------------ + +Reed Solomon (RS) frame mode. + +Possible values are: + + +.. _atscmh-rs-frame-mode: + +.. flat-table:: enum atscmh_rs_frame_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ATSCMH-RSFRAME-PRI-ONLY: + + ``ATSCMH_RSFRAME_PRI_ONLY`` + + - Single Frame: There is only a primary RS Frame for all Group + Regions. + + - .. row 3 + + - .. _ATSCMH-RSFRAME-PRI-SEC: + + ``ATSCMH_RSFRAME_PRI_SEC`` + + - Dual Frame: There are two separate RS Frames: Primary RS Frame for + Group Region A and B and Secondary RS Frame for Group Region C and + D. + + + +.. _DTV-ATSCMH-RS-FRAME-ENSEMBLE: + +DTV_ATSCMH_RS_FRAME_ENSEMBLE +---------------------------- + +Reed Solomon(RS) frame ensemble. + +Possible values are: + + +.. _atscmh-rs-frame-ensemble: + +.. flat-table:: enum atscmh_rs_frame_ensemble + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ATSCMH-RSFRAME-ENS-PRI: + + ``ATSCMH_RSFRAME_ENS_PRI`` + + - Primary Ensemble. + + - .. row 3 + + - .. _ATSCMH-RSFRAME-ENS-SEC: + + ``AATSCMH_RSFRAME_PRI_SEC`` + + - Secondary Ensemble. + + - .. row 4 + + - .. _ATSCMH-RSFRAME-RES: + + ``AATSCMH_RSFRAME_RES`` + + - Reserved. Shouldn't be used. + + + +.. _DTV-ATSCMH-RS-CODE-MODE-PRI: + +DTV_ATSCMH_RS_CODE_MODE_PRI +--------------------------- + +Reed Solomon (RS) code mode (primary). + +Possible values are: + + +.. _atscmh-rs-code-mode: + +.. flat-table:: enum atscmh_rs_code_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ATSCMH-RSCODE-211-187: + + ``ATSCMH_RSCODE_211_187`` + + - Reed Solomon code (211,187). + + - .. row 3 + + - .. _ATSCMH-RSCODE-223-187: + + ``ATSCMH_RSCODE_223_187`` + + - Reed Solomon code (223,187). + + - .. row 4 + + - .. _ATSCMH-RSCODE-235-187: + + ``ATSCMH_RSCODE_235_187`` + + - Reed Solomon code (235,187). + + - .. row 5 + + - .. _ATSCMH-RSCODE-RES: + + ``ATSCMH_RSCODE_RES`` + + - Reserved. Shouldn't be used. + + + +.. _DTV-ATSCMH-RS-CODE-MODE-SEC: + +DTV_ATSCMH_RS_CODE_MODE_SEC +--------------------------- + +Reed Solomon (RS) code mode (secondary). + +Possible values are the same as documented on enum +:ref:`atscmh_rs_code_mode `: + + +.. _DTV-ATSCMH-SCCC-BLOCK-MODE: + +DTV_ATSCMH_SCCC_BLOCK_MODE +-------------------------- + +Series Concatenated Convolutional Code Block Mode. + +Possible values are: + + +.. _atscmh-sccc-block-mode: + +.. flat-table:: enum atscmh_scc_block_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ATSCMH-SCCC-BLK-SEP: + + ``ATSCMH_SCCC_BLK_SEP`` + + - Separate SCCC: the SCCC outer code mode shall be set independently + for each Group Region (A, B, C, D) + + - .. row 3 + + - .. _ATSCMH-SCCC-BLK-COMB: + + ``ATSCMH_SCCC_BLK_COMB`` + + - Combined SCCC: all four Regions shall have the same SCCC outer + code mode. + + - .. row 4 + + - .. _ATSCMH-SCCC-BLK-RES: + + ``ATSCMH_SCCC_BLK_RES`` + + - Reserved. Shouldn't be used. + + + +.. _DTV-ATSCMH-SCCC-CODE-MODE-A: + +DTV_ATSCMH_SCCC_CODE_MODE_A +--------------------------- + +Series Concatenated Convolutional Code Rate. + +Possible values are: + + +.. _atscmh-sccc-code-mode: + +.. flat-table:: enum atscmh_sccc_code_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _ATSCMH-SCCC-CODE-HLF: + + ``ATSCMH_SCCC_CODE_HLF`` + + - The outer code rate of a SCCC Block is 1/2 rate. + + - .. row 3 + + - .. _ATSCMH-SCCC-CODE-QTR: + + ``ATSCMH_SCCC_CODE_QTR`` + + - The outer code rate of a SCCC Block is 1/4 rate. + + - .. row 4 + + - .. _ATSCMH-SCCC-CODE-RES: + + ``ATSCMH_SCCC_CODE_RES`` + + - to be documented. + + + +.. _DTV-ATSCMH-SCCC-CODE-MODE-B: + +DTV_ATSCMH_SCCC_CODE_MODE_B +--------------------------- + +Series Concatenated Convolutional Code Rate. + +Possible values are the same as documented on enum +:ref:`atscmh_sccc_code_mode `. + + +.. _DTV-ATSCMH-SCCC-CODE-MODE-C: + +DTV_ATSCMH_SCCC_CODE_MODE_C +--------------------------- + +Series Concatenated Convolutional Code Rate. + +Possible values are the same as documented on enum +:ref:`atscmh_sccc_code_mode `. + + +.. _DTV-ATSCMH-SCCC-CODE-MODE-D: + +DTV_ATSCMH_SCCC_CODE_MODE_D +--------------------------- + +Series Concatenated Convolutional Code Rate. + +Possible values are the same as documented on enum +:ref:`atscmh_sccc_code_mode `. + + +.. _DTV-API-VERSION: + +DTV_API_VERSION +=============== + +Returns the major/minor version of the DVB API + + +.. _DTV-CODE-RATE-HP: + +DTV_CODE_RATE_HP +================ + +Used on terrestrial transmissions. The acceptable values are the ones +described at :ref:`fe_transmit_mode_t `. + + +.. _DTV-CODE-RATE-LP: + +DTV_CODE_RATE_LP +================ + +Used on terrestrial transmissions. The acceptable values are the ones +described at :ref:`fe_transmit_mode_t `. + + +.. _DTV-GUARD-INTERVAL: + +DTV_GUARD_INTERVAL +================== + +Possible values are: + + +.. _fe-guard-interval-t: + +Modulation guard interval +------------------------- + + +.. _fe-guard-interval: + +.. flat-table:: enum fe_guard_interval + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _GUARD-INTERVAL-AUTO: + + ``GUARD_INTERVAL_AUTO`` + + - Autodetect the guard interval + + - .. row 3 + + - .. _GUARD-INTERVAL-1-128: + + ``GUARD_INTERVAL_1_128`` + + - Guard interval 1/128 + + - .. row 4 + + - .. _GUARD-INTERVAL-1-32: + + ``GUARD_INTERVAL_1_32`` + + - Guard interval 1/32 + + - .. row 5 + + - .. _GUARD-INTERVAL-1-16: + + ``GUARD_INTERVAL_1_16`` + + - Guard interval 1/16 + + - .. row 6 + + - .. _GUARD-INTERVAL-1-8: + + ``GUARD_INTERVAL_1_8`` + + - Guard interval 1/8 + + - .. row 7 + + - .. _GUARD-INTERVAL-1-4: + + ``GUARD_INTERVAL_1_4`` + + - Guard interval 1/4 + + - .. row 8 + + - .. _GUARD-INTERVAL-19-128: + + ``GUARD_INTERVAL_19_128`` + + - Guard interval 19/128 + + - .. row 9 + + - .. _GUARD-INTERVAL-19-256: + + ``GUARD_INTERVAL_19_256`` + + - Guard interval 19/256 + + - .. row 10 + + - .. _GUARD-INTERVAL-PN420: + + ``GUARD_INTERVAL_PN420`` + + - PN length 420 (1/4) + + - .. row 11 + + - .. _GUARD-INTERVAL-PN595: + + ``GUARD_INTERVAL_PN595`` + + - PN length 595 (1/6) + + - .. row 12 + + - .. _GUARD-INTERVAL-PN945: + + ``GUARD_INTERVAL_PN945`` + + - PN length 945 (1/9) + + +Notes: + +1) If ``DTV_GUARD_INTERVAL`` is set the ``GUARD_INTERVAL_AUTO`` the +hardware will try to find the correct guard interval (if capable) and +will use TMCC to fill in the missing parameters. + +2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at +present + +3) DTMB specifies PN420, PN595 and PN945. + + +.. _DTV-TRANSMISSION-MODE: + +DTV_TRANSMISSION_MODE +===================== + +Specifies the number of carriers used by the standard. This is used only +on OFTM-based standards, e. g. DVB-T/T2, ISDB-T, DTMB + + +.. _fe-transmit-mode-t: + +enum fe_transmit_mode: Number of carriers per channel +----------------------------------------------------- + + +.. _fe-transmit-mode: + +.. flat-table:: enum fe_transmit_mode + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _TRANSMISSION-MODE-AUTO: + + ``TRANSMISSION_MODE_AUTO`` + + - Autodetect transmission mode. The hardware will try to find the + correct FFT-size (if capable) to fill in the missing parameters. + + - .. row 3 + + - .. _TRANSMISSION-MODE-1K: + + ``TRANSMISSION_MODE_1K`` + + - Transmission mode 1K + + - .. row 4 + + - .. _TRANSMISSION-MODE-2K: + + ``TRANSMISSION_MODE_2K`` + + - Transmission mode 2K + + - .. row 5 + + - .. _TRANSMISSION-MODE-8K: + + ``TRANSMISSION_MODE_8K`` + + - Transmission mode 8K + + - .. row 6 + + - .. _TRANSMISSION-MODE-4K: + + ``TRANSMISSION_MODE_4K`` + + - Transmission mode 4K + + - .. row 7 + + - .. _TRANSMISSION-MODE-16K: + + ``TRANSMISSION_MODE_16K`` + + - Transmission mode 16K + + - .. row 8 + + - .. _TRANSMISSION-MODE-32K: + + ``TRANSMISSION_MODE_32K`` + + - Transmission mode 32K + + - .. row 9 + + - .. _TRANSMISSION-MODE-C1: + + ``TRANSMISSION_MODE_C1`` + + - Single Carrier (C=1) transmission mode (DTMB) + + - .. row 10 + + - .. _TRANSMISSION-MODE-C3780: + + ``TRANSMISSION_MODE_C3780`` + + - Multi Carrier (C=3780) transmission mode (DTMB) + + +Notes: + +1) ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called +'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K + +2) If ``DTV_TRANSMISSION_MODE`` is set the ``TRANSMISSION_MODE_AUTO`` +the hardware will try to find the correct FFT-size (if capable) and will +use TMCC to fill in the missing parameters. + +3) DVB-T specifies 2K and 8K as valid sizes. + +4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. + +5) DTMB specifies C1 and C3780. + + +.. _DTV-HIERARCHY: + +DTV_HIERARCHY +============= + +Frontend hierarchy + + +.. _fe-hierarchy-t: + +Frontend hierarchy +------------------ + + +.. _fe-hierarchy: + +.. flat-table:: enum fe_hierarchy + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _HIERARCHY-NONE: + + ``HIERARCHY_NONE`` + + - No hierarchy + + - .. row 3 + + - .. _HIERARCHY-AUTO: + + ``HIERARCHY_AUTO`` + + - Autodetect hierarchy (if supported) + + - .. row 4 + + - .. _HIERARCHY-1: + + ``HIERARCHY_1`` + + - Hierarchy 1 + + - .. row 5 + + - .. _HIERARCHY-2: + + ``HIERARCHY_2`` + + - Hierarchy 2 + + - .. row 6 + + - .. _HIERARCHY-4: + + ``HIERARCHY_4`` + + - Hierarchy 4 + + + +.. _DTV-STREAM-ID: + +DTV_STREAM_ID +============= + +DVB-S2, DVB-T2 and ISDB-S support the transmission of several streams on +a single transport stream. This property enables the DVB driver to +handle substream filtering, when supported by the hardware. By default, +substream filtering is disabled. + +For DVB-S2 and DVB-T2, the valid substream id range is from 0 to 255. + +For ISDB, the valid substream id range is from 1 to 65535. + +To disable it, you should use the special macro NO_STREAM_ID_FILTER. + +Note: any value outside the id range also disables filtering. + + +.. _DTV-DVBT2-PLP-ID-LEGACY: + +DTV_DVBT2_PLP_ID_LEGACY +======================= + +Obsolete, replaced with DTV_STREAM_ID. + + +.. _DTV-ENUM-DELSYS: + +DTV_ENUM_DELSYS +=============== + +A Multi standard frontend needs to advertise the delivery systems +provided. Applications need to enumerate the provided delivery systems, +before using any other operation with the frontend. Prior to it's +introduction, FE_GET_INFO was used to determine a frontend type. A +frontend which provides more than a single delivery system, +FE_GET_INFO doesn't help much. Applications which intends to use a +multistandard frontend must enumerate the delivery systems associated +with it, rather than trying to use FE_GET_INFO. In the case of a +legacy frontend, the result is just the same as with FE_GET_INFO, but +in a more structured format + + +.. _DTV-INTERLEAVING: + +DTV_INTERLEAVING +================ + +Time interleaving to be used. Currently, used only on DTMB. + + +.. _fe-interleaving: + +.. flat-table:: enum fe_interleaving + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - .. _INTERLEAVING-NONE: + + ``INTERLEAVING_NONE`` + + - No interleaving. + + - .. row 3 + + - .. _INTERLEAVING-AUTO: + + ``INTERLEAVING_AUTO`` + + - Auto-detect interleaving. + + - .. row 4 + + - .. _INTERLEAVING-240: + + ``INTERLEAVING_240`` + + - Interleaving of 240 symbols. + + - .. row 5 + + - .. _INTERLEAVING-720: + + ``INTERLEAVING_720`` + + - Interleaving of 720 symbols. + + + +.. _DTV-LNA: + +DTV_LNA +======= + +Low-noise amplifier. + +Hardware might offer controllable LNA which can be set manually using +that parameter. Usually LNA could be found only from terrestrial devices +if at all. + +Possible values: 0, 1, LNA_AUTO + +0, LNA off + +1, LNA on + +use the special macro LNA_AUTO to set LNA auto diff --git a/Documentation/media/uapi/dvb/frontend-property-cable-systems.rst b/Documentation/media/uapi/dvb/frontend-property-cable-systems.rst new file mode 100644 index 0000000000000000000000000000000000000000..bf2328627af5f865cc365e6b8fe7b0d740769ceb --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend-property-cable-systems.rst @@ -0,0 +1,75 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend-property-cable-systems: + +***************************************** +Properties used on cable delivery systems +***************************************** + + +.. _dvbc-params: + +DVB-C delivery system +===================== + +The DVB-C Annex-A is the widely used cable standard. Transmission uses +QAM modulation. + +The DVB-C Annex-C is optimized for 6MHz, and is used in Japan. It +supports a subset of the Annex A modulation types, and a roll-off of +0.13, instead of 0.15 + +The following parameters are valid for DVB-C Annex A/C: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_SYMBOL_RATE ` + +- :ref:`DTV_INNER_FEC ` + +- :ref:`DTV_LNA ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _dvbc-annex-b-params: + +DVB-C Annex B delivery system +============================= + +The DVB-C Annex-B is only used on a few Countries like the United +States. + +The following parameters are valid for DVB-C Annex B: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_LNA ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. diff --git a/Documentation/media/uapi/dvb/frontend-property-satellite-systems.rst b/Documentation/media/uapi/dvb/frontend-property-satellite-systems.rst new file mode 100644 index 0000000000000000000000000000000000000000..1f40399c68fffe1a911301b5c1639e5ce0bd8569 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend-property-satellite-systems.rst @@ -0,0 +1,103 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend-property-satellite-systems: + +********************************************* +Properties used on satellite delivery systems +********************************************* + + +.. _dvbs-params: + +DVB-S delivery system +===================== + +The following parameters are valid for DVB-S: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_SYMBOL_RATE ` + +- :ref:`DTV_INNER_FEC ` + +- :ref:`DTV_VOLTAGE ` + +- :ref:`DTV_TONE ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + +Future implementations might add those two missing parameters: + +- :ref:`DTV_DISEQC_MASTER ` + +- :ref:`DTV_DISEQC_SLAVE_REPLY ` + + +.. _dvbs2-params: + +DVB-S2 delivery system +====================== + +In addition to all parameters valid for DVB-S, DVB-S2 supports the +following parameters: + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_PILOT ` + +- :ref:`DTV_ROLLOFF ` + +- :ref:`DTV_STREAM_ID ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _turbo-params: + +Turbo code delivery system +========================== + +In addition to all parameters valid for DVB-S, turbo code supports the +following parameters: + +- :ref:`DTV_MODULATION ` + + +.. _isdbs-params: + +ISDB-S delivery system +====================== + +The following parameters are valid for ISDB-S: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_SYMBOL_RATE ` + +- :ref:`DTV_INNER_FEC ` + +- :ref:`DTV_VOLTAGE ` + +- :ref:`DTV_STREAM_ID ` diff --git a/Documentation/media/uapi/dvb/frontend-property-terrestrial-systems.rst b/Documentation/media/uapi/dvb/frontend-property-terrestrial-systems.rst new file mode 100644 index 0000000000000000000000000000000000000000..dbc717cad9eebad5f237d1b30c8db850059849b1 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend-property-terrestrial-systems.rst @@ -0,0 +1,294 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend-property-terrestrial-systems: + +*********************************************** +Properties used on terrestrial delivery systems +*********************************************** + + +.. _dvbt-params: + +DVB-T delivery system +===================== + +The following parameters are valid for DVB-T: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_CODE_RATE_HP ` + +- :ref:`DTV_CODE_RATE_LP ` + +- :ref:`DTV_GUARD_INTERVAL ` + +- :ref:`DTV_TRANSMISSION_MODE ` + +- :ref:`DTV_HIERARCHY ` + +- :ref:`DTV_LNA ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _dvbt2-params: + +DVB-T2 delivery system +====================== + +DVB-T2 support is currently in the early stages of development, so +expect that this section maygrow and become more detailed with time. + +The following parameters are valid for DVB-T2: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_CODE_RATE_HP ` + +- :ref:`DTV_CODE_RATE_LP ` + +- :ref:`DTV_GUARD_INTERVAL ` + +- :ref:`DTV_TRANSMISSION_MODE ` + +- :ref:`DTV_HIERARCHY ` + +- :ref:`DTV_STREAM_ID ` + +- :ref:`DTV_LNA ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _isdbt: + +ISDB-T delivery system +====================== + +This ISDB-T/ISDB-Tsb API extension should reflect all information needed +to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible that some +very sophisticated devices won't need certain parameters to tune. + +The information given here should help application writers to know how +to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API. + +The details given here about ISDB-T and ISDB-Tsb are just enough to +basically show the dependencies between the needed parameter values, but +surely some information is left out. For more detailed information see +the following documents: + +ARIB STD-B31 - "Transmission System for Digital Terrestrial Television +Broadcasting" and + +ARIB TR-B14 - "Operational Guidelines for Digital Terrestrial Television +Broadcasting". + +In order to understand the ISDB specific parameters, one has to have +some knowledge the channel structure in ISDB-T and ISDB-Tsb. I.e. it has +to be known to the reader that an ISDB-T channel consists of 13 +segments, that it can have up to 3 layer sharing those segments, and +things like that. + +The following parameters are valid for ISDB-T: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_GUARD_INTERVAL ` + +- :ref:`DTV_TRANSMISSION_MODE ` + +- :ref:`DTV_ISDBT_LAYER_ENABLED ` + +- :ref:`DTV_ISDBT_PARTIAL_RECEPTION ` + +- :ref:`DTV_ISDBT_SOUND_BROADCASTING ` + +- :ref:`DTV_ISDBT_SB_SUBCHANNEL_ID ` + +- :ref:`DTV_ISDBT_SB_SEGMENT_IDX ` + +- :ref:`DTV_ISDBT_SB_SEGMENT_COUNT ` + +- :ref:`DTV_ISDBT_LAYERA_FEC ` + +- :ref:`DTV_ISDBT_LAYERA_MODULATION ` + +- :ref:`DTV_ISDBT_LAYERA_SEGMENT_COUNT ` + +- :ref:`DTV_ISDBT_LAYERA_TIME_INTERLEAVING ` + +- :ref:`DTV_ISDBT_LAYERB_FEC ` + +- :ref:`DTV_ISDBT_LAYERB_MODULATION ` + +- :ref:`DTV_ISDBT_LAYERB_SEGMENT_COUNT ` + +- :ref:`DTV_ISDBT_LAYERB_TIME_INTERLEAVING ` + +- :ref:`DTV_ISDBT_LAYERC_FEC ` + +- :ref:`DTV_ISDBT_LAYERC_MODULATION ` + +- :ref:`DTV_ISDBT_LAYERC_SEGMENT_COUNT ` + +- :ref:`DTV_ISDBT_LAYERC_TIME_INTERLEAVING ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _atsc-params: + +ATSC delivery system +==================== + +The following parameters are valid for ATSC: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _atscmh-params: + +ATSC-MH delivery system +======================= + +The following parameters are valid for ATSC-MH: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +- :ref:`DTV_ATSCMH_FIC_VER ` + +- :ref:`DTV_ATSCMH_PARADE_ID ` + +- :ref:`DTV_ATSCMH_NOG ` + +- :ref:`DTV_ATSCMH_TNOG ` + +- :ref:`DTV_ATSCMH_SGN ` + +- :ref:`DTV_ATSCMH_PRC ` + +- :ref:`DTV_ATSCMH_RS_FRAME_MODE ` + +- :ref:`DTV_ATSCMH_RS_FRAME_ENSEMBLE ` + +- :ref:`DTV_ATSCMH_RS_CODE_MODE_PRI ` + +- :ref:`DTV_ATSCMH_RS_CODE_MODE_SEC ` + +- :ref:`DTV_ATSCMH_SCCC_BLOCK_MODE ` + +- :ref:`DTV_ATSCMH_SCCC_CODE_MODE_A ` + +- :ref:`DTV_ATSCMH_SCCC_CODE_MODE_B ` + +- :ref:`DTV_ATSCMH_SCCC_CODE_MODE_C ` + +- :ref:`DTV_ATSCMH_SCCC_CODE_MODE_D ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. + + +.. _dtmb-params: + +DTMB delivery system +==================== + +The following parameters are valid for DTMB: + +- :ref:`DTV_API_VERSION ` + +- :ref:`DTV_DELIVERY_SYSTEM ` + +- :ref:`DTV_TUNE ` + +- :ref:`DTV_CLEAR ` + +- :ref:`DTV_FREQUENCY ` + +- :ref:`DTV_MODULATION ` + +- :ref:`DTV_BANDWIDTH_HZ ` + +- :ref:`DTV_INVERSION ` + +- :ref:`DTV_INNER_FEC ` + +- :ref:`DTV_GUARD_INTERVAL ` + +- :ref:`DTV_TRANSMISSION_MODE ` + +- :ref:`DTV_INTERLEAVING ` + +- :ref:`DTV_LNA ` + +In addition, the :ref:`DTV QoS statistics ` +are also valid. diff --git a/Documentation/media/uapi/dvb/frontend-stat-properties.rst b/Documentation/media/uapi/dvb/frontend-stat-properties.rst new file mode 100644 index 0000000000000000000000000000000000000000..0fc4aaa304ff351462088a06ad8edcd6831adcee --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend-stat-properties.rst @@ -0,0 +1,245 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend-stat-properties: + +****************************** +Frontend statistics indicators +****************************** + +The values are returned via ``dtv_property.stat``. If the property is +supported, ``dtv_property.stat.len`` is bigger than zero. + +For most delivery systems, ``dtv_property.stat.len`` will be 1 if the +stats is supported, and the properties will return a single value for +each parameter. + +It should be noted, however, that new OFDM delivery systems like ISDB +can use different modulation types for each group of carriers. On such +standards, up to 3 groups of statistics can be provided, and +``dtv_property.stat.len`` is updated to reflect the "global" metrics, +plus one metric per each carrier group (called "layer" on ISDB). + +So, in order to be consistent with other delivery systems, the first +value at :ref:`dtv_property.stat.dtv_stats ` array refers +to the global metric. The other elements of the array represent each +layer, starting from layer A(index 1), layer B (index 2) and so on. + +The number of filled elements are stored at ``dtv_property.stat.len``. + +Each element of the ``dtv_property.stat.dtv_stats`` array consists on +two elements: + +- ``svalue`` or ``uvalue``, where ``svalue`` is for signed values of + the measure (dB measures) and ``uvalue`` is for unsigned values + (counters, relative scale) + +- ``scale`` - Scale for the value. It can be: + + - ``FE_SCALE_NOT_AVAILABLE`` - The parameter is supported by the + frontend, but it was not possible to collect it (could be a + transitory or permanent condition) + + - ``FE_SCALE_DECIBEL`` - parameter is a signed value, measured in + 1/1000 dB + + - ``FE_SCALE_RELATIVE`` - parameter is a unsigned value, where 0 + means 0% and 65535 means 100%. + + - ``FE_SCALE_COUNTER`` - parameter is a unsigned value that counts + the occurrence of an event, like bit error, block error, or lapsed + time. + + +.. _DTV-STAT-SIGNAL-STRENGTH: + +DTV_STAT_SIGNAL_STRENGTH +======================== + +Indicates the signal strength level at the analog part of the tuner or +of the demod. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_DECIBEL`` - signal strength is in 0.001 dBm units, power + measured in miliwatts. This value is generally negative. + +- ``FE_SCALE_RELATIVE`` - The frontend provides a 0% to 100% + measurement for power (actually, 0 to 65535). + + +.. _DTV-STAT-CNR: + +DTV_STAT_CNR +============ + +Indicates the Signal to Noise ratio for the main carrier. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_DECIBEL`` - Signal/Noise ratio is in 0.001 dB units. + +- ``FE_SCALE_RELATIVE`` - The frontend provides a 0% to 100% + measurement for Signal/Noise (actually, 0 to 65535). + + +.. _DTV-STAT-PRE-ERROR-BIT-COUNT: + +DTV_STAT_PRE_ERROR_BIT_COUNT +============================ + +Measures the number of bit errors before the forward error correction +(FEC) on the inner coding block (before Viterbi, LDPC or other inner +code). + +This measure is taken during the same interval as +``DTV_STAT_PRE_TOTAL_BIT_COUNT``. + +In order to get the BER (Bit Error Rate) measurement, it should be +divided by +:ref:`DTV_STAT_PRE_TOTAL_BIT_COUNT `. + +This measurement is monotonically increased, as the frontend gets more +bit count measurements. The frontend may reset it when a +channel/transponder is tuned. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of error bits counted before the inner + coding. + + +.. _DTV-STAT-PRE-TOTAL-BIT-COUNT: + +DTV_STAT_PRE_TOTAL_BIT_COUNT +============================ + +Measures the amount of bits received before the inner code block, during +the same period as +:ref:`DTV_STAT_PRE_ERROR_BIT_COUNT ` +measurement was taken. + +It should be noted that this measurement can be smaller than the total +amount of bits on the transport stream, as the frontend may need to +manually restart the measurement, losing some data between each +measurement interval. + +This measurement is monotonically increased, as the frontend gets more +bit count measurements. The frontend may reset it when a +channel/transponder is tuned. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of bits counted while measuring + :ref:`DTV_STAT_PRE_ERROR_BIT_COUNT `. + + +.. _DTV-STAT-POST-ERROR-BIT-COUNT: + +DTV_STAT_POST_ERROR_BIT_COUNT +============================= + +Measures the number of bit errors after the forward error correction +(FEC) done by inner code block (after Viterbi, LDPC or other inner +code). + +This measure is taken during the same interval as +``DTV_STAT_POST_TOTAL_BIT_COUNT``. + +In order to get the BER (Bit Error Rate) measurement, it should be +divided by +:ref:`DTV_STAT_POST_TOTAL_BIT_COUNT `. + +This measurement is monotonically increased, as the frontend gets more +bit count measurements. The frontend may reset it when a +channel/transponder is tuned. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of error bits counted after the inner + coding. + + +.. _DTV-STAT-POST-TOTAL-BIT-COUNT: + +DTV_STAT_POST_TOTAL_BIT_COUNT +============================= + +Measures the amount of bits received after the inner coding, during the +same period as +:ref:`DTV_STAT_POST_ERROR_BIT_COUNT ` +measurement was taken. + +It should be noted that this measurement can be smaller than the total +amount of bits on the transport stream, as the frontend may need to +manually restart the measurement, losing some data between each +measurement interval. + +This measurement is monotonically increased, as the frontend gets more +bit count measurements. The frontend may reset it when a +channel/transponder is tuned. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of bits counted while measuring + :ref:`DTV_STAT_POST_ERROR_BIT_COUNT `. + + +.. _DTV-STAT-ERROR-BLOCK-COUNT: + +DTV_STAT_ERROR_BLOCK_COUNT +========================== + +Measures the number of block errors after the outer forward error +correction coding (after Reed-Solomon or other outer code). + +This measurement is monotonically increased, as the frontend gets more +bit count measurements. The frontend may reset it when a +channel/transponder is tuned. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of error blocks counted after the outer + coding. + + +.. _DTV-STAT-TOTAL-BLOCK-COUNT: + +DTV-STAT_TOTAL_BLOCK_COUNT +========================== + +Measures the total number of blocks received during the same period as +:ref:`DTV_STAT_ERROR_BLOCK_COUNT ` +measurement was taken. + +It can be used to calculate the PER indicator, by dividing +:ref:`DTV_STAT_ERROR_BLOCK_COUNT ` by +:ref:`DTV-STAT-TOTAL-BLOCK-COUNT`. + +Possible scales for this metric are: + +- ``FE_SCALE_NOT_AVAILABLE`` - it failed to measure it, or the + measurement was not complete yet. + +- ``FE_SCALE_COUNTER`` - Number of blocks counted while measuring + :ref:`DTV_STAT_ERROR_BLOCK_COUNT `. diff --git a/Documentation/media/uapi/dvb/frontend.rst b/Documentation/media/uapi/dvb/frontend.rst new file mode 100644 index 0000000000000000000000000000000000000000..48c5cd487ce7601b37ea31183b9fe3b8900cfa1a --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend.rst @@ -0,0 +1,51 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_frontend: + +################ +DVB Frontend API +################ +The DVB frontend API was designed to support three types of delivery +systems: + +- Terrestrial systems: DVB-T, DVB-T2, ATSC, ATSC M/H, ISDB-T, DVB-H, + DTMB, CMMB + +- Cable systems: DVB-C Annex A/C, ClearQAM (DVB-C Annex B), ISDB-C + +- Satellite systems: DVB-S, DVB-S2, DVB Turbo, ISDB-S, DSS + +The DVB frontend controls several sub-devices including: + +- Tuner + +- Digital TV demodulator + +- Low noise amplifier (LNA) + +- Satellite Equipment Control (SEC) hardware (only for Satellite). + +The frontend can be accessed through ``/dev/dvb/adapter?/frontend?``. +Data types and ioctl definitions can be accessed by including +``linux/dvb/frontend.h`` in your application. + +.. note:: Transmission via the internet (DVB-IP) is not yet handled by this + API but a future extension is possible. + +On Satellite systems, the API support for the Satellite Equipment +Control (SEC) allows to power control and to send/receive signals to +control the antenna subsystem, selecting the polarization and choosing +the Intermediate Frequency IF) of the Low Noise Block Converter Feed +Horn (LNBf). It supports the DiSEqC and V-SEC protocols. The DiSEqC +(digital SEC) specification is available at +`Eutelsat `__. + + +.. toctree:: + :maxdepth: 1 + + query-dvb-frontend-info + dvb-fe-read-status + dvbproperty + frontend_fcalls + frontend_legacy_dvbv3_api diff --git a/Documentation/media/uapi/dvb/frontend_f_close.rst b/Documentation/media/uapi/dvb/frontend_f_close.rst new file mode 100644 index 0000000000000000000000000000000000000000..5cce9262084c751f67797b1957b48b302a4bd355 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_f_close.rst @@ -0,0 +1,48 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_f_close: + +******************** +DVB frontend close() +******************** + +Name +==== + +fe-close - Close a frontend device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int close( int fd ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + + +Description +=========== + +This system call closes a previously opened front-end device. After +closing a front-end device, its corresponding hardware might be powered +down automatically. + + +Return Value +============ + +The function returns 0 on success, -1 on failure and the ``errno`` is +set appropriately. Possible error codes: + +EBADF + ``fd`` is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/frontend_f_open.rst b/Documentation/media/uapi/dvb/frontend_f_open.rst new file mode 100644 index 0000000000000000000000000000000000000000..e0c55345f524a13d9fe2cbaea3fcd5a80c38ea64 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_f_open.rst @@ -0,0 +1,102 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_f_open: + +******************* +DVB frontend open() +******************* + +Name +==== + +fe-open - Open a frontend device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int open( const char *device_name, int flags ) + + +Arguments +========= + +``device_name`` + Device to be opened. + +``flags`` + Open flags. Access can either be ``O_RDWR`` or ``O_RDONLY``. + + Multiple opens are allowed with ``O_RDONLY``. In this mode, only + query and read ioctls are allowed. + + Only one open is allowed in ``O_RDWR``. In this mode, all ioctls are + allowed. + + When the ``O_NONBLOCK`` flag is given, the system calls may return + ``EAGAIN`` error code when no data is available or when the device + driver is temporarily busy. + + Other flags have no effect. + + +Description +=========== + +This system call opens a named frontend device +(``/dev/dvb/adapter?/frontend?``) for subsequent use. Usually the first +thing to do after a successful open is to find out the frontend type +with :ref:`FE_GET_INFO`. + +The device can be opened in read-only mode, which only allows monitoring +of device status and statistics, or read/write mode, which allows any +kind of use (e.g. performing tuning operations.) + +In a system with multiple front-ends, it is usually the case that +multiple devices cannot be open in read/write mode simultaneously. As +long as a front-end device is opened in read/write mode, other open() +calls in read/write mode will either fail or block, depending on whether +non-blocking or blocking mode was specified. A front-end device opened +in blocking mode can later be put into non-blocking mode (and vice +versa) using the F_SETFL command of the fcntl system call. This is a +standard system call, documented in the Linux manual page for fcntl. +When an open() call has succeeded, the device will be ready for use in +the specified mode. This implies that the corresponding hardware is +powered up, and that other front-ends may have been powered down to make +that possible. + + +Return Value +============ + +On success :ref:`open() ` returns the new file descriptor. +On error, -1 is returned, and the ``errno`` variable is set appropriately. + +Possible error codes are: + +EACCES + The caller has no permission to access the device. + +EBUSY + The the device driver is already in use. + +ENXIO + No device corresponding to this device special file exists. + +ENOMEM + Not enough kernel memory was available to complete the request. + +EMFILE + The process already has the maximum number of files open. + +ENFILE + The limit on the total number of files open on the system has been + reached. + +ENODEV + The device got removed. diff --git a/Documentation/media/uapi/dvb/frontend_fcalls.rst b/Documentation/media/uapi/dvb/frontend_fcalls.rst new file mode 100644 index 0000000000000000000000000000000000000000..b03f9cab6d5a19fc42f82123ec79c5b2405d4c40 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_fcalls.rst @@ -0,0 +1,24 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_fcalls: + +####################### +Frontend Function Calls +####################### + +.. toctree:: + :maxdepth: 1 + + frontend_f_open + frontend_f_close + fe-get-info + fe-read-status + fe-get-property + fe-diseqc-reset-overload + fe-diseqc-send-master-cmd + fe-diseqc-recv-slave-reply + fe-diseqc-send-burst + fe-set-tone + fe-set-voltage + fe-enable-high-lnb-voltage + fe-set-frontend-tune-mode diff --git a/Documentation/media/uapi/dvb/frontend_h.rst b/Documentation/media/uapi/dvb/frontend_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..15fca04d1c3207062144424df88b2b055845045a --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_h: + +************************ +DVB Frontend Header File +************************ + +.. kernel-include:: $BUILDDIR/frontend.h.rst diff --git a/Documentation/media/uapi/dvb/frontend_legacy_api.rst b/Documentation/media/uapi/dvb/frontend_legacy_api.rst new file mode 100644 index 0000000000000000000000000000000000000000..759833d3eaa483b8e57d694338e9204588e2dcb2 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_legacy_api.rst @@ -0,0 +1,38 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_legacy_types: + +Frontend Legacy Data Types +========================== + + +.. toctree:: + :maxdepth: 1 + + fe-type-t + fe-bandwidth-t + dvb-frontend-parameters + dvb-frontend-event + + +.. _frontend_legacy_fcalls: + +Frontend Legacy Function Calls +============================== + +Those functions are defined at DVB version 3. The support is kept in the +kernel due to compatibility issues only. Their usage is strongly not +recommended + + +.. toctree:: + :maxdepth: 1 + + fe-read-ber + fe-read-snr + fe-read-signal-strength + fe-read-uncorrected-blocks + fe-set-frontend + fe-get-frontend + fe-get-event + fe-dishnetwork-send-legacy-cmd diff --git a/Documentation/media/uapi/dvb/frontend_legacy_dvbv3_api.rst b/Documentation/media/uapi/dvb/frontend_legacy_dvbv3_api.rst new file mode 100644 index 0000000000000000000000000000000000000000..7d4a091b7d7fcefe1edd5bc9646ee269a7d9fc17 --- /dev/null +++ b/Documentation/media/uapi/dvb/frontend_legacy_dvbv3_api.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _frontend_legacy_dvbv3_api: + +**************************************** +DVB Frontend legacy API (a. k. a. DVBv3) +**************************************** + +The usage of this API is deprecated, as it doesn't support all digital +TV standards, doesn't provide good statistics measurements and provides +incomplete information. This is kept only to support legacy +applications. + + +.. toctree:: + :maxdepth: 1 + + frontend_legacy_api diff --git a/Documentation/media/uapi/dvb/intro.rst b/Documentation/media/uapi/dvb/intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..b61081d00a9fc28947739e2c62347ae5996be130 --- /dev/null +++ b/Documentation/media/uapi/dvb/intro.rst @@ -0,0 +1,172 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_introdution: + +************ +Introduction +************ + + +.. _requisites: + +What you need to know +===================== + +The reader of this document is required to have some knowledge in the +area of digital video broadcasting (DVB) and should be familiar with +part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222), i.e +you should know what a program/transport stream (PS/TS) is and what is +meant by a packetized elementary stream (PES) or an I-frame. + +Various DVB standards documents are available from http://www.dvb.org +and/or http://www.etsi.org. + +It is also necessary to know how to access unix/linux devices and how to +use ioctl calls. This also includes the knowledge of C or C++. + + +.. _history: + +History +======= + +The first API for DVB cards we used at Convergence in late 1999 was an +extension of the Video4Linux API which was primarily developed for frame +grabber cards. As such it was not really well suited to be used for DVB +cards and their new features like recording MPEG streams and filtering +several section and PES data streams at the same time. + +In early 2000, we were approached by Nokia with a proposal for a new +standard Linux DVB API. As a commitment to the development of terminals +based on open standards, Nokia and Convergence made it available to all +Linux developers and published it on https://linuxtv.org in September +2000. Convergence is the maintainer of the Linux DVB API. Together with +the LinuxTV community (i.e. you, the reader of this document), the Linux +DVB API will be constantly reviewed and improved. With the Linux driver +for the Siemens/Hauppauge DVB PCI card Convergence provides a first +implementation of the Linux DVB API. + + +.. _overview: + +Overview +======== + + +.. _stb_components: + +.. figure:: intro_files/dvbstb.* + :alt: dvbstb.pdf / dvbstb.png + :align: center + + Components of a DVB card/STB + +A DVB PCI card or DVB set-top-box (STB) usually consists of the +following main hardware components: + +- Frontend consisting of tuner and DVB demodulator + + Here the raw signal reaches the DVB hardware from a satellite dish or + antenna or directly from cable. The frontend down-converts and + demodulates this signal into an MPEG transport stream (TS). In case + of a satellite frontend, this includes a facility for satellite + equipment control (SEC), which allows control of LNB polarization, + multi feed switches or dish rotors. + +- Conditional Access (CA) hardware like CI adapters and smartcard slots + + The complete TS is passed through the CA hardware. Programs to which + the user has access (controlled by the smart card) are decoded in + real time and re-inserted into the TS. + +- Demultiplexer which filters the incoming DVB stream + + The demultiplexer splits the TS into its components like audio and + video streams. Besides usually several of such audio and video + streams it also contains data streams with information about the + programs offered in this or other streams of the same provider. + +- MPEG2 audio and video decoder + + The main targets of the demultiplexer are the MPEG2 audio and video + decoders. After decoding they pass on the uncompressed audio and + video to the computer screen or (through a PAL/NTSC encoder) to a TV + set. + +:ref:`stb_components` shows a crude schematic of the control and data +flow between those components. + +On a DVB PCI card not all of these have to be present since some +functionality can be provided by the main CPU of the PC (e.g. MPEG +picture and sound decoding) or is not needed (e.g. for data-only uses +like “internet over satellite”). Also not every card or STB provides +conditional access hardware. + + +.. _dvb_devices: + +Linux DVB Devices +================= + +The Linux DVB API lets you control these hardware components through +currently six Unix-style character devices for video, audio, frontend, +demux, CA and IP-over-DVB networking. The video and audio devices +control the MPEG2 decoder hardware, the frontend device the tuner and +the DVB demodulator. The demux device gives you control over the PES and +section filters of the hardware. If the hardware does not support +filtering these filters can be implemented in software. Finally, the CA +device controls all the conditional access capabilities of the hardware. +It can depend on the individual security requirements of the platform, +if and how many of the CA functions are made available to the +application through this device. + +All devices can be found in the ``/dev`` tree under ``/dev/dvb``. The +individual devices are called: + +- ``/dev/dvb/adapterN/audioM``, + +- ``/dev/dvb/adapterN/videoM``, + +- ``/dev/dvb/adapterN/frontendM``, + +- ``/dev/dvb/adapterN/netM``, + +- ``/dev/dvb/adapterN/demuxM``, + +- ``/dev/dvb/adapterN/dvrM``, + +- ``/dev/dvb/adapterN/caM``, + +where N enumerates the DVB PCI cards in a system starting from 0, and M +enumerates the devices of each type within each adapter, starting +from 0, too. We will omit the “ ``/dev/dvb/adapterN/``\ ” in the further +discussion of these devices. + +More details about the data structures and function calls of all the +devices are described in the following chapters. + + +.. _include_files: + +API include files +================= + +For each of the DVB devices a corresponding include file exists. The DVB +API include files should be included in application sources with a +partial path like: + + +.. code-block:: c + + #include + + #include + + #include + + #include + + +To enable applications to support different API version, an additional +include file ``linux/dvb/version.h`` exists, which defines the constant +``DVB_API_VERSION``. This document describes ``DVB_API_VERSION 5.10``. diff --git a/Documentation/media/uapi/dvb/intro_files/dvbstb.pdf b/Documentation/media/uapi/dvb/intro_files/dvbstb.pdf new file mode 100644 index 0000000000000000000000000000000000000000..0fa75d90c3eba1db9d07611ec6d86b4bc22d7a39 Binary files /dev/null and b/Documentation/media/uapi/dvb/intro_files/dvbstb.pdf differ diff --git a/Documentation/media/uapi/dvb/intro_files/dvbstb.png b/Documentation/media/uapi/dvb/intro_files/dvbstb.png new file mode 100644 index 0000000000000000000000000000000000000000..9b8f372e7afd9d016854973ba705dcdfbd1bbf13 Binary files /dev/null and b/Documentation/media/uapi/dvb/intro_files/dvbstb.png differ diff --git a/Documentation/media/uapi/dvb/legacy_dvb_apis.rst b/Documentation/media/uapi/dvb/legacy_dvb_apis.rst new file mode 100644 index 0000000000000000000000000000000000000000..2957f5a988b03819fa62099fc0b68348022f1ad8 --- /dev/null +++ b/Documentation/media/uapi/dvb/legacy_dvb_apis.rst @@ -0,0 +1,20 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _legacy_dvb_apis: + +******************* +DVB Deprecated APIs +******************* + +The APIs described here are kept only for historical reasons. There's +just one driver for a very legacy hardware that uses this API. No modern +drivers should use it. Instead, audio and video should be using the V4L2 +and ALSA APIs, and the pipelines should be set using the Media +Controller API + + +.. toctree:: + :maxdepth: 1 + + video + audio diff --git a/Documentation/media/uapi/dvb/net-add-if.rst b/Documentation/media/uapi/dvb/net-add-if.rst new file mode 100644 index 0000000000000000000000000000000000000000..2b990d0e0fe15b40502baed1c841df5b55998d06 --- /dev/null +++ b/Documentation/media/uapi/dvb/net-add-if.rst @@ -0,0 +1,91 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _NET_ADD_IF: + +**************** +ioctl NET_ADD_IF +**************** + +Name +==== + +NET_ADD_IF - Creates a new network interface for a given Packet ID. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dvb_net_if *net_if ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_TONE + +``net_if`` + pointer to struct :ref:`dvb_net_if ` + + +Description +=========== + +The NET_ADD_IF ioctl system call selects the Packet ID (PID) that +contains a TCP/IP traffic, the type of encapsulation to be used (MPE or +ULE) and the interface number for the new interface to be created. When +the system call successfully returns, a new virtual network interface is +created. + +The struct :ref:`dvb_net_if `::ifnum field will be +filled with the number of the created interface. + + +.. _dvb-net-if-t: + +struct dvb_net_if description +============================= + +.. _dvb-net-if: + +.. flat-table:: struct dvb_net_if + :header-rows: 1 + :stub-columns: 0 + + + - .. row 1 + + - ID + + - Description + + - .. row 2 + + - pid + + - Packet ID (PID) of the MPEG-TS that contains data + + - .. row 3 + + - ifnum + + - number of the DVB interface. + + - .. row 4 + + - feedtype + + - Encapsulation type of the feed. It can be: + ``DVB_NET_FEEDTYPE_MPE`` for MPE encoding or + ``DVB_NET_FEEDTYPE_ULE`` for ULE encoding. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/net-get-if.rst b/Documentation/media/uapi/dvb/net-get-if.rst new file mode 100644 index 0000000000000000000000000000000000000000..92b884143ccd550209741b3a645ce4aa31723a2d --- /dev/null +++ b/Documentation/media/uapi/dvb/net-get-if.rst @@ -0,0 +1,50 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _NET_GET_IF: + +**************** +ioctl NET_GET_IF +**************** + +Name +==== + +NET_GET_IF - Read the configuration data of an interface created via - :ref:`NET_ADD_IF `. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct dvb_net_if *net_if ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_TONE + +``net_if`` + pointer to struct :ref:`dvb_net_if ` + + +Description +=========== + +The NET_GET_IF ioctl uses the interface number given by the struct +:ref:`dvb_net_if `::ifnum field and fills the content of +struct :ref:`dvb_net_if ` with the packet ID and +encapsulation type used on such interface. If the interface was not +created yet with :ref:`NET_ADD_IF `, it will return -1 and fill +the ``errno`` with ``EINVAL`` error code. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/net-remove-if.rst b/Documentation/media/uapi/dvb/net-remove-if.rst new file mode 100644 index 0000000000000000000000000000000000000000..d374c1d63d06dcb21201478153a013b6141d6b18 --- /dev/null +++ b/Documentation/media/uapi/dvb/net-remove-if.rst @@ -0,0 +1,46 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _NET_REMOVE_IF: + +******************* +ioctl NET_REMOVE_IF +******************* + +Name +==== + +NET_REMOVE_IF - Removes a network interface. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, int ifnum ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + FE_SET_TONE + +``net_if`` + number of the interface to be removed + + +Description +=========== + +The NET_REMOVE_IF ioctl deletes an interface previously created via +:ref:`NET_ADD_IF `. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/net.rst b/Documentation/media/uapi/dvb/net.rst new file mode 100644 index 0000000000000000000000000000000000000000..eca42dd5326173f07c000bb1e6be1564e28afd12 --- /dev/null +++ b/Documentation/media/uapi/dvb/net.rst @@ -0,0 +1,40 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _net: + +############### +DVB Network API +############### +The DVB net device controls the mapping of data packages that are part +of a transport stream to be mapped into a virtual network interface, +visible through the standard Linux network protocol stack. + +Currently, two encapsulations are supported: + +- `Multi Protocol Encapsulation (MPE) `__ + +- `Ultra Lightweight Encapsulation (ULE) `__ + +In order to create the Linux virtual network interfaces, an application +needs to tell to the Kernel what are the PIDs and the encapsulation +types that are present on the transport stream. This is done through +``/dev/dvb/adapter?/net?`` device node. The data will be available via +virtual ``dvb?_?`` network interfaces, and will be controlled/routed via +the standard ip tools (like ip, route, netstat, ifconfig, etc). + +Data types and and ioctl definitions are defined via ``linux/dvb/net.h`` +header. + + +.. _net_fcalls: + +###################### +DVB net Function Calls +###################### + +.. toctree:: + :maxdepth: 1 + + net-add-if + net-remove-if + net-get-if diff --git a/Documentation/media/uapi/dvb/net_h.rst b/Documentation/media/uapi/dvb/net_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..7bcf5ba9d1ebbee19fe58422d2ad7bb9d0186892 --- /dev/null +++ b/Documentation/media/uapi/dvb/net_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _net_h: + +*********************** +DVB Network Header File +*********************** + +.. kernel-include:: $BUILDDIR/net.h.rst diff --git a/Documentation/media/uapi/dvb/query-dvb-frontend-info.rst b/Documentation/media/uapi/dvb/query-dvb-frontend-info.rst new file mode 100644 index 0000000000000000000000000000000000000000..81cd9b92a36c01d5dad83711839c6996391057b9 --- /dev/null +++ b/Documentation/media/uapi/dvb/query-dvb-frontend-info.rst @@ -0,0 +1,13 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _query-dvb-frontend-info: + +***************************** +Querying frontend information +***************************** + +Usually, the first thing to do when the frontend is opened is to check +the frontend capabilities. This is done using +:ref:`FE_GET_INFO`. This ioctl will enumerate the +DVB API version and other characteristics about the frontend, and can be +opened either in read only or read/write mode. diff --git a/Documentation/media/uapi/dvb/video-clear-buffer.rst b/Documentation/media/uapi/dvb/video-clear-buffer.rst new file mode 100644 index 0000000000000000000000000000000000000000..7c85aa06f0131338cd39c82fbb41b825b909d245 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-clear-buffer.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_CLEAR_BUFFER: + +================== +VIDEO_CLEAR_BUFFER +================== + +Name +---- + +VIDEO_CLEAR_BUFFER + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_CLEAR_BUFFER) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_CLEAR_BUFFER for this command. + + +Description +----------- + +This ioctl call clears all video buffers in the driver and in the +decoder hardware. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-command.rst b/Documentation/media/uapi/dvb/video-command.rst new file mode 100644 index 0000000000000000000000000000000000000000..b1634f722cbd42417fda98f5e131015cf675050b --- /dev/null +++ b/Documentation/media/uapi/dvb/video-command.rst @@ -0,0 +1,66 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_COMMAND: + +============= +VIDEO_COMMAND +============= + +Name +---- + +VIDEO_COMMAND + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_COMMAND, struct video_command *cmd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_COMMAND for this command. + + - .. row 3 + + - struct video_command \*cmd + + - Commands the decoder. + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders +this ioctl has been replaced by the +:ref:`VIDIOC_DECODER_CMD` ioctl. + +This ioctl commands the decoder. The ``video_command`` struct is a +subset of the ``v4l2_decoder_cmd`` struct, so refer to the +:ref:`VIDIOC_DECODER_CMD` documentation for +more information. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-continue.rst b/Documentation/media/uapi/dvb/video-continue.rst new file mode 100644 index 0000000000000000000000000000000000000000..c5acc094986f9bac72ace477731abe04228f5fdf --- /dev/null +++ b/Documentation/media/uapi/dvb/video-continue.rst @@ -0,0 +1,57 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_CONTINUE: + +============== +VIDEO_CONTINUE +============== + +Name +---- + +VIDEO_CONTINUE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_CONTINUE) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_CONTINUE for this command. + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 :ref:`VIDIOC_DECODER_CMD` instead. + +This ioctl call restarts decoding and playing processes of the video +stream which was played before a call to VIDEO_FREEZE was made. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-fast-forward.rst b/Documentation/media/uapi/dvb/video-fast-forward.rst new file mode 100644 index 0000000000000000000000000000000000000000..db338e9f5379c7a3d02aa0a029fd588c023c63a9 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-fast-forward.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_FAST_FORWARD: + +================== +VIDEO_FAST_FORWARD +================== + +Name +---- + +VIDEO_FAST_FORWARD + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_FAST_FORWARD, int nFrames) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_FAST_FORWARD for this command. + + - .. row 3 + + - int nFrames + + - The number of frames to skip. + + +Description +----------- + +This ioctl call asks the Video Device to skip decoding of N number of +I-frames. This call can only be used if VIDEO_SOURCE_MEMORY is +selected. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EPERM`` + + - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/media/uapi/dvb/video-fclose.rst b/Documentation/media/uapi/dvb/video-fclose.rst new file mode 100644 index 0000000000000000000000000000000000000000..ebeaade0c3510221090ba842c16b4f05a03ec224 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-fclose.rst @@ -0,0 +1,54 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_fclose: + +================= +dvb video close() +================= + +Name +---- + +dvb video close() + + +Synopsis +-------- + +.. cpp:function:: int close(int fd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + +Description +----------- + +This system call closes a previously opened video device. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/video-fopen.rst b/Documentation/media/uapi/dvb/video-fopen.rst new file mode 100644 index 0000000000000000000000000000000000000000..9e5471557b831e38369b3fc1bb483d1c53222cb2 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-fopen.rst @@ -0,0 +1,112 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_fopen: + +================ +dvb video open() +================ + +Name +---- + +dvb video open() + + +Synopsis +-------- + +.. cpp:function:: int open(const char *deviceName, int flags) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - const char \*deviceName + + - Name of specific video device. + + - .. row 2 + + - int flags + + - A bit-wise OR of the following flags: + + - .. row 3 + + - + - O_RDONLY read-only access + + - .. row 4 + + - + - O_RDWR read/write access + + - .. row 5 + + - + - O_NONBLOCK open in non-blocking mode + + - .. row 6 + + - + - (blocking mode is the default) + + +Description +----------- + +This system call opens a named video device (e.g. +/dev/dvb/adapter0/video0) for subsequent use. + +When an open() call has succeeded, the device will be ready for use. The +significance of blocking or non-blocking mode is described in the +documentation for functions where there is a difference. It does not +affect the semantics of the open() call itself. A device opened in +blocking mode can later be put into non-blocking mode (and vice versa) +using the F_SETFL command of the fcntl system call. This is a standard +system call, documented in the Linux manual page for fcntl. Only one +user can open the Video Device in O_RDWR mode. All other attempts to +open the device in this mode will fail, and an error-code will be +returned. If the Video Device is opened in O_RDONLY mode, the only +ioctl call that can be used is VIDEO_GET_STATUS. All other call will +return an error code. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``ENODEV`` + + - Device driver not loaded/available. + + - .. row 2 + + - ``EINTERNAL`` + + - Internal error. + + - .. row 3 + + - ``EBUSY`` + + - Device or resource busy. + + - .. row 4 + + - ``EINVAL`` + + - Invalid argument. diff --git a/Documentation/media/uapi/dvb/video-freeze.rst b/Documentation/media/uapi/dvb/video-freeze.rst new file mode 100644 index 0000000000000000000000000000000000000000..d3d0dc31281abf84fe3123c2a21688ffaf88794f --- /dev/null +++ b/Documentation/media/uapi/dvb/video-freeze.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_FREEZE: + +============ +VIDEO_FREEZE +============ + +Name +---- + +VIDEO_FREEZE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_FREEZE) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_FREEZE for this command. + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 :ref:`VIDIOC_DECODER_CMD` instead. + +This ioctl call suspends the live video stream being played. Decoding +and playing are frozen. It is then possible to restart the decoding and +playing process of the video stream using the VIDEO_CONTINUE command. +If VIDEO_SOURCE_MEMORY is selected in the ioctl call +VIDEO_SELECT_SOURCE, the DVB subsystem will not decode any more data +until the ioctl call VIDEO_CONTINUE or VIDEO_PLAY is performed. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-fwrite.rst b/Documentation/media/uapi/dvb/video-fwrite.rst new file mode 100644 index 0000000000000000000000000000000000000000..045038f4181e9e39f183313a6b22449490df6087 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-fwrite.rst @@ -0,0 +1,82 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_fwrite: + +================= +dvb video write() +================= + +Name +---- + +dvb video write() + + +Synopsis +-------- + +.. cpp:function:: size_t write(int fd, const void *buf, size_t count) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - void \*buf + + - Pointer to the buffer containing the PES data. + + - .. row 3 + + - size_t count + + - Size of buf. + + +Description +----------- + +This system call can only be used if VIDEO_SOURCE_MEMORY is selected +in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in +PES format, unless the capability allows other formats. If O_NONBLOCK +is not specified the function will block until buffer space is +available. The amount of data to be transferred is implied by count. + + +Return Value +------------ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EPERM`` + + - Mode VIDEO_SOURCE_MEMORY not selected. + + - .. row 2 + + - ``ENOMEM`` + + - Attempted to write more data than the internal buffer can hold. + + - .. row 3 + + - ``EBADF`` + + - fd is not a valid open file descriptor. diff --git a/Documentation/media/uapi/dvb/video-get-capabilities.rst b/Documentation/media/uapi/dvb/video-get-capabilities.rst new file mode 100644 index 0000000000000000000000000000000000000000..94cbbba478a818f14fda6067423ac9a96685c3ab --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-capabilities.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_CAPABILITIES: + +====================== +VIDEO_GET_CAPABILITIES +====================== + +Name +---- + +VIDEO_GET_CAPABILITIES + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_GET_CAPABILITIES, unsigned int *cap) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_CAPABILITIES for this command. + + - .. row 3 + + - unsigned int \*cap + + - Pointer to a location where to store the capability information. + + +Description +----------- + +This ioctl call asks the video device about its decoding capabilities. +On success it returns and integer which has bits set according to the +defines in section ??. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-get-event.rst b/Documentation/media/uapi/dvb/video-get-event.rst new file mode 100644 index 0000000000000000000000000000000000000000..a1484a22651840ff7bbbf32395ad120465aac5ec --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-event.rst @@ -0,0 +1,88 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_EVENT: + +=============== +VIDEO_GET_EVENT +=============== + +Name +---- + +VIDEO_GET_EVENT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_GET_EVENT, struct video_event *ev) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_EVENT for this command. + + - .. row 3 + + - struct video_event \*ev + + - Points to the location where the event, if any, is to be stored. + + +Description +----------- + +This ioctl is for DVB devices only. To get events from a V4L2 decoder +use the V4L2 :ref:`VIDIOC_DQEVENT` ioctl instead. + +This ioctl call returns an event of type video_event if available. If +an event is not available, the behavior depends on whether the device is +in blocking or non-blocking mode. In the latter case, the call fails +immediately with errno set to ``EWOULDBLOCK``. In the former case, the call +blocks until an event becomes available. The standard Linux poll() +and/or select() system calls can be used with the device file descriptor +to watch for new events. For select(), the file descriptor should be +included in the exceptfds argument, and for poll(), POLLPRI should be +specified as the wake-up condition. Read-only permissions are sufficient +for this ioctl call. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EWOULDBLOCK`` + + - There is no event pending, and the device is in non-blocking mode. + + - .. row 2 + + - ``EOVERFLOW`` + + - Overflow in event queue - one or more events were lost. diff --git a/Documentation/media/uapi/dvb/video-get-frame-count.rst b/Documentation/media/uapi/dvb/video-get-frame-count.rst new file mode 100644 index 0000000000000000000000000000000000000000..4ff100c2ee95b271e96b784d9e681f03b57ec982 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-frame-count.rst @@ -0,0 +1,65 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_FRAME_COUNT: + +===================== +VIDEO_GET_FRAME_COUNT +===================== + +Name +---- + +VIDEO_GET_FRAME_COUNT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_GET_FRAME_COUNT, __u64 *pts) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_FRAME_COUNT for this command. + + - .. row 3 + + - __u64 \*pts + + - Returns the number of frames displayed since the decoder was + started. + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders +this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_FRAME`` +control. + +This ioctl call asks the Video Device to return the number of displayed +frames since the decoder was started. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-get-frame-rate.rst b/Documentation/media/uapi/dvb/video-get-frame-rate.rst new file mode 100644 index 0000000000000000000000000000000000000000..131def9623055a0d254ae8d2237e796e20b54179 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-frame-rate.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_FRAME_RATE: + +==================== +VIDEO_GET_FRAME_RATE +==================== + +Name +---- + +VIDEO_GET_FRAME_RATE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_GET_FRAME_RATE, unsigned int *rate) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_FRAME_RATE for this command. + + - .. row 3 + + - unsigned int \*rate + + - Returns the framerate in number of frames per 1000 seconds. + + +Description +----------- + +This ioctl call asks the Video Device to return the current framerate. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-get-navi.rst b/Documentation/media/uapi/dvb/video-get-navi.rst new file mode 100644 index 0000000000000000000000000000000000000000..6c3034fe5fa2b1102c71065f5dcd0b0a23289fd2 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-navi.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_NAVI: + +============== +VIDEO_GET_NAVI +============== + +Name +---- + +VIDEO_GET_NAVI + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_GET_NAVI , video_navi_pack_t *navipack) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_NAVI for this command. + + - .. row 3 + + - video_navi_pack_t \*navipack + + - PCI or DSI pack (private stream 2) according to section ??. + + +Description +----------- + +This ioctl returns navigational information from the DVD stream. This is +especially needed if an encoded stream has to be decoded by the +hardware. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EFAULT`` + + - driver is not able to return navigational information diff --git a/Documentation/media/uapi/dvb/video-get-pts.rst b/Documentation/media/uapi/dvb/video-get-pts.rst new file mode 100644 index 0000000000000000000000000000000000000000..082612243bbb6560e63bda6183399df33873fa45 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-pts.rst @@ -0,0 +1,69 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_PTS: + +============= +VIDEO_GET_PTS +============= + +Name +---- + +VIDEO_GET_PTS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_GET_PTS, __u64 *pts) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_PTS for this command. + + - .. row 3 + + - __u64 \*pts + + - Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / + ISO/IEC 13818-1. + + The PTS should belong to the currently played frame if possible, + but may also be a value close to it like the PTS of the last + decoded frame or the last PTS extracted by the PES parser. + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders +this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_PTS`` +control. + +This ioctl call asks the Video Device to return the current PTS +timestamp. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-get-size.rst b/Documentation/media/uapi/dvb/video-get-size.rst new file mode 100644 index 0000000000000000000000000000000000000000..c75e3c47c471a2b845fcc9ac95c7b4f30b4b4c45 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-size.rst @@ -0,0 +1,59 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_SIZE: + +============== +VIDEO_GET_SIZE +============== + +Name +---- + +VIDEO_GET_SIZE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_GET_SIZE, video_size_t *size) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_SIZE for this command. + + - .. row 3 + + - video_size_t \*size + + - Returns the size and aspect ratio. + + +Description +----------- + +This ioctl returns the size and aspect ratio. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-get-status.rst b/Documentation/media/uapi/dvb/video-get-status.rst new file mode 100644 index 0000000000000000000000000000000000000000..ab9c2236df7e304bc78babfb10113a15b9ea4b91 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-get-status.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_GET_STATUS: + +================ +VIDEO_GET_STATUS +================ + +Name +---- + +VIDEO_GET_STATUS + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_GET_STATUS, struct video_status *status) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_GET_STATUS for this command. + + - .. row 3 + + - struct video_status \*status + + - Returns the current status of the Video Device. + + +Description +----------- + +This ioctl call asks the Video Device to return the current status of +the device. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-play.rst b/Documentation/media/uapi/dvb/video-play.rst new file mode 100644 index 0000000000000000000000000000000000000000..943c4b75537235c3c3d7208609a226b3414694aa --- /dev/null +++ b/Documentation/media/uapi/dvb/video-play.rst @@ -0,0 +1,57 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_PLAY: + +========== +VIDEO_PLAY +========== + +Name +---- + +VIDEO_PLAY + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_PLAY) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_PLAY for this command. + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 :ref:`VIDIOC_DECODER_CMD` instead. + +This ioctl call asks the Video Device to start playing a video stream +from the selected source. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-select-source.rst b/Documentation/media/uapi/dvb/video-select-source.rst new file mode 100644 index 0000000000000000000000000000000000000000..0ee0d03dbeb2ff5973ad31725bbef6406a4a9d1a --- /dev/null +++ b/Documentation/media/uapi/dvb/video-select-source.rst @@ -0,0 +1,65 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SELECT_SOURCE: + +=================== +VIDEO_SELECT_SOURCE +=================== + +Name +---- + +VIDEO_SELECT_SOURCE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SELECT_SOURCE, video_stream_source_t source) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SELECT_SOURCE for this command. + + - .. row 3 + + - video_stream_source_t source + + - Indicates which source shall be used for the Video stream. + + +Description +----------- + +This ioctl is for DVB devices only. This ioctl was also supported by the +V4L2 ivtv driver, but that has been replaced by the ivtv-specific +``IVTV_IOC_PASSTHROUGH_MODE`` ioctl. + +This ioctl call informs the video device which source shall be used for +the input data. The possible sources are demux or memory. If memory is +selected, the data is fed to the video device through the write command. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-set-attributes.rst b/Documentation/media/uapi/dvb/video-set-attributes.rst new file mode 100644 index 0000000000000000000000000000000000000000..326c5c876e8057d5c3eaf02b76214ad6a421b7bd --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-attributes.rst @@ -0,0 +1,75 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_ATTRIBUTES: + +==================== +VIDEO_SET_ATTRIBUTES +==================== + +Name +---- + +VIDEO_SET_ATTRIBUTES + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_ATTRIBUTE ,video_attributes_t vattr) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_ATTRIBUTE for this command. + + - .. row 3 + + - video_attributes_t vattr + + - video attributes according to section ??. + + +Description +----------- + +This ioctl is intended for DVD playback and allows you to set certain +information about the stream. Some hardware may not need this +information, but the call also tells the hardware to prepare for DVD +playback. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - input is not a valid attribute setting. diff --git a/Documentation/media/uapi/dvb/video-set-blank.rst b/Documentation/media/uapi/dvb/video-set-blank.rst new file mode 100644 index 0000000000000000000000000000000000000000..142ea8817380ceee99bdec426f52b08d59e9d8c6 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-blank.rst @@ -0,0 +1,64 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_BLANK: + +=============== +VIDEO_SET_BLANK +=============== + +Name +---- + +VIDEO_SET_BLANK + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_BLANK, boolean mode) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_BLANK for this command. + + - .. row 3 + + - boolean mode + + - TRUE: Blank screen when stop. + + - .. row 4 + + - + - FALSE: Show last decoded frame. + + +Description +----------- + +This ioctl call asks the Video Device to blank out the picture. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-set-display-format.rst b/Documentation/media/uapi/dvb/video-set-display-format.rst new file mode 100644 index 0000000000000000000000000000000000000000..2061ab06497717f6f808b4077cc342d95aa49f29 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-display-format.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_DISPLAY_FORMAT: + +======================== +VIDEO_SET_DISPLAY_FORMAT +======================== + +Name +---- + +VIDEO_SET_DISPLAY_FORMAT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_DISPLAY_FORMAT, video_display_format_t format) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_DISPLAY_FORMAT for this command. + + - .. row 3 + + - video_display_format_t format + + - Selects the video format to be used. + + +Description +----------- + +This ioctl call asks the Video Device to select the video format to be +applied by the MPEG chip on the video. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-set-format.rst b/Documentation/media/uapi/dvb/video-set-format.rst new file mode 100644 index 0000000000000000000000000000000000000000..53d66ec462ca51ecdad08281797092207473859a --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-format.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_FORMAT: + +================ +VIDEO_SET_FORMAT +================ + +Name +---- + +VIDEO_SET_FORMAT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_FORMAT, video_format_t format) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_FORMAT for this command. + + - .. row 3 + + - video_format_t format + + - video format of TV as defined in section ??. + + +Description +----------- + +This ioctl sets the screen format (aspect ratio) of the connected output +device (TV) so that the output of the decoder can be adjusted +accordingly. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - format is not a valid video format. diff --git a/Documentation/media/uapi/dvb/video-set-highlight.rst b/Documentation/media/uapi/dvb/video-set-highlight.rst new file mode 100644 index 0000000000000000000000000000000000000000..374f5d895b4d47df4c95b25bfeaa3bcdf9888258 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-highlight.rst @@ -0,0 +1,60 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_HIGHLIGHT: + +=================== +VIDEO_SET_HIGHLIGHT +=================== + +Name +---- + +VIDEO_SET_HIGHLIGHT + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_HIGHLIGHT ,video_highlight_t *vhilite) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_HIGHLIGHT for this command. + + - .. row 3 + + - video_highlight_t \*vhilite + + - SPU Highlight information according to section ??. + + +Description +----------- + +This ioctl sets the SPU highlight information for the menu access of a +DVD. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-set-id.rst b/Documentation/media/uapi/dvb/video-set-id.rst new file mode 100644 index 0000000000000000000000000000000000000000..9c002d5399ad6c827c856197226f38aad3725119 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-id.rst @@ -0,0 +1,73 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_ID: + +============ +VIDEO_SET_ID +============ + +Name +---- + +VIDEO_SET_ID + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_SET_ID, int id) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_ID for this command. + + - .. row 3 + + - int id + + - video sub-stream id + + +Description +----------- + +This ioctl selects which sub-stream is to be decoded if a program or +system stream is sent to the video device. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - Invalid sub-stream id. diff --git a/Documentation/media/uapi/dvb/video-set-spu-palette.rst b/Documentation/media/uapi/dvb/video-set-spu-palette.rst new file mode 100644 index 0000000000000000000000000000000000000000..4b80b6f56219ffaab013c54dcb6ef2c9748d2067 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-spu-palette.rst @@ -0,0 +1,72 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_SPU_PALETTE: + +===================== +VIDEO_SET_SPU_PALETTE +===================== + +Name +---- + +VIDEO_SET_SPU_PALETTE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_SPU_PALETTE, video_spu_palette_t *palette ) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_SPU_PALETTE for this command. + + - .. row 3 + + - video_spu_palette_t \*palette + + - SPU palette according to section ??. + + +Description +----------- + +This ioctl sets the SPU color palette. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - input is not a valid palette or driver doesn’t handle SPU. diff --git a/Documentation/media/uapi/dvb/video-set-spu.rst b/Documentation/media/uapi/dvb/video-set-spu.rst new file mode 100644 index 0000000000000000000000000000000000000000..a6f6924f10c402de1c55d1a2d1b72dc6c4a0c89e --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-spu.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_SPU: + +============= +VIDEO_SET_SPU +============= + +Name +---- + +VIDEO_SET_SPU + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_SPU , video_spu_t *spu) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_SPU for this command. + + - .. row 3 + + - video_spu_t \*spu + + - SPU decoding (de)activation and subid setting according to section + ??. + + +Description +----------- + +This ioctl activates or deactivates SPU decoding in a DVD input stream. +It can only be used, if the driver is able to handle a DVD stream. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - input is not a valid spu setting or driver cannot handle SPU. diff --git a/Documentation/media/uapi/dvb/video-set-streamtype.rst b/Documentation/media/uapi/dvb/video-set-streamtype.rst new file mode 100644 index 0000000000000000000000000000000000000000..75b2e7a6e8292b6a959fe4105b01b749ad653ad0 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-streamtype.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_STREAMTYPE: + +==================== +VIDEO_SET_STREAMTYPE +==================== + +Name +---- + +VIDEO_SET_STREAMTYPE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_STREAMTYPE, int type) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_STREAMTYPE for this command. + + - .. row 3 + + - int type + + - stream type + + +Description +----------- + +This ioctl tells the driver which kind of stream to expect being written +to it. If this call is not used the default of video PES is used. Some +drivers might not support this call and always expect PES. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-set-system.rst b/Documentation/media/uapi/dvb/video-set-system.rst new file mode 100644 index 0000000000000000000000000000000000000000..9ae0df1f5813a3fa731d83667a6ec777266a752d --- /dev/null +++ b/Documentation/media/uapi/dvb/video-set-system.rst @@ -0,0 +1,75 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SET_SYSTEM: + +================ +VIDEO_SET_SYSTEM +================ + +Name +---- + +VIDEO_SET_SYSTEM + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SET_SYSTEM , video_system_t system) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SET_FORMAT for this command. + + - .. row 3 + + - video_system_t system + + - video system of TV output. + + +Description +----------- + +This ioctl sets the television output format. The format (see section +??) may vary from the color format of the displayed MPEG stream. If the +hardware is not able to display the requested format the call will +return an error. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EINVAL`` + + - system is not a valid or supported video system. diff --git a/Documentation/media/uapi/dvb/video-slowmotion.rst b/Documentation/media/uapi/dvb/video-slowmotion.rst new file mode 100644 index 0000000000000000000000000000000000000000..905712844f6a71cbd0e640a00e5feea06c3d15e9 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-slowmotion.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_SLOWMOTION: + +================ +VIDEO_SLOWMOTION +================ + +Name +---- + +VIDEO_SLOWMOTION + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_SLOWMOTION, int nFrames) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_SLOWMOTION for this command. + + - .. row 3 + + - int nFrames + + - The number of times to repeat each frame. + + +Description +----------- + +This ioctl call asks the video device to repeat decoding frames N number +of times. This call can only be used if VIDEO_SOURCE_MEMORY is +selected. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``EPERM`` + + - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/media/uapi/dvb/video-stillpicture.rst b/Documentation/media/uapi/dvb/video-stillpicture.rst new file mode 100644 index 0000000000000000000000000000000000000000..ed3a2f53b998da4a407010661c5c58b8da9bcd53 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-stillpicture.rst @@ -0,0 +1,61 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_STILLPICTURE: + +================== +VIDEO_STILLPICTURE +================== + +Name +---- + +VIDEO_STILLPICTURE + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_STILLPICTURE, struct video_still_picture *sp) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_STILLPICTURE for this command. + + - .. row 3 + + - struct video_still_picture \*sp + + - Pointer to a location where an I-frame and size is stored. + + +Description +----------- + +This ioctl call asks the Video Device to display a still picture +(I-frame). The input data shall contain an I-frame. If the pointer is +NULL, then the current displayed still picture is blanked. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-stop.rst b/Documentation/media/uapi/dvb/video-stop.rst new file mode 100644 index 0000000000000000000000000000000000000000..ad8d59e06004672b19005d375b70954e2b503bd6 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-stop.rst @@ -0,0 +1,74 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_STOP: + +========== +VIDEO_STOP +========== + +Name +---- + +VIDEO_STOP + + +Synopsis +-------- + +.. cpp:function:: int ioctl(fd, int request = VIDEO_STOP, boolean mode) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_STOP for this command. + + - .. row 3 + + - Boolean mode + + - Indicates how the screen shall be handled. + + - .. row 4 + + - + - TRUE: Blank screen when stop. + + - .. row 5 + + - + - FALSE: Show last decoded frame. + + +Description +----------- + +This ioctl is for DVB devices only. To control a V4L2 decoder use the +V4L2 :ref:`VIDIOC_DECODER_CMD` instead. + +This ioctl call asks the Video Device to stop playing the current +stream. Depending on the input parameter, the screen can be blanked out +or displaying the last decoded frame. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video-try-command.rst b/Documentation/media/uapi/dvb/video-try-command.rst new file mode 100644 index 0000000000000000000000000000000000000000..df96c2d7fc6b7142b233889f8ea61bb6ed050846 --- /dev/null +++ b/Documentation/media/uapi/dvb/video-try-command.rst @@ -0,0 +1,66 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _VIDEO_TRY_COMMAND: + +================= +VIDEO_TRY_COMMAND +================= + +Name +---- + +VIDEO_TRY_COMMAND + + +Synopsis +-------- + +.. cpp:function:: int ioctl(int fd, int request = VIDEO_TRY_COMMAND, struct video_command *cmd) + + +Arguments +--------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - int fd + + - File descriptor returned by a previous call to open(). + + - .. row 2 + + - int request + + - Equals VIDEO_TRY_COMMAND for this command. + + - .. row 3 + + - struct video_command \*cmd + + - Try a decoder command. + + +Description +----------- + +This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders +this ioctl has been replaced by the +:ref:`VIDIOC_TRY_DECODER_CMD ` ioctl. + +This ioctl tries a decoder command. The ``video_command`` struct is a +subset of the ``v4l2_decoder_cmd`` struct, so refer to the +:ref:`VIDIOC_TRY_DECODER_CMD ` documentation +for more information. + + +Return Value +------------ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/dvb/video.rst b/Documentation/media/uapi/dvb/video.rst new file mode 100644 index 0000000000000000000000000000000000000000..60d43fb7ce22e9a5bc8f767ffc7f5ae8f174dd93 --- /dev/null +++ b/Documentation/media/uapi/dvb/video.rst @@ -0,0 +1,35 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _dvb_video: + +################ +DVB Video Device +################ +The DVB video device controls the MPEG2 video decoder of the DVB +hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data +types and and ioctl definitions can be accessed by including +**linux/dvb/video.h** in your application. + +Note that the DVB video device only controls decoding of the MPEG video +stream, not its presentation on the TV or computer screen. On PCs this +is typically handled by an associated video4linux device, e.g. +**/dev/video**, which allows scaling and defining output windows. + +Some DVB cards don’t have their own MPEG decoder, which results in the +omission of the audio and video device as well as the video4linux +device. + +The ioctls that deal with SPUs (sub picture units) and navigation +packets are only supported on some MPEG decoders made for DVD playback. + +These ioctls were also used by V4L2 to control MPEG decoders implemented +in V4L2. The use of these ioctls for that purpose has been made obsolete +and proper V4L2 ioctls or controls have been created to replace that +functionality. + + +.. toctree:: + :maxdepth: 1 + + video_types + video_function_calls diff --git a/Documentation/media/uapi/dvb/video_function_calls.rst b/Documentation/media/uapi/dvb/video_function_calls.rst new file mode 100644 index 0000000000000000000000000000000000000000..68588ac7fecbeecef70c1d81aa35b2ba71b694bc --- /dev/null +++ b/Documentation/media/uapi/dvb/video_function_calls.rst @@ -0,0 +1,43 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_function_calls: + +******************** +Video Function Calls +******************** + +.. toctree:: + :maxdepth: 1 + + video-fopen + video-fclose + video-fwrite + video-stop + video-play + video-freeze + video-continue + video-select-source + video-set-blank + video-get-status + video-get-frame-count + video-get-pts + video-get-frame-rate + video-get-event + video-command + video-try-command + video-get-size + video-set-display-format + video-stillpicture + video-fast-forward + video-slowmotion + video-get-capabilities + video-set-id + video-clear-buffer + video-set-streamtype + video-set-format + video-set-system + video-set-highlight + video-set-spu + video-set-spu-palette + video-get-navi + video-set-attributes diff --git a/Documentation/media/uapi/dvb/video_h.rst b/Documentation/media/uapi/dvb/video_h.rst new file mode 100644 index 0000000000000000000000000000000000000000..3f39b0c4879c2ae5615f3f64ff586c3094fe55be --- /dev/null +++ b/Documentation/media/uapi/dvb/video_h.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_h: + +********************* +DVB Video Header File +********************* + +.. kernel-include:: $BUILDDIR/video.h.rst diff --git a/Documentation/media/uapi/dvb/video_types.rst b/Documentation/media/uapi/dvb/video_types.rst new file mode 100644 index 0000000000000000000000000000000000000000..671f365ceeb49fdcb374bf90829f550bf04aac89 --- /dev/null +++ b/Documentation/media/uapi/dvb/video_types.rst @@ -0,0 +1,379 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _video_types: + +**************** +Video Data Types +**************** + + +.. _video-format-t: + +video_format_t +============== + +The ``video_format_t`` data type defined by + + +.. code-block:: c + + typedef enum { + VIDEO_FORMAT_4_3, /* Select 4:3 format */ + VIDEO_FORMAT_16_9, /* Select 16:9 format. */ + VIDEO_FORMAT_221_1 /* 2.21:1 */ + } video_format_t; + +is used in the VIDEO_SET_FORMAT function (??) to tell the driver which +aspect ratio the output hardware (e.g. TV) has. It is also used in the +data structures video_status (??) returned by VIDEO_GET_STATUS (??) +and video_event (??) returned by VIDEO_GET_EVENT (??) which report +about the display format of the current video stream. + + +.. _video-displayformat-t: + +video_displayformat_t +===================== + +In case the display format of the video stream and of the display +hardware differ the application has to specify how to handle the +cropping of the picture. This can be done using the +VIDEO_SET_DISPLAY_FORMAT call (??) which accepts + + +.. code-block:: c + + typedef enum { + VIDEO_PAN_SCAN, /* use pan and scan format */ + VIDEO_LETTER_BOX, /* use letterbox format */ + VIDEO_CENTER_CUT_OUT /* use center cut out format */ + } video_displayformat_t; + +as argument. + + +.. _video-stream-source-t: + +video_stream_source_t +===================== + +The video stream source is set through the VIDEO_SELECT_SOURCE call +and can take the following values, depending on whether we are replaying +from an internal (demuxer) or external (user write) source. + + +.. code-block:: c + + typedef enum { + VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ + VIDEO_SOURCE_MEMORY /* If this source is selected, the stream + comes from the user through the write + system call */ + } video_stream_source_t; + +VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the +frontend or the DVR device) as the source of the video stream. If +VIDEO_SOURCE_MEMORY is selected the stream comes from the application +through the **write()** system call. + + +.. _video-play-state-t: + +video_play_state_t +================== + +The following values can be returned by the VIDEO_GET_STATUS call +representing the state of video playback. + + +.. code-block:: c + + typedef enum { + VIDEO_STOPPED, /* Video is stopped */ + VIDEO_PLAYING, /* Video is currently playing */ + VIDEO_FREEZED /* Video is freezed */ + } video_play_state_t; + + +.. _video-command: + +struct video_command +==================== + +The structure must be zeroed before use by the application This ensures +it can be extended safely in the future. + + +.. code-block:: c + + struct video_command { + __u32 cmd; + __u32 flags; + union { + struct { + __u64 pts; + } stop; + + struct { + /* 0 or 1000 specifies normal speed, + 1 specifies forward single stepping, + -1 specifies backward single stepping, + >>1: playback at speed/1000 of the normal speed, + <-1: reverse playback at (-speed/1000) of the normal speed. */ + __s32 speed; + __u32 format; + } play; + + struct { + __u32 data[16]; + } raw; + }; + }; + + +.. _video-size-t: + +video_size_t +============ + + +.. code-block:: c + + typedef struct { + int w; + int h; + video_format_t aspect_ratio; + } video_size_t; + + +.. _video-event: + +struct video_event +================== + +The following is the structure of a video event as it is returned by the +VIDEO_GET_EVENT call. + + +.. code-block:: c + + struct video_event { + __s32 type; + #define VIDEO_EVENT_SIZE_CHANGED 1 + #define VIDEO_EVENT_FRAME_RATE_CHANGED 2 + #define VIDEO_EVENT_DECODER_STOPPED 3 + #define VIDEO_EVENT_VSYNC 4 + __kernel_time_t timestamp; + union { + video_size_t size; + unsigned int frame_rate; /* in frames per 1000sec */ + unsigned char vsync_field; /* unknown/odd/even/progressive */ + } u; + }; + + +.. _video-status: + +struct video_status +=================== + +The VIDEO_GET_STATUS call returns the following structure informing +about various states of the playback operation. + + +.. code-block:: c + + struct video_status { + int video_blank; /* blank video on freeze? */ + video_play_state_t play_state; /* current state of playback */ + video_stream_source_t stream_source; /* current source (demux/memory) */ + video_format_t video_format; /* current aspect ratio of stream */ + video_displayformat_t display_format;/* selected cropping mode */ + }; + +If video_blank is set video will be blanked out if the channel is +changed or if playback is stopped. Otherwise, the last picture will be +displayed. play_state indicates if the video is currently frozen, +stopped, or being played back. The stream_source corresponds to the +seleted source for the video stream. It can come either from the +demultiplexer or from memory. The video_format indicates the aspect +ratio (one of 4:3 or 16:9) of the currently played video stream. +Finally, display_format corresponds to the selected cropping mode in +case the source video format is not the same as the format of the output +device. + + +.. _video-still-picture: + +struct video_still_picture +========================== + +An I-frame displayed via the VIDEO_STILLPICTURE call is passed on +within the following structure. + + +.. code-block:: c + + /* pointer to and size of a single iframe in memory */ + struct video_still_picture { + char *iFrame; /* pointer to a single iframe in memory */ + int32_t size; + }; + + +.. _video_caps: + +video capabilities +================== + +A call to VIDEO_GET_CAPABILITIES returns an unsigned integer with the +following bits set according to the hardwares capabilities. + + +.. code-block:: c + + /* bit definitions for capabilities: */ + /* can the hardware decode MPEG1 and/or MPEG2? */ + #define VIDEO_CAP_MPEG1 1 + #define VIDEO_CAP_MPEG2 2 + /* can you send a system and/or program stream to video device? + (you still have to open the video and the audio device but only + send the stream to the video device) */ + #define VIDEO_CAP_SYS 4 + #define VIDEO_CAP_PROG 8 + /* can the driver also handle SPU, NAVI and CSS encoded data? + (CSS API is not present yet) */ + #define VIDEO_CAP_SPU 16 + #define VIDEO_CAP_NAVI 32 + #define VIDEO_CAP_CSS 64 + + +.. _video-system: + +video_system_t +============== + +A call to VIDEO_SET_SYSTEM sets the desired video system for TV +output. The following system types can be set: + + +.. code-block:: c + + typedef enum { + VIDEO_SYSTEM_PAL, + VIDEO_SYSTEM_NTSC, + VIDEO_SYSTEM_PALN, + VIDEO_SYSTEM_PALNc, + VIDEO_SYSTEM_PALM, + VIDEO_SYSTEM_NTSC60, + VIDEO_SYSTEM_PAL60, + VIDEO_SYSTEM_PALM60 + } video_system_t; + + +.. _video-highlight: + +struct video_highlight +====================== + +Calling the ioctl VIDEO_SET_HIGHLIGHTS posts the SPU highlight +information. The call expects the following format for that information: + + +.. code-block:: c + + typedef + struct video_highlight { + boolean active; /* 1=show highlight, 0=hide highlight */ + uint8_t contrast1; /* 7- 4 Pattern pixel contrast */ + /* 3- 0 Background pixel contrast */ + uint8_t contrast2; /* 7- 4 Emphasis pixel-2 contrast */ + /* 3- 0 Emphasis pixel-1 contrast */ + uint8_t color1; /* 7- 4 Pattern pixel color */ + /* 3- 0 Background pixel color */ + uint8_t color2; /* 7- 4 Emphasis pixel-2 color */ + /* 3- 0 Emphasis pixel-1 color */ + uint32_t ypos; /* 23-22 auto action mode */ + /* 21-12 start y */ + /* 9- 0 end y */ + uint32_t xpos; /* 23-22 button color number */ + /* 21-12 start x */ + /* 9- 0 end x */ + } video_highlight_t; + + +.. _video-spu: + +struct video_spu +================ + +Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according +to the following format: + + +.. code-block:: c + + typedef + struct video_spu { + boolean active; + int stream_id; + } video_spu_t; + + +.. _video-spu-palette: + +struct video_spu_palette +======================== + +The following structure is used to set the SPU palette by calling +VIDEO_SPU_PALETTE: + + +.. code-block:: c + + typedef + struct video_spu_palette { + int length; + uint8_t *palette; + } video_spu_palette_t; + + +.. _video-navi-pack: + +struct video_navi_pack +====================== + +In order to get the navigational data the following structure has to be +passed to the ioctl VIDEO_GET_NAVI: + + +.. code-block:: c + + typedef + struct video_navi_pack { + int length; /* 0 ... 1024 */ + uint8_t data[1024]; + } video_navi_pack_t; + + +.. _video-attributes-t: + +video_attributes_t +================== + +The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES: + + +.. code-block:: c + + typedef uint16_t video_attributes_t; + /* bits: descr. */ + /* 15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */ + /* 13-12 TV system (0=525/60, 1=625/50) */ + /* 11-10 Aspect ratio (0=4:3, 3=16:9) */ + /* 9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */ + /* 7 line 21-1 data present in GOP (1=yes, 0=no) */ + /* 6 line 21-2 data present in GOP (1=yes, 0=no) */ + /* 5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */ + /* 2 source letterboxed (1=yes, 0=no) */ + /* 0 film/camera mode (0=camera, 1=film (625/50 only)) */ diff --git a/Documentation/media/uapi/fdl-appendix.rst b/Documentation/media/uapi/fdl-appendix.rst new file mode 100644 index 0000000000000000000000000000000000000000..fd475180fed828a2868e4350d004cf4e36f56b26 --- /dev/null +++ b/Documentation/media/uapi/fdl-appendix.rst @@ -0,0 +1,471 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _fdl: + +****************************** +GNU Free Documentation License +****************************** + + +.. _fdl-preamble: + +0. PREAMBLE +=========== + +The purpose of this License is to make a manual, textbook, or other +written document “free” in the sense of freedom: to assure everyone the +effective freedom to copy and redistribute it, with or without modifying +it, either commercially or noncommercially. Secondarily, this License +preserves for the author and publisher a way to get credit for their +work, while not being considered responsible for modifications made by +others. + +This License is a kind of “copyleft”, which means that derivative works +of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft license +designed for free software. + +We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free program +should come with manuals providing the same freedoms that the software +does. But this License is not limited to software manuals; it can be +used for any textual work, regardless of subject matter or whether it is +published as a printed book. We recommend this License principally for +works whose purpose is instruction or reference. + + +.. _fdl-section1: + +1. APPLICABILITY AND DEFINITIONS +================================ + + +.. _fdl-document: + +This License applies to any manual or other work that contains a notice +placed by the copyright holder saying it can be distributed under the +terms of this License. The “Document”, below, refers to any such manual +or work. Any member of the public is a licensee, and is addressed as +“you”. + + +.. _fdl-modified: + +A “Modified Version” of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + + +.. _fdl-secondary: + +A “Secondary Section” is a named appendix or a front-matter section of +the :ref:`Document ` that deals exclusively with the +relationship of the publishers or authors of the Document to the +Document's overall subject (or to related matters) and contains nothing +that could fall directly within that overall subject. (For example, if +the Document is in part a textbook of mathematics, a Secondary Section +may not explain any mathematics.) The relationship could be a matter of +historical connection with the subject or with related matters, or of +legal, commercial, philosophical, ethical or political position +regarding them. + + +.. _fdl-invariant: + +The “Invariant Sections” are certain +:ref:`Secondary Sections ` whose titles are designated, +as being those of Invariant Sections, in the notice that says that the +:ref:`Document ` is released under this License. + + +.. _fdl-cover-texts: + +The “Cover Texts” are certain short passages of text that are listed, as +Front-Cover Texts or Back-Cover Texts, in the notice that says that the +:ref:`Document ` is released under this License. + + +.. _fdl-transparent: + +A “Transparent” copy of the :ref:`Document ` means a +machine-readable copy, represented in a format whose specification is +available to the general public, whose contents can be viewed and edited +directly and straightforwardly with generic text editors or (for images +composed of pixels) generic paint programs or (for drawings) some widely +available drawing editor, and that is suitable for input to text +formatters or for automatic translation to a variety of formats suitable +for input to text formatters. A copy made in an otherwise Transparent +file format whose markup has been designed to thwart or discourage +subsequent modification by readers is not Transparent. A copy that is +not “Transparent” is called “Opaque”. + +Examples of suitable formats for Transparent copies include plain ASCII +without markup, Texinfo input format, LaTeX input format, SGML or XML +using a publicly available DTD, and standard-conforming simple HTML +designed for human modification. Opaque formats include PostScript, PDF, +proprietary formats that can be read and edited only by proprietary word +processors, SGML or XML for which the DTD and/or processing tools are +not generally available, and the machine-generated HTML produced by some +word processors for output purposes only. + + +.. _fdl-title-page: + +The “Title Page” means, for a printed book, the title page itself, plus +such following pages as are needed to hold, legibly, the material this +License requires to appear in the title page. For works in formats which +do not have any title page as such, “Title Page” means the text near the +most prominent appearance of the work's title, preceding the beginning +of the body of the text. + + +.. _fdl-section2: + +2. VERBATIM COPYING +=================== + +You may copy and distribute the :ref:`Document ` in any +medium, either commercially or noncommercially, provided that this +License, the copyright notices, and the license notice saying this +License applies to the Document are reproduced in all copies, and that +you add no other conditions whatsoever to those of this License. You may +not use technical measures to obstruct or control the reading or further +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough +number of copies you must also follow the conditions in +:ref:`section 3 `. + +You may also lend copies, under the same conditions stated above, and +you may publicly display copies. + + +.. _fdl-section3: + +3. COPYING IN QUANTITY +====================== + +If you publish printed copies of the :ref:`Document ` +numbering more than 100, and the Document's license notice requires +:ref:`Cover Texts `, you must enclose the copies in +covers that carry, clearly and legibly, all these Cover Texts: +Front-Cover Texts on the front cover, and Back-Cover Texts on the back +cover. Both covers must also clearly and legibly identify you as the +publisher of these copies. The front cover must present the full title +with all words of the title equally prominent and visible. You may add +other material on the covers in addition. Copying with changes limited +to the covers, as long as they preserve the title of the +:ref:`Document ` and satisfy these conditions, can be +treated as verbatim copying in other respects. + +If the required texts for either cover are too voluminous to fit +legibly, you should put the first ones listed (as many as fit +reasonably) on the actual cover, and continue the rest onto adjacent +pages. + +If you publish or distribute :ref:`Opaque ` copies of +the :ref:`Document ` numbering more than 100, you must +either include a machine-readable :ref:`Transparent ` +copy along with each Opaque copy, or state in or with each Opaque copy a +publicly-accessible computer-network location containing a complete +Transparent copy of the Document, free of added material, which the +general network-using public has access to download anonymously at no +charge using public-standard network protocols. If you use the latter +option, you must take reasonably prudent steps, when you begin +distribution of Opaque copies in quantity, to ensure that this +Transparent copy will remain thus accessible at the stated location +until at least one year after the last time you distribute an Opaque +copy (directly or through your agents or retailers) of that edition to +the public. + +It is requested, but not required, that you contact the authors of the +:ref:`Document ` well before redistributing any large +number of copies, to give them a chance to provide you with an updated +version of the Document. + + +.. _fdl-section4: + +4. MODIFICATIONS +================ + +You may copy and distribute a :ref:`Modified Version ` +of the :ref:`Document ` under the conditions of sections +:ref:`2 ` and :ref:`3 ` above, provided +that you release the Modified Version under precisely this License, with +the Modified Version filling the role of the Document, thus licensing +distribution and modification of the Modified Version to whoever +possesses a copy of it. In addition, you must do these things in the +Modified Version: + +- **A.** + Use in the :ref:`Title Page ` (and on the covers, + if any) a title distinct from that of the + :ref:`Document `, and from those of previous versions + (which should, if there were any, be listed in the History section of + the Document). You may use the same title as a previous version if + the original publisher of that version gives permission. + +- **B.** + List on the :ref:`Title Page `, as authors, one or + more persons or entities responsible for authorship of the + modifications in the :ref:`Modified Version `, + together with at least five of the principal authors of the + :ref:`Document ` (all of its principal authors, if it + has less than five). + +- **C.** + State on the :ref:`Title Page ` the name of the + publisher of the :ref:`Modified Version `, as the + publisher. + +- **D.** + Preserve all the copyright notices of the + :ref:`Document `. + +- **E.** + Add an appropriate copyright notice for your modifications adjacent + to the other copyright notices. + +- **F.** + Include, immediately after the copyright notices, a license notice + giving the public permission to use the + :ref:`Modified Version ` under the terms of this + License, in the form shown in the Addendum below. + +- **G.** + Preserve in that license notice the full lists of + :ref:`Invariant Sections ` and required + :ref:`Cover Texts ` given in the + :ref:`Document's ` license notice. + +- **H.** + Include an unaltered copy of this License. + +- **I.** + Preserve the section entitled “History”, and its title, and add to it + an item stating at least the title, year, new authors, and publisher + of the :ref:`Modified Version ` as given on the + :ref:`Title Page `. If there is no section entitled + “History” in the :ref:`Document `, create one stating + the title, year, authors, and publisher of the Document as given on + its Title Page, then add an item describing the Modified Version as + stated in the previous sentence. + +- **J.** + Preserve the network location, if any, given in the + :ref:`Document ` for public access to a + :ref:`Transparent ` copy of the Document, and + likewise the network locations given in the Document for previous + versions it was based on. These may be placed in the “History” + section. You may omit a network location for a work that was + published at least four years before the Document itself, or if the + original publisher of the version it refers to gives permission. + +- **K.** + In any section entitled “Acknowledgements” or “Dedications”, preserve + the section's title, and preserve in the section all the substance + and tone of each of the contributor acknowledgements and/or + dedications given therein. + +- **L.** + Preserve all the :ref:`Invariant Sections ` of the + :ref:`Document `, unaltered in their text and in + their titles. Section numbers or the equivalent are not considered + part of the section titles. + +- **M.** + Delete any section entitled “Endorsements”. Such a section may not be + included in the :ref:`Modified Version `. + +- **N.** + Do not retitle any existing section as “Endorsements” or to conflict + in title with any :ref:`Invariant Section `. + +If the :ref:`Modified Version ` includes new +front-matter sections or appendices that qualify as +:ref:`Secondary Sections ` and contain no material +copied from the Document, you may at your option designate some or all +of these sections as invariant. To do this, add their titles to the list +of :ref:`Invariant Sections ` in the Modified Version's +license notice. These titles must be distinct from any other section +titles. + +You may add a section entitled “Endorsements”, provided it contains +nothing but endorsements of your +:ref:`Modified Version ` by various parties--for +example, statements of peer review or that the text has been approved by +an organization as the authoritative definition of a standard. + +You may add a passage of up to five words as a +:ref:`Front-Cover Text `, and a passage of up to 25 +words as a :ref:`Back-Cover Text `, to the end of the +list of :ref:`Cover Texts ` in the +:ref:`Modified Version `. Only one passage of +Front-Cover Text and one of Back-Cover Text may be added by (or through +arrangements made by) any one entity. If the +:ref:`Document ` already includes a cover text for the +same cover, previously added by you or by arrangement made by the same +entity you are acting on behalf of, you may not add another; but you may +replace the old one, on explicit permission from the previous publisher +that added the old one. + +The author(s) and publisher(s) of the :ref:`Document ` +do not by this License give permission to use their names for publicity +for or to assert or imply endorsement of any +:ref:`Modified Version `. + + +.. _fdl-section5: + +5. COMBINING DOCUMENTS +====================== + +You may combine the :ref:`Document ` with other +documents released under this License, under the terms defined in +:ref:`section 4 ` above for modified versions, provided +that you include in the combination all of the +:ref:`Invariant Sections ` of all of the original +documents, unmodified, and list them all as Invariant Sections of your +combined work in its license notice. + +The combined work need only contain one copy of this License, and +multiple identical :ref:`Invariant Sections ` may be +replaced with a single copy. If there are multiple Invariant Sections +with the same name but different contents, make the title of each such +section unique by adding at the end of it, in parentheses, the name of +the original author or publisher of that section if known, or else a +unique number. Make the same adjustment to the section titles in the +list of Invariant Sections in the license notice of the combined work. + +In the combination, you must combine any sections entitled “History” in +the various original documents, forming one section entitled “History”; +likewise combine any sections entitled “Acknowledgements”, and any +sections entitled “Dedications”. You must delete all sections entitled +“Endorsements.” + + +.. _fdl-section6: + +6. COLLECTIONS OF DOCUMENTS +=========================== + +You may make a collection consisting of the +:ref:`Document ` and other documents released under this +License, and replace the individual copies of this License in the +various documents with a single copy that is included in the collection, +provided that you follow the rules of this License for verbatim copying +of each of the documents in all other respects. + +You may extract a single document from such a collection, and dispbibute +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. + + +.. _fdl-section7: + +7. AGGREGATION WITH INDEPENDENT WORKS +===================================== + +A compilation of the :ref:`Document ` or its derivatives +with other separate and independent documents or works, in or on a +volume of a storage or distribution medium, does not as a whole count as +a :ref:`Modified Version ` of the Document, provided no +compilation copyright is claimed for the compilation. Such a compilation +is called an “aggregate”, and this License does not apply to the other +self-contained works thus compiled with the Document , on account of +their being thus compiled, if they are not themselves derivative works +of the Document. If the :ref:`Cover Text ` +requirement of :ref:`section 3 ` is applicable to these +copies of the Document, then if the Document is less than one quarter of +the entire aggregate, the Document's Cover Texts may be placed on covers +that surround only the Document within the aggregate. Otherwise they +must appear on covers around the whole aggregate. + + +.. _fdl-section8: + +8. TRANSLATION +============== + +Translation is considered a kind of modification, so you may distribute +translations of the :ref:`Document ` under the terms of +:ref:`section 4 `. Replacing +:ref:`Invariant Sections ` with translations requires +special permission from their copyright holders, but you may include +translations of some or all Invariant Sections in addition to the +original versions of these Invariant Sections. You may include a +translation of this License provided that you also include the original +English version of this License. In case of a disagreement between the +translation and the original English version of this License, the +original English version will prevail. + + +.. _fdl-section9: + +9. TERMINATION +============== + +You may not copy, modify, sublicense, or distribute the +:ref:`Document ` except as expressly provided for under +this License. Any other attempt to copy, modify, sublicense or +distribute the Document is void, and will automatically terminate your +rights under this License. However, parties who have received copies, or +rights, from you under this License will not have their licenses +terminated so long as such parties remain in full compliance. + + +.. _fdl-section10: + +10. FUTURE REVISIONS OF THIS LICENSE +==================================== + +The `Free Software Foundation `__ +may publish new, revised versions of the GNU Free Documentation License +from time to time. Such new versions will be similar in spirit to the +present version, but may differ in detail to address new problems or +concerns. See +`http://www.gnu.org/copyleft/ `__. + +Each version of the License is given a distinguishing version number. If +the :ref:`Document ` specifies that a particular +numbered version of this License “or any later version” applies to it, +you have the option of following the terms and conditions either of that +specified version or of any later version that has been published (not +as a draft) by the Free Software Foundation. If the Document does not +specify a version number of this License, you may choose any version +ever published (not as a draft) by the Free Software Foundation. + + +.. _fdl-using: + +Addendum +======== + +To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and license +notices just after the title page: + + Copyright © YEAR YOUR NAME. + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.1 or any later version published by the Free Software + Foundation; with the :ref:`Invariant Sections ` + being LIST THEIR TITLES, with the + :ref:`Front-Cover Texts ` being LIST, and with + the :ref:`Back-Cover Texts ` being LIST. A copy + of the license is included in the section entitled “GNU Free + Documentation License”. + +If you have no :ref:`Invariant Sections `, write “with +no Invariant Sections” instead of saying which ones are invariant. If +you have no :ref:`Front-Cover Texts `, write “no +Front-Cover Texts” instead of “Front-Cover Texts being LIST”; likewise +for :ref:`Back-Cover Texts `. + +If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of free +software license, such as the +`GNU General Public License `__, +to permit their use in free software. diff --git a/Documentation/media/uapi/gen-errors.rst b/Documentation/media/uapi/gen-errors.rst new file mode 100644 index 0000000000000000000000000000000000000000..d6b0cfd00a3fff25de59fc65cfa2d84ed63231ce --- /dev/null +++ b/Documentation/media/uapi/gen-errors.rst @@ -0,0 +1,103 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _gen_errors: + +******************* +Generic Error Codes +******************* + + +.. _gen-errors: + +.. flat-table:: Generic error codes + :header-rows: 0 + :stub-columns: 0 + :widths: 1 16 + + + - .. row 1 + + - ``EAGAIN`` (aka ``EWOULDBLOCK``) + + - The ioctl can't be handled because the device is in state where it + can't perform it. This could happen for example in case where + device is sleeping and ioctl is performed to query statistics. It + is also returned when the ioctl would need to wait for an event, + but the device was opened in non-blocking mode. + + - .. row 2 + + - ``EBADF`` + + - The file descriptor is not a valid. + + - .. row 3 + + - ``EBUSY`` + + - The ioctl can't be handled because the device is busy. This is + typically return while device is streaming, and an ioctl tried to + change something that would affect the stream, or would require + the usage of a hardware resource that was already allocated. The + ioctl must not be retried without performing another action to fix + the problem first (typically: stop the stream before retrying). + + - .. row 4 + + - ``EFAULT`` + + - There was a failure while copying data from/to userspace, probably + caused by an invalid pointer reference. + + - .. row 5 + + - ``EINVAL`` + + - One or more of the ioctl parameters are invalid or out of the + allowed range. This is a widely used error code. See the + individual ioctl requests for specific causes. + + - .. row 6 + + - ``ENODEV`` + + - Device not found or was removed. + + - .. row 7 + + - ``ENOMEM`` + + - There's not enough memory to handle the desired operation. + + - .. row 8 + + - ``ENOTTY`` + + - The ioctl is not supported by the driver, actually meaning that + the required functionality is not available, or the file + descriptor is not for a media device. + + - .. row 9 + + - ``ENOSPC`` + + - On USB devices, the stream ioctl's can return this error, meaning + that this request would overcommit the usb bandwidth reserved for + periodic transfers (up to 80% of the USB bandwidth). + + - .. row 10 + + - ``EPERM`` + + - Permission denied. Can be returned if the device needs write + permission, or some special capabilities is needed (e. g. root) + +.. note:: + + #. This list is not exaustive; ioctls may return other error codes. + Since errors may have side effects such as a driver reset, + applications should abort on unexpected errors, or otherwise + assume that the device is in a bad state. + + #. Request-specific error codes are listed in the individual + requests descriptions. diff --git a/Documentation/media/uapi/mediactl/media-controller-intro.rst b/Documentation/media/uapi/mediactl/media-controller-intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..3e776c0d827671eb0490696d0f28840d4e46b839 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-controller-intro.rst @@ -0,0 +1,33 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-controller-intro: + +Introduction +============ + +Media devices increasingly handle multiple related functions. Many USB +cameras include microphones, video capture hardware can also output +video, or SoC camera interfaces also perform memory-to-memory operations +similar to video codecs. + +Independent functions, even when implemented in the same hardware, can +be modelled as separate devices. A USB camera with a microphone will be +presented to userspace applications as V4L2 and ALSA capture devices. +The devices' relationships (when using a webcam, end-users shouldn't +have to manually select the associated USB microphone), while not made +available directly to applications by the drivers, can usually be +retrieved from sysfs. + +With more and more advanced SoC devices being introduced, the current +approach will not scale. Device topologies are getting increasingly +complex and can't always be represented by a tree structure. Hardware +blocks are shared between different functions, creating dependencies +between seemingly unrelated devices. + +Kernel abstraction APIs such as V4L2 and ALSA provide means for +applications to access hardware parameters. As newer hardware expose an +increasingly high number of those parameters, drivers need to guess what +applications really require based on limited information, thereby +implementing policies that belong to userspace. + +The media controller API aims at solving those problems. diff --git a/Documentation/media/uapi/mediactl/media-controller-model.rst b/Documentation/media/uapi/mediactl/media-controller-model.rst new file mode 100644 index 0000000000000000000000000000000000000000..558273cf9570364d621abd7e919868974746ab69 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-controller-model.rst @@ -0,0 +1,35 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-controller-model: + +Media device model +================== + +Discovering a device internal topology, and configuring it at runtime, +is one of the goals of the media controller API. To achieve this, +hardware devices and Linux Kernel interfaces are modelled as graph +objects on an oriented graph. The object types that constitute the graph +are: + +- An **entity** is a basic media hardware or software 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. + +- An **interface** is a graph representation of a Linux Kernel + userspace API interface, like a device node or a sysfs file that + controls one or more entities in the graph. + +- A **pad** is a data 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 **data 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. + +- An **interface link** is a point-to-point bidirectional control + connection between a Linux Kernel interface and an entity. diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst new file mode 100644 index 0000000000000000000000000000000000000000..7ae38d48969ea93300eed8a4f386e5a33787b91d --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-controller.rst @@ -0,0 +1,52 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +.. _media_controller: + +############################## +Part IV - Media Controller API +############################## + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 5 + :numbered: + + media-controller-intro + media-controller-model + media-types + media-funcs + media-header + + +********************** +Revision and Copyright +********************** + +Authors: + +- Pinchart, Laurent + + - Initial version. + +- Carvalho Chehab, Mauro + + - MEDIA_IOC_G_TOPOLOGY documentation and documentation improvements. + +**Copyright** |copy| 2010 : Laurent Pinchart + +**Copyright** |copy| 2015-2016 : Mauro Carvalho Chehab + +**************** +Revision History +**************** + +:revision: 1.1.0 / 2015-12-12 (*mcc*) + +:revision: 1.0.0 / 2010-11-10 (*lp*) + +Initial revision diff --git a/Documentation/media/uapi/mediactl/media-func-close.rst b/Documentation/media/uapi/mediactl/media-func-close.rst new file mode 100644 index 0000000000000000000000000000000000000000..39ef70ac865609197d3546fcecf792ab2b560f1c --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-func-close.rst @@ -0,0 +1,47 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-func-close: + +************* +media close() +************* + +Name +==== + +media-close - Close a media device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int close( int fd ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + + +Description +=========== + +Closes the media device. Resources associated with the file descriptor +are freed. The device configuration remain unchanged. + + +Return Value +============ + +:ref:`close() ` returns 0 on success. On error, -1 is returned, and +``errno`` is set appropriately. Possible error codes are: + +EBADF + ``fd`` is not a valid open file descriptor. diff --git a/Documentation/media/uapi/mediactl/media-func-ioctl.rst b/Documentation/media/uapi/mediactl/media-func-ioctl.rst new file mode 100644 index 0000000000000000000000000000000000000000..9d1b23133edf123d5352ad53c46fd74402f2932b --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-func-ioctl.rst @@ -0,0 +1,67 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-func-ioctl: + +************* +media ioctl() +************* + +Name +==== + +media-ioctl - Control a media device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int ioctl( int fd, int request, void *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + Media ioctl request code as defined in the media.h header file, for + example MEDIA_IOC_SETUP_LINK. + +``argp`` + Pointer to a request-specific structure. + + +Description +=========== + +The :ref:`ioctl() ` function manipulates media device +parameters. The argument ``fd`` must be an open file descriptor. + +The ioctl ``request`` code specifies the media function to be called. It +has encoded in it whether the argument is an input, output or read/write +parameter, and the size of the argument ``argp`` in bytes. + +Macros and structures definitions specifying media ioctl requests and +their parameters are located in the media.h header file. All media ioctl +requests, their respective function and parameters are specified in +:ref:`media-user-func`. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +Request-specific error codes are listed in the individual requests +descriptions. + +When an ioctl that takes an output or read/write parameter fails, the +parameter remains unmodified. diff --git a/Documentation/media/uapi/mediactl/media-func-open.rst b/Documentation/media/uapi/mediactl/media-func-open.rst new file mode 100644 index 0000000000000000000000000000000000000000..2b2ecd85b995ed30425490df2af2a0d070fe6e55 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-func-open.rst @@ -0,0 +1,69 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-func-open: + +************ +media open() +************ + +Name +==== + +media-open - Open a media device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: int open( const char *device_name, int flags ) + + +Arguments +========= + +``device_name`` + Device to be opened. + +``flags`` + Open flags. Access mode must be either ``O_RDONLY`` or ``O_RDWR``. + Other flags have no effect. + + +Description +=========== + +To open a media device applications call :ref:`open() ` with the +desired device name. The function has no side effects; the device +configuration remain unchanged. + +When the device is opened in read-only mode, attempts to modify its +configuration will result in an error, and ``errno`` will be set to +EBADF. + + +Return Value +============ + +:ref:`open() ` returns the new file descriptor on success. On error, +-1 is returned, and ``errno`` is set appropriately. Possible error codes +are: + +EACCES + The requested access to the file is not allowed. + +EMFILE + The process already has the maximum number of files open. + +ENFILE + The system limit on the total number of open files has been reached. + +ENOMEM + Insufficient kernel memory was available. + +ENXIO + No device corresponding to this device special file exists. diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst new file mode 100644 index 0000000000000000000000000000000000000000..076856501cdb34feb0afd2724f2551587d59b599 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-funcs.rst @@ -0,0 +1,18 @@ +.. _media-user-func: + +****************** +Function Reference +****************** + + +.. toctree:: + :maxdepth: 1 + + media-func-open + media-func-close + media-func-ioctl + media-ioc-device-info + media-ioc-g-topology + media-ioc-enum-entities + media-ioc-enum-links + media-ioc-setup-link diff --git a/Documentation/media/uapi/mediactl/media-header.rst b/Documentation/media/uapi/mediactl/media-header.rst new file mode 100644 index 0000000000000000000000000000000000000000..96f7b0155e5a5a6630687dd722d3afd1acff5870 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-header.rst @@ -0,0 +1,10 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_header: + +**************************** +Media Controller Header File +**************************** + +.. kernel-include:: $BUILDDIR/media.h.rst + diff --git a/Documentation/media/uapi/mediactl/media-ioc-device-info.rst b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst new file mode 100644 index 0000000000000000000000000000000000000000..467d82cbb81e9094b4b91ff6f8aa67601e6352aa --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst @@ -0,0 +1,142 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_device_info: + +*************************** +ioctl MEDIA_IOC_DEVICE_INFO +*************************** + +Name +==== + +MEDIA_IOC_DEVICE_INFO - Query device information + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct media_device_info *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + MEDIA_IOC_DEVICE_INFO + +``argp`` + + +Description +=========== + +All media devices must support the ``MEDIA_IOC_DEVICE_INFO`` ioctl. To +query device information, applications call the ioctl with a pointer to +a struct :ref:`media_device_info `. The driver +fills the structure and returns the information to the application. The +ioctl never fails. + + +.. _media-device-info: + +.. flat-table:: struct media_device_info + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - char + + - ``driver``\ [16] + + - Name of the driver implementing the media API as a NUL-terminated + ASCII string. The driver version is stored in the + ``driver_version`` field. + + Driver specific applications can use this information to verify + the driver identity. It is also useful to work around known bugs, + or to identify drivers in error reports. + + - .. row 2 + + - char + + - ``model``\ [32] + + - Device model name as a NUL-terminated UTF-8 string. The device + version is stored in the ``device_version`` field and is not be + appended to the model name. + + - .. row 3 + + - char + + - ``serial``\ [40] + + - Serial number as a NUL-terminated ASCII string. + + - .. row 4 + + - char + + - ``bus_info``\ [32] + + - Location of the device in the system as a NUL-terminated ASCII + string. This includes the bus type name (PCI, USB, ...) and a + bus-specific identifier. + + - .. row 5 + + - __u32 + + - ``media_version`` + + - Media API version, formatted with the ``KERNEL_VERSION()`` macro. + + - .. row 6 + + - __u32 + + - ``hw_revision`` + + - Hardware device revision in a driver-specific format. + + - .. row 7 + + - __u32 + + - ``driver_version`` + + - Media device driver version, formatted with the + ``KERNEL_VERSION()`` macro. Together with the ``driver`` field + this identifies a particular driver. + + - .. row 8 + + - __u32 + + - ``reserved``\ [31] + + - Reserved for future extensions. Drivers and applications must set + this array to zero. + + +The ``serial`` and ``bus_info`` fields can be used to distinguish +between multiple instances of otherwise identical hardware. The serial +number takes precedence when provided and can be assumed to be unique. +If the serial number is an empty string, the ``bus_info`` field can be +used instead. The ``bus_info`` field is guaranteed to be unique, but can +vary across reboots or device unplug/replug. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst new file mode 100644 index 0000000000000000000000000000000000000000..12d4b25d5b94092e3bd06cded359f7762cad1c10 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst @@ -0,0 +1,199 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_enum_entities: + +***************************** +ioctl MEDIA_IOC_ENUM_ENTITIES +***************************** + +Name +==== + +MEDIA_IOC_ENUM_ENTITIES - Enumerate entities and their properties + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct media_entity_desc *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + MEDIA_IOC_ENUM_ENTITIES + +``argp`` + + +Description +=========== + +To query the attributes of an entity, applications set the id field of a +struct :ref:`media_entity_desc ` structure and +call the MEDIA_IOC_ENUM_ENTITIES ioctl with a pointer to this +structure. The driver fills the rest of the structure or returns an +EINVAL error code when the id is invalid. + +.. _media-ent-id-flag-next: + +Entities can be enumerated by or'ing the id with the +``MEDIA_ENT_ID_FLAG_NEXT`` flag. The driver will return information +about the entity with the smallest id strictly larger than the requested +one ('next entity'), or the ``EINVAL`` error code if there is none. + +Entity IDs can be non-contiguous. Applications must *not* try to +enumerate entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing +id's until they get an error. + + +.. _media-entity-desc: + +.. flat-table:: struct media_entity_desc + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 1 1 8 + + + - .. row 1 + + - __u32 + + - ``id`` + + - + - + - Entity id, set by the application. When the id is or'ed with + ``MEDIA_ENT_ID_FLAG_NEXT``, the driver clears the flag and returns + the first entity with a larger id. + + - .. row 2 + + - char + + - ``name``\ [32] + + - + - + - Entity name as an UTF-8 NULL-terminated string. + + - .. row 3 + + - __u32 + + - ``type`` + + - + - + - Entity type, see :ref:`media-entity-type` for details. + + - .. row 4 + + - __u32 + + - ``revision`` + + - + - + - Entity revision. Always zero (obsolete) + + - .. row 5 + + - __u32 + + - ``flags`` + + - + - + - Entity flags, see :ref:`media-entity-flag` for details. + + - .. row 6 + + - __u32 + + - ``group_id`` + + - + - + - Entity group ID. Always zero (obsolete) + + - .. row 7 + + - __u16 + + - ``pads`` + + - + - + - Number of pads + + - .. row 8 + + - __u16 + + - ``links`` + + - + - + - Total number of outbound links. Inbound links are not counted in + this field. + + - .. row 9 + + - union + + - .. row 10 + + - + - struct + + - ``dev`` + + - + - Valid for (sub-)devices that create a single device node. + + - .. row 11 + + - + - + - __u32 + + - ``major`` + + - Device node major number. + + - .. row 12 + + - + - + - __u32 + + - ``minor`` + + - Device node minor number. + + - .. row 13 + + - + - __u8 + + - ``raw``\ [184] + + - + - + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +EINVAL + The struct :ref:`media_entity_desc ` ``id`` + references a non-existing entity. diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst b/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst new file mode 100644 index 0000000000000000000000000000000000000000..87443b1ce42d56c1031254b161767b691eef3dc4 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst @@ -0,0 +1,170 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_enum_links: + +************************** +ioctl MEDIA_IOC_ENUM_LINKS +************************** + +Name +==== + +MEDIA_IOC_ENUM_LINKS - Enumerate all pads and links for a given entity + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct media_links_enum *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + MEDIA_IOC_ENUM_LINKS + +``argp`` + + +Description +=========== + +To enumerate pads and/or links for a given entity, applications set the +entity field of a struct :ref:`media_links_enum ` +structure and initialize the struct +:ref:`media_pad_desc ` and struct +:ref:`media_link_desc ` structure arrays pointed by +the ``pads`` and ``links`` fields. They then call the +MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this structure. + +If the ``pads`` field is not NULL, the driver fills the ``pads`` array +with information about the entity's pads. The array must have enough +room to store all the entity's pads. The number of pads can be retrieved +with :ref:`MEDIA_IOC_ENUM_ENTITIES`. + +If the ``links`` field is not NULL, the driver fills the ``links`` array +with information about the entity's outbound links. The array must have +enough room to store all the entity's outbound links. The number of +outbound links can be retrieved with :ref:`MEDIA_IOC_ENUM_ENTITIES`. + +Only forward links that originate at one of the entity's source pads are +returned during the enumeration process. + + +.. _media-links-enum: + +.. flat-table:: struct media_links_enum + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - __u32 + + - ``entity`` + + - Entity id, set by the application. + + - .. row 2 + + - struct :ref:`media_pad_desc ` + + - \*\ ``pads`` + + - Pointer to a pads array allocated by the application. Ignored if + NULL. + + - .. row 3 + + - struct :ref:`media_link_desc ` + + - \*\ ``links`` + + - Pointer to a links array allocated by the application. Ignored if + NULL. + + + +.. _media-pad-desc: + +.. flat-table:: struct media_pad_desc + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - __u32 + + - ``entity`` + + - ID of the entity this pad belongs to. + + - .. row 2 + + - __u16 + + - ``index`` + + - 0-based pad index. + + - .. row 3 + + - __u32 + + - ``flags`` + + - Pad flags, see :ref:`media-pad-flag` for more details. + + + +.. _media-link-desc: + +.. flat-table:: struct media_link_desc + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - struct :ref:`media_pad_desc ` + + - ``source`` + + - Pad at the origin of this link. + + - .. row 2 + + - struct :ref:`media_pad_desc ` + + - ``sink`` + + - Pad at the target of this link. + + - .. row 3 + + - __u32 + + - ``flags`` + + - Link flags, see :ref:`media-link-flag` for more details. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +EINVAL + The struct :ref:`media_links_enum ` ``id`` + references a non-existing entity. diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst new file mode 100644 index 0000000000000000000000000000000000000000..2e382cc7762c37dece8fff52a0b28fe99a5f1be3 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst @@ -0,0 +1,377 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_g_topology: + +************************** +ioctl MEDIA_IOC_G_TOPOLOGY +************************** + +Name +==== + +MEDIA_IOC_G_TOPOLOGY - Enumerate the graph topology and graph element properties + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct media_v2_topology *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + MEDIA_IOC_G_TOPOLOGY + +``argp`` + + +Description +=========== + +The typical usage of this ioctl is to call it twice. On the first call, +the structure defined at struct +:ref:`media_v2_topology ` should be zeroed. At +return, if no errors happen, this ioctl will return the +``topology_version`` and the total number of entities, interfaces, pads +and links. + +Before the second call, the userspace should allocate arrays to store +the graph elements that are desired, putting the pointers to them at the +ptr_entities, ptr_interfaces, ptr_links and/or ptr_pads, keeping the +other values untouched. + +If the ``topology_version`` remains the same, the ioctl should fill the +desired arrays with the media graph elements. + + +.. _media-v2-topology: + +.. flat-table:: struct media_v2_topology + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + + - .. row 1 + + - __u64 + + - ``topology_version`` + + - Version of the media graph topology. When the graph is created, + this field starts with zero. Every time a graph element is added + or removed, this field is incremented. + + - .. row 2 + + - __u64 + + - ``num_entities`` + + - Number of entities in the graph + + - .. row 3 + + - __u64 + + - ``ptr_entities`` + + - A pointer to a memory area where the entities array will be + stored, converted to a 64-bits integer. It can be zero. if zero, + the ioctl won't store the entities. It will just update + ``num_entities`` + + - .. row 4 + + - __u64 + + - ``num_interfaces`` + + - Number of interfaces in the graph + + - .. row 5 + + - __u64 + + - ``ptr_interfaces`` + + - A pointer to a memory area where the interfaces array will be + stored, converted to a 64-bits integer. It can be zero. if zero, + the ioctl won't store the interfaces. It will just update + ``num_interfaces`` + + - .. row 6 + + - __u64 + + - ``num_pads`` + + - Total number of pads in the graph + + - .. row 7 + + - __u64 + + - ``ptr_pads`` + + - A pointer to a memory area where the pads array will be stored, + converted to a 64-bits integer. It can be zero. if zero, the ioctl + won't store the pads. It will just update ``num_pads`` + + - .. row 8 + + - __u64 + + - ``num_links`` + + - Total number of data and interface links in the graph + + - .. row 9 + + - __u64 + + - ``ptr_links`` + + - A pointer to a memory area where the links array will be stored, + converted to a 64-bits integer. It can be zero. if zero, the ioctl + won't store the links. It will just update ``num_links`` + + + +.. _media-v2-entity: + +.. flat-table:: struct media_v2_entity + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + + - .. row 1 + + - __u32 + + - ``id`` + + - Unique ID for the entity. + + - .. row 2 + + - char + + - ``name``\ [64] + + - Entity name as an UTF-8 NULL-terminated string. + + - .. row 3 + + - __u32 + + - ``function`` + + - Entity main function, see :ref:`media-entity-type` for details. + + - .. row 4 + + - __u32 + + - ``reserved``\ [12] + + - Reserved for future extensions. Drivers and applications must set + this array to zero. + + + +.. _media-v2-interface: + +.. flat-table:: struct media_v2_interface + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + - .. row 1 + + - __u32 + + - ``id`` + + - Unique ID for the interface. + + - .. row 2 + + - __u32 + + - ``intf_type`` + + - Interface type, see :ref:`media-intf-type` for details. + + - .. row 3 + + - __u32 + + - ``flags`` + + - Interface flags. Currently unused. + + - .. row 4 + + - __u32 + + - ``reserved``\ [9] + + - Reserved for future extensions. Drivers and applications must set + this array to zero. + + - .. row 5 + + - struct media_v2_intf_devnode + + - ``devnode`` + + - Used only for device node interfaces. See + :ref:`media-v2-intf-devnode` for details.. + + + +.. _media-v2-intf-devnode: + +.. flat-table:: struct media_v2_interface + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + + - .. row 1 + + - __u32 + + - ``major`` + + - Device node major number. + + - .. row 2 + + - __u32 + + - ``minor`` + + - Device node minor number. + + + +.. _media-v2-pad: + +.. flat-table:: struct media_v2_pad + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + + - .. row 1 + + - __u32 + + - ``id`` + + - Unique ID for the pad. + + - .. row 2 + + - __u32 + + - ``entity_id`` + + - Unique ID for the entity where this pad belongs. + + - .. row 3 + + - __u32 + + - ``flags`` + + - Pad flags, see :ref:`media-pad-flag` for more details. + + - .. row 4 + + - __u32 + + - ``reserved``\ [9] + + - Reserved for future extensions. Drivers and applications must set + this array to zero. + + + +.. _media-v2-link: + +.. flat-table:: struct media_v2_pad + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + + - .. row 1 + + - __u32 + + - ``id`` + + - Unique ID for the pad. + + - .. row 2 + + - __u32 + + - ``source_id`` + + - On pad to pad links: unique ID for the source pad. + + On interface to entity links: unique ID for the interface. + + - .. row 3 + + - __u32 + + - ``sink_id`` + + - On pad to pad links: unique ID for the sink pad. + + On interface to entity links: unique ID for the entity. + + - .. row 4 + + - __u32 + + - ``flags`` + + - Link flags, see :ref:`media-link-flag` for more details. + + - .. row 5 + + - __u32 + + - ``reserved``\ [5] + + - Reserved for future extensions. Drivers and applications must set + this array to zero. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +ENOSPC + This is returned when either one or more of the num_entities, + num_interfaces, num_links or num_pads are non-zero and are + smaller than the actual number of elements inside the graph. This + may happen if the ``topology_version`` changed when compared to the + last time this ioctl was called. Userspace should usually free the + area for the pointers, zero the struct elements and call this ioctl + again. diff --git a/Documentation/media/uapi/mediactl/media-ioc-setup-link.rst b/Documentation/media/uapi/mediactl/media-ioc-setup-link.rst new file mode 100644 index 0000000000000000000000000000000000000000..e02fe23de9de02d41815a0028330f2217707918c --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-setup-link.rst @@ -0,0 +1,68 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_setup_link: + +************************** +ioctl MEDIA_IOC_SETUP_LINK +************************** + +Name +==== + +MEDIA_IOC_SETUP_LINK - Modify the properties of a link + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct media_link_desc *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``request`` + MEDIA_IOC_SETUP_LINK + +``argp`` + + +Description +=========== + +To change link properties applications fill a struct +:ref:`media_link_desc ` with link identification +information (source and sink pad) and the new requested link flags. They +then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to that +structure. + +The only configurable property is the ``ENABLED`` link flag to +enable/disable a link. Links marked with the ``IMMUTABLE`` link flag can +not be enabled or disabled. + +Link configuration has no side effect on other links. If an enabled link +at the sink pad prevents the link from being enabled, the driver returns +with an ``EBUSY`` error code. + +Only links marked with the ``DYNAMIC`` link flag can be enabled/disabled +while streaming media data. Attempting to enable or disable a streaming +non-dynamic link will return an ``EBUSY`` error code. + +If the specified link can't be found the driver returns with an ``EINVAL`` +error code. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +EINVAL + The struct :ref:`media_link_desc ` references a + non-existing link, or the link is immutable and an attempt to modify + its configuration was made. diff --git a/Documentation/media/uapi/mediactl/media-types.rst b/Documentation/media/uapi/mediactl/media-types.rst new file mode 100644 index 0000000000000000000000000000000000000000..c77717b236cee50ef2a42d2e3b5373fa8cddb6cc --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-types.rst @@ -0,0 +1,606 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media-controller-types: + +Types and flags used to represent the media graph elements +========================================================== + + +.. _media-entity-type: + +.. flat-table:: Media entity types + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + .. _MEDIA-ENT-F-UNKNOWN: + .. _MEDIA-ENT-F-V4L2-SUBDEV-UNKNOWN: + + - ``MEDIA_ENT_F_UNKNOWN`` and ``MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN`` + + - Unknown entity. That generally indicates that a driver didn't + initialize properly the entity, with is a Kernel bug + + - .. row 2 + + .. _MEDIA-ENT-F-IO-V4L: + + - ``MEDIA_ENT_F_IO_V4L`` + + - Data streaming input and/or output entity. + + - .. row 3 + + .. _MEDIA-ENT-F-IO-VBI: + + - ``MEDIA_ENT_F_IO_VBI`` + + - V4L VBI streaming input or output entity + + - .. row 4 + + .. _MEDIA-ENT-F-IO-SWRADIO: + + - ``MEDIA_ENT_F_IO_SWRADIO`` + + - V4L Software Digital Radio (SDR) streaming input or output entity + + - .. row 5 + + .. _MEDIA-ENT-F-IO-DTV: + + - ``MEDIA_ENT_F_IO_DTV`` + + - DVB Digital TV streaming input or output entity + + - .. row 6 + + .. _MEDIA-ENT-F-DTV-DEMOD: + + - ``MEDIA_ENT_F_DTV_DEMOD`` + + - Digital TV demodulator entity. + + - .. row 7 + + .. _MEDIA-ENT-F-TS-DEMUX: + + - ``MEDIA_ENT_F_TS_DEMUX`` + + - MPEG Transport stream demux entity. Could be implemented on + hardware or in Kernelspace by the Linux DVB subsystem. + + - .. row 8 + + .. _MEDIA-ENT-F-DTV-CA: + + - ``MEDIA_ENT_F_DTV_CA`` + + - Digital TV Conditional Access module (CAM) entity + + - .. row 9 + + .. _MEDIA-ENT-F-DTV-NET-DECAP: + + - ``MEDIA_ENT_F_DTV_NET_DECAP`` + + - Digital TV network ULE/MLE desencapsulation entity. Could be + implemented on hardware or in Kernelspace + + - .. row 10 + + .. _MEDIA-ENT-F-CONN-RF: + + - ``MEDIA_ENT_F_CONN_RF`` + + - Connector for a Radio Frequency (RF) signal. + + - .. row 11 + + .. _MEDIA-ENT-F-CONN-SVIDEO: + + - ``MEDIA_ENT_F_CONN_SVIDEO`` + + - Connector for a S-Video signal. + + - .. row 12 + + .. _MEDIA-ENT-F-CONN-COMPOSITE: + + - ``MEDIA_ENT_F_CONN_COMPOSITE`` + + - Connector for a RGB composite signal. + + - .. row 13 + + .. _MEDIA-ENT-F-CAM-SENSOR: + + - ``MEDIA_ENT_F_CAM_SENSOR`` + + - Camera video sensor entity. + + - .. row 14 + + .. _MEDIA-ENT-F-FLASH: + + - ``MEDIA_ENT_F_FLASH`` + + - Flash controller entity. + + - .. row 15 + + .. _MEDIA-ENT-F-LENS: + + - ``MEDIA_ENT_F_LENS`` + + - Lens controller entity. + + - .. row 16 + + .. _MEDIA-ENT-F-ATV-DECODER: + + - ``MEDIA_ENT_F_ATV_DECODER`` + + - Analog video decoder, the basic function of the video decoder is + to accept analogue video from a wide variety of sources such as + broadcast, DVD players, cameras and video cassette recorders, in + either NTSC, PAL, SECAM or HD format, separating the stream into + its component parts, luminance and chrominance, and output it in + some digital video standard, with appropriate timing signals. + + - .. row 17 + + .. _MEDIA-ENT-F-TUNER: + + - ``MEDIA_ENT_F_TUNER`` + + - Digital TV, analog TV, radio and/or software radio tuner, with + consists on a PLL tuning stage that converts radio frequency (RF) + signal into an Intermediate Frequency (IF). Modern tuners have + internally IF-PLL decoders for audio and video, but older models + have those stages implemented on separate entities. + + - .. row 18 + + .. _MEDIA-ENT-F-IF-VID-DECODER: + + - ``MEDIA_ENT_F_IF_VID_DECODER`` + + - IF-PLL video decoder. It receives the IF from a PLL and decodes + the analog TV video signal. This is commonly found on some very + old analog tuners, like Philips MK3 designs. They all contain a + tda9887 (or some software compatible similar chip, like tda9885). + Those devices use a different I2C address than the tuner PLL. + + - .. row 19 + + .. _MEDIA-ENT-F-IF-AUD-DECODER: + + - ``MEDIA_ENT_F_IF_AUD_DECODER`` + + - IF-PLL sound decoder. It receives the IF from a PLL and decodes + the analog TV audio signal. This is commonly found on some very + old analog hardware, like Micronas msp3400, Philips tda9840, + tda985x, etc. Those devices use a different I2C address than the + tuner PLL and should be controlled together with the IF-PLL video + decoder. + + - .. row 20 + + .. _MEDIA-ENT-F-AUDIO-CAPTURE: + + - ``MEDIA_ENT_F_AUDIO_CAPTURE`` + + - Audio Capture Function Entity. + + - .. row 21 + + .. _MEDIA-ENT-F-AUDIO-PLAYBACK: + + - ``MEDIA_ENT_F_AUDIO_PLAYBACK`` + + - Audio Playback Function Entity. + + - .. row 22 + + .. _MEDIA-ENT-F-AUDIO-MIXER: + + - ``MEDIA_ENT_F_AUDIO_MIXER`` + + - Audio Mixer Function Entity. + + - .. row 23 + + .. _MEDIA-ENT-F-PROC-VIDEO-COMPOSER: + + - ``MEDIA_ENT_F_PROC_VIDEO_COMPOSER`` + + - Video composer (blender). An entity capable of video + composing must have at least two sink pads and one source + pad, and composes input video frames onto output video + frames. Composition can be performed using alpha blending, + color keying, raster operations (ROP), stitching or any other + means. + + - .. row 24 + + .. _MEDIA-ENT-F-PROC-VIDEO-PIXEL-FORMATTER: + + - ``MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER`` + + - Video pixel formatter. An entity capable of pixel formatting + must have at least one sink pad and one source pad. Read + pixel formatters read pixels from memory and perform a subset + of unpacking, cropping, color keying, alpha multiplication + and pixel encoding conversion. Write pixel formatters perform + a subset of dithering, pixel encoding conversion and packing + and write pixels to memory. + + - .. row 25 + + .. _MEDIA-ENT-F-PROC-VIDEO-PIXEL-ENC-CONV: + + - ``MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV`` + + - Video pixel encoding converter. An entity capable of pixel + enconding conversion must have at least one sink pad and one + source pad, and convert the encoding of pixels received on + its sink pad(s) to a different encoding output on its source + pad(s). Pixel encoding conversion includes but isn't limited + to RGB to/from HSV, RGB to/from YUV and CFA (Bayer) to RGB + conversions. + + - .. row 26 + + .. _MEDIA-ENT-F-PROC-VIDEO-LUT: + + - ``MEDIA_ENT_F_PROC_VIDEO_LUT`` + + - Video look-up table. An entity capable of video lookup table + processing must have one sink pad and one source pad. It uses + the values of the pixels received on its sink pad to look up + entries in internal tables and output them on its source pad. + The lookup processing can be performed on all components + separately or combine them for multi-dimensional table + lookups. + + - .. row 27 + + .. _MEDIA-ENT-F-PROC-VIDEO-SCALER: + + - ``MEDIA_ENT_F_PROC_VIDEO_SCALER`` + + - Video scaler. An entity capable of video scaling must have + at least one sink pad and one source pad, and scale the + video frame(s) received on its sink pad(s) to a different + resolution output on its source pad(s). The range of + supported scaling ratios is entity-specific and can differ + between the horizontal and vertical directions (in particular + scaling can be supported in one direction only). Binning and + skipping are considered as scaling. + + - .. row 28 + + .. _MEDIA-ENT-F-PROC-VIDEO-STATISTICS: + + - ``MEDIA_ENT_F_PROC_VIDEO_STATISTICS`` + + - Video statistics computation (histogram, 3A, ...). An entity + capable of statistics computation must have one sink pad and + one source pad. It computes statistics over the frames + received on its sink pad and outputs the statistics data on + its source pad. + + +.. _media-entity-flag: + +.. flat-table:: Media entity flags + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + .. _MEDIA-ENT-FL-DEFAULT: + + - ``MEDIA_ENT_FL_DEFAULT`` + + - Default entity for its type. Used to discover the default audio, + VBI and video devices, the default camera sensor, ... + + - .. row 2 + + .. _MEDIA-ENT-FL-CONNECTOR: + + - ``MEDIA_ENT_FL_CONNECTOR`` + + - The entity represents a data conector + + + +.. _media-intf-type: + +.. flat-table:: Media interface types + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + .. _MEDIA-INTF-T-DVB-FE: + + - ``MEDIA_INTF_T_DVB_FE`` + + - Device node interface for the Digital TV frontend + + - typically, /dev/dvb/adapter?/frontend? + + - .. row 2 + + .. _MEDIA-INTF-T-DVB-DEMUX: + + - ``MEDIA_INTF_T_DVB_DEMUX`` + + - Device node interface for the Digital TV demux + + - typically, /dev/dvb/adapter?/demux? + + - .. row 3 + + .. _MEDIA-INTF-T-DVB-DVR: + + - ``MEDIA_INTF_T_DVB_DVR`` + + - Device node interface for the Digital TV DVR + + - typically, /dev/dvb/adapter?/dvr? + + - .. row 4 + + .. _MEDIA-INTF-T-DVB-CA: + + - ``MEDIA_INTF_T_DVB_CA`` + + - Device node interface for the Digital TV Conditional Access + + - typically, /dev/dvb/adapter?/ca? + + - .. row 5 + + .. _MEDIA-INTF-T-DVB-NET: + + - ``MEDIA_INTF_T_DVB_NET`` + + - Device node interface for the Digital TV network control + + - typically, /dev/dvb/adapter?/net? + + - .. row 6 + + .. _MEDIA-INTF-T-V4L-VIDEO: + + - ``MEDIA_INTF_T_V4L_VIDEO`` + + - Device node interface for video (V4L) + + - typically, /dev/video? + + - .. row 7 + + .. _MEDIA-INTF-T-V4L-VBI: + + - ``MEDIA_INTF_T_V4L_VBI`` + + - Device node interface for VBI (V4L) + + - typically, /dev/vbi? + + - .. row 8 + + .. _MEDIA-INTF-T-V4L-RADIO: + + - ``MEDIA_INTF_T_V4L_RADIO`` + + - Device node interface for radio (V4L) + + - typically, /dev/vbi? + + - .. row 9 + + .. _MEDIA-INTF-T-V4L-SUBDEV: + + - ``MEDIA_INTF_T_V4L_SUBDEV`` + + - Device node interface for a V4L subdevice + + - typically, /dev/v4l-subdev? + + - .. row 10 + + .. _MEDIA-INTF-T-V4L-SWRADIO: + + - ``MEDIA_INTF_T_V4L_SWRADIO`` + + - Device node interface for Software Defined Radio (V4L) + + - typically, /dev/swradio? + + - .. row 11 + + .. _MEDIA-INTF-T-ALSA-PCM-CAPTURE: + + - ``MEDIA_INTF_T_ALSA_PCM_CAPTURE`` + + - Device node interface for ALSA PCM Capture + + - typically, /dev/snd/pcmC?D?c + + - .. row 12 + + .. _MEDIA-INTF-T-ALSA-PCM-PLAYBACK: + + - ``MEDIA_INTF_T_ALSA_PCM_PLAYBACK`` + + - Device node interface for ALSA PCM Playback + + - typically, /dev/snd/pcmC?D?p + + - .. row 13 + + .. _MEDIA-INTF-T-ALSA-CONTROL: + + - ``MEDIA_INTF_T_ALSA_CONTROL`` + + - Device node interface for ALSA Control + + - typically, /dev/snd/controlC? + + - .. row 14 + + .. _MEDIA-INTF-T-ALSA-COMPRESS: + + - ``MEDIA_INTF_T_ALSA_COMPRESS`` + + - Device node interface for ALSA Compress + + - typically, /dev/snd/compr? + + - .. row 15 + + .. _MEDIA-INTF-T-ALSA-RAWMIDI: + + - ``MEDIA_INTF_T_ALSA_RAWMIDI`` + + - Device node interface for ALSA Raw MIDI + + - typically, /dev/snd/midi? + + - .. row 16 + + .. _MEDIA-INTF-T-ALSA-HWDEP: + + - ``MEDIA_INTF_T_ALSA_HWDEP`` + + - Device node interface for ALSA Hardware Dependent + + - typically, /dev/snd/hwC?D? + + - .. row 17 + + .. _MEDIA-INTF-T-ALSA-SEQUENCER: + + - ``MEDIA_INTF_T_ALSA_SEQUENCER`` + + - Device node interface for ALSA Sequencer + + - typically, /dev/snd/seq + + - .. row 18 + + .. _MEDIA-INTF-T-ALSA-TIMER: + + - ``MEDIA_INTF_T_ALSA_TIMER`` + + - Device node interface for ALSA Timer + + - typically, /dev/snd/timer + + + +.. _media-pad-flag: + +.. flat-table:: Media pad flags + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + .. _MEDIA-PAD-FL-SINK: + + - ``MEDIA_PAD_FL_SINK`` + + - Input pad, relative to the entity. Input pads sink data and are + targets of links. + + - .. row 2 + + .. _MEDIA-PAD-FL-SOURCE: + + - ``MEDIA_PAD_FL_SOURCE`` + + - Output pad, relative to the entity. Output pads source data and + are origins of links. + + - .. row 3 + + .. _MEDIA-PAD-FL-MUST-CONNECT: + + - ``MEDIA_PAD_FL_MUST_CONNECT`` + + - If this flag is set and the pad is linked to any other pad, then + at least one of those links must be enabled for the entity to be + able to stream. There could be temporary reasons (e.g. device + configuration dependent) for the pad to need enabled links even + when this flag isn't set; the absence of the flag doesn't imply + there is none. + + +One and only one of ``MEDIA_PAD_FL_SINK`` and ``MEDIA_PAD_FL_SOURCE`` +must be set for every pad. + + +.. _media-link-flag: + +.. flat-table:: Media link flags + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + .. _MEDIA-LNK-FL-ENABLED: + + - ``MEDIA_LNK_FL_ENABLED`` + + - The link is enabled and can be used to transfer media data. When + two or more links target a sink pad, only one of them can be + enabled at a time. + + - .. row 2 + + .. _MEDIA-LNK-FL-IMMUTABLE: + + - ``MEDIA_LNK_FL_IMMUTABLE`` + + - The link enabled state can't be modified at runtime. An immutable + link is always enabled. + + - .. row 3 + + .. _MEDIA-LNK-FL-DYNAMIC: + + - ``MEDIA_LNK_FL_DYNAMIC`` + + - The link enabled state can be modified during streaming. This flag + is set by drivers and is read-only for applications. + + - .. row 4 + + .. _MEDIA-LNK-FL-LINK-TYPE: + + - ``MEDIA_LNK_FL_LINK_TYPE`` + + - This is a bitmask that defines the type of the link. Currently, + two types of links are supported: + + .. _MEDIA-LNK-FL-DATA-LINK: + + ``MEDIA_LNK_FL_DATA_LINK`` if the link is between two pads + + .. _MEDIA-LNK-FL-INTERFACE-LINK: + + ``MEDIA_LNK_FL_INTERFACE_LINK`` if the link is between an + interface and an entity diff --git a/Documentation/media/uapi/rc/keytable.c.rst b/Documentation/media/uapi/rc/keytable.c.rst new file mode 100644 index 0000000000000000000000000000000000000000..e6ce1e3f5a78a9be42f33904b00b5ad1dd1a2414 --- /dev/null +++ b/Documentation/media/uapi/rc/keytable.c.rst @@ -0,0 +1,176 @@ +.. -*- coding: utf-8; mode: rst -*- + +file: uapi/v4l/keytable.c +========================= + +.. code-block:: c + + /* keytable.c - This program allows checking/replacing keys at IR + + Copyright (C) 2006-2009 Mauro Carvalho Chehab + + This program 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. + */ + + #include + #include + #include + #include + #include + #include + #include + #include + + #include "parse.h" + + void prtcode (int *codes) + { + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (p->value == (unsigned)codes[1]) { + printf("scancode 0x%04x = %s (0x%02x)\\n", codes[0], p->name, codes[1]); + return; + } + } + + if (isprint (codes[1])) + printf("scancode %d = '%c' (0x%02x)\\n", codes[0], codes[1], codes[1]); + else + printf("scancode %d = 0x%02x\\n", codes[0], codes[1]); + } + + int parse_code(char *string) + { + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (!strcasecmp(p->name, string)) { + return p->value; + } + } + return -1; + } + + int main (int argc, char *argv[]) + { + int fd; + unsigned int i, j; + int codes[2]; + + if (argc<2 || argc>4) { + printf ("usage: %s to get table; or\\n" + " %s \\n" + " %s n",*argv,*argv,*argv); + return -1; + } + + if ((fd = open(argv[1], O_RDONLY)) < 0) { + perror("Couldn't open input device"); + return(-1); + } + + if (argc==4) { + int value; + + value=parse_code(argv[3]); + + if (value==-1) { + value = strtol(argv[3], NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(argv[2], NULL, 0); + codes [1] = (unsigned) value; + + if(ioctl(fd, EVIOCSKEYCODE, codes)) + perror ("EVIOCSKEYCODE"); + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + return 0; + } + + if (argc==3) { + FILE *fin; + int value; + char *scancode, *keycode, s[2048]; + + fin=fopen(argv[2],"r"); + if (fin==NULL) { + perror ("opening keycode file"); + return -1; + } + + /* Clears old table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + codes[1] = KEY_RESERVED; + ioctl(fd, EVIOCSKEYCODE, codes); + } + } + + while (fgets(s,sizeof(s),fin)) { + scancode=strtok(s,"\\n\\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + if (!strcasecmp(scancode, "scancode")) { + scancode = strtok(NULL,"\\n\\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + } + + keycode=strtok(NULL,"\\n\\t =:("); + if (!keycode) { + perror ("parsing input file keycode"); + return -1; + } + + // printf ("parsing %s=%s:", scancode, keycode); + value=parse_code(keycode); + // printf ("\\tvalue=%d\\n",value); + + if (value==-1) { + value = strtol(keycode, NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(scancode, NULL, 0); + codes [1] = (unsigned) value; + + // printf("\\t%04x=%04x\\n",codes[0], codes[1]); + if(ioctl(fd, EVIOCSKEYCODE, codes)) { + fprintf(stderr, "Setting scancode 0x%04x with 0x%04x via ",codes[0], codes[1]); + perror ("EVIOCSKEYCODE"); + } + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + } + return 0; + } + + /* Get scancode table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + if (!ioctl(fd, EVIOCGKEYCODE, codes) && codes[1] != KEY_RESERVED) + prtcode(codes); + } + } + return 0; + } diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst b/Documentation/media/uapi/rc/lirc-dev-intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..ef97e40f2fd873c7f951f138d877bd4d656a314c --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_dev_intro: + +************ +Introduction +************ + +The LIRC device interface is a bi-directional interface for transporting +raw IR data between userspace and kernelspace. Fundamentally, it is just +a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number of standard +struct file_operations defined on it. With respect to transporting raw +IR data to and fro, the essential fops are read, write and ioctl. + +Example dmesg output upon a driver registering w/LIRC: + +.. code-block:: none + + $ dmesg |grep lirc_dev + lirc_dev: IR Remote Control driver registered, major 248 + rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 + +What you should see for a chardev: + +.. code-block:: none + + $ ls -l /dev/lirc* + crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0 + +********** +LIRC modes +********** + +LIRC supports some modes of receiving and sending IR codes, as shown +on the following table. + +.. _lirc-mode-mode2: + +``LIRC_MODE_MODE2`` + + The driver returns a sequence of pulse and space codes to userspace. + + This mode is used only for IR receive. + +.. _lirc-mode-lirccode: + +``LIRC_MODE_LIRCCODE`` + + The IR signal is decoded internally by the receiver. The LIRC interface + returns the scancode as an integer value. This is the usual mode used + by several TV media cards. + + This mode is used only for IR receive. + +.. _lirc-mode-pulse: + +``LIRC_MODE_PULSE`` + + On puse mode, a sequence of pulse/space integer values are written to the + lirc device using :Ref:`lirc-write`. + + This mode is used only for IR send. diff --git a/Documentation/media/uapi/rc/lirc-dev.rst b/Documentation/media/uapi/rc/lirc-dev.rst new file mode 100644 index 0000000000000000000000000000000000000000..03cde25f5859dfcac2118de1b6e25f57f3573b5c --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-dev.rst @@ -0,0 +1,14 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_dev: + +LIRC Device Interface +===================== + + +.. toctree:: + :maxdepth: 1 + + lirc-dev-intro + lirc-func + lirc-header diff --git a/Documentation/media/uapi/rc/lirc-func.rst b/Documentation/media/uapi/rc/lirc-func.rst new file mode 100644 index 0000000000000000000000000000000000000000..9b5a772ec96c29f78c2e0c4e1a669a3ab5d5724e --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-func.rst @@ -0,0 +1,28 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_func: + +LIRC Function Reference +======================= + + +.. toctree:: + :maxdepth: 1 + + lirc-read + lirc-write + lirc-get-features + lirc-get-send-mode + lirc-get-rec-mode + lirc-get-rec-resolution + lirc-set-send-duty-cycle + lirc-get-timeout + lirc-set-rec-timeout + lirc-get-length + lirc-set-rec-carrier + lirc-set-rec-carrier-range + lirc-set-send-carrier + lirc-set-transmitter-mask + lirc-set-rec-timeout-reports + lirc-set-measure-carrier-mode + lirc-set-wideband-receiver diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst b/Documentation/media/uapi/rc/lirc-get-features.rst new file mode 100644 index 0000000000000000000000000000000000000000..e763ebfb2cb1c6bdb59e25e1af7b0693b01a2b2a --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-features.rst @@ -0,0 +1,181 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_features: + +*********************** +ioctl LIRC_GET_FEATURES +*********************** + +Name +==== + +LIRC_GET_FEATURES - Get the underlying hardware device's features + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *features) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_FEATURES + +``features`` + Bitmask with the LIRC features. + + +Description +=========== + + +Get the underlying hardware device's features. If a driver does not +announce support of certain features, calling of the corresponding ioctls +is undefined. + +LIRC features +============= + +.. _LIRC-CAN-REC-RAW: + +``LIRC_CAN_REC_RAW`` + + Unused. Kept just to avoid breaking uAPI. + +.. _LIRC-CAN-REC-PULSE: + +``LIRC_CAN_REC_PULSE`` + + The driver is capable of receiving using + :ref:`LIRC_MODE_PULSE `. + +.. _LIRC-CAN-REC-MODE2: + +``LIRC_CAN_REC_MODE2`` + + The driver is capable of receiving using + :ref:`LIRC_MODE_MODE2 `. + +.. _LIRC-CAN-REC-LIRCCODE: + +``LIRC_CAN_REC_LIRCCODE`` + + The driver is capable of receiving using + :ref:`LIRC_MODE_LIRCCODE `. + +.. _LIRC-CAN-SET-SEND-CARRIER: + +``LIRC_CAN_SET_SEND_CARRIER`` + + The driver supports changing the modulation frequency via + :ref:`ioctl LIRC_SET_SEND_CARRIER `. + +.. _LIRC-CAN-SET-SEND-DUTY-CYCLE: + +``LIRC_CAN_SET_SEND_DUTY_CYCLE`` + + The driver supports changing the duty cycle using + :ref:`ioctl LIRC_SET_SEND_DUTY_CYCLE `. + +.. _LIRC-CAN-SET-TRANSMITTER-MASK: + +``LIRC_CAN_SET_TRANSMITTER_MASK`` + + The driver supports changing the active transmitter(s) using + :ref:`ioctl LIRC_SET_TRANSMITTER_MASK `. + +.. _LIRC-CAN-SET-REC-CARRIER: + +``LIRC_CAN_SET_REC_CARRIER`` + + The driver supports setting the receive carrier frequency using + :ref:`ioctl LIRC_SET_REC_CARRIER `. + +.. _LIRC-CAN-SET-REC-DUTY-CYCLE-RANGE: + +``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE`` + + Unused. Kept just to avoid breaking uAPI. + +.. _LIRC-CAN-SET-REC-CARRIER-RANGE: + +``LIRC_CAN_SET_REC_CARRIER_RANGE`` + + The driver supports + :ref:`ioctl LIRC_SET_REC_CARRIER_RANGE `. + +.. _LIRC-CAN-GET-REC-RESOLUTION: + +``LIRC_CAN_GET_REC_RESOLUTION`` + + The driver supports + :ref:`ioctl LIRC_GET_REC_RESOLUTION `. + +.. _LIRC-CAN-SET-REC-TIMEOUT: + +``LIRC_CAN_SET_REC_TIMEOUT`` + + The driver supports + :ref:`ioctl LIRC_SET_REC_TIMEOUT `. + +.. _LIRC-CAN-SET-REC-FILTER: + +``LIRC_CAN_SET_REC_FILTER`` + + Unused. Kept just to avoid breaking uAPI. + +.. _LIRC-CAN-MEASURE-CARRIER: + +``LIRC_CAN_MEASURE_CARRIER`` + + The driver supports measuring of the modulation frequency using + :ref:`ioctl LIRC_SET_MEASURE_CARRIER_MODE `. + +.. _LIRC-CAN-USE-WIDEBAND-RECEIVER: + +``LIRC_CAN_USE_WIDEBAND_RECEIVER`` + + The driver supports learning mode using + :ref:`ioctl LIRC_SET_WIDEBAND_RECEIVER `. + +.. _LIRC-CAN-NOTIFY-DECODE: + +``LIRC_CAN_NOTIFY_DECODE`` + + Unused. Kept just to avoid breaking uAPI. + +.. _LIRC-CAN-SEND-RAW: + +``LIRC_CAN_SEND_RAW`` + + Unused. Kept just to avoid breaking uAPI. + +.. _LIRC-CAN-SEND-PULSE: + +``LIRC_CAN_SEND_PULSE`` + + The driver supports sending using :ref:`LIRC_MODE_PULSE `. + +.. _LIRC-CAN-SEND-MODE2: + +``LIRC_CAN_SEND_MODE2`` + + The driver supports sending using :ref:`LIRC_MODE_MODE2 `. + +.. _LIRC-CAN-SEND-LIRCCODE: + +``LIRC_CAN_SEND_LIRCCODE`` + + The driver supports sending codes (also called as IR blasting or IR TX). + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-get-length.rst b/Documentation/media/uapi/rc/lirc-get-length.rst new file mode 100644 index 0000000000000000000000000000000000000000..d11c3d3f2c06e18ea62e9ed97264d4bb1df597a6 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-length.rst @@ -0,0 +1,45 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_length: + +********************* +ioctl LIRC_GET_LENGTH +********************* + +Name +==== + +LIRC_GET_LENGTH - Retrieves the code length in bits. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *length ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_LENGTH + +``length`` + length, in bits + + +Description +=========== + +Retrieves the code length in bits (only for ``LIRC-MODE-LIRCCODE``). +Reads on the device must be done in blocks matching the bit count. +The bit could should be rounded up so that it matches full bytes. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..586860c36791fcffa61633121f3b8de19689e63e --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst @@ -0,0 +1,45 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_rec_mode: +.. _lirc_set_rec_mode: + +********************************************** +ioctls LIRC_GET_REC_MODE and LIRC_SET_REC_MODE +********************************************** + +Name +==== + +LIRC_GET_REC_MODE/LIRC_GET_REC_MODE - Get/set supported receive modes. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 rx_modes) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_REC_MODE or LIRC_GET_REC_MODE + +``rx_modes`` + Bitmask with the supported transmit modes. + +Description +=========== + +Get/set supported receive modes. Only :ref:`LIRC_MODE_MODE2 ` +and :ref:`LIRC_MODE_LIRCCODE ` are supported for IR +receive. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst b/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst new file mode 100644 index 0000000000000000000000000000000000000000..6ef1723878b4d2fcba93125f83e6de5629f175ec --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_rec_resolution: + +***************************** +ioctl LIRC_GET_REC_RESOLUTION +***************************** + +Name +==== + +LIRC_GET_REC_RESOLUTION - Obtain the value of receive resolution, in microseconds. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *microseconds) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_REC_RESOLUTION + +``microseconds`` + Resolution, in microseconds. + + +Description +=========== + +Some receivers 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 ioctl returns the integer value with such resolution, with can be +used by userspace applications like lircd to automatically adjust the +tolerance value. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-get-send-mode.rst b/Documentation/media/uapi/rc/lirc-get-send-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..3e1d96122ff2e6ff05adadf3d4cc6653d9b094b4 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-send-mode.rst @@ -0,0 +1,45 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_send_mode: +.. _lirc_set_send_mode: + +************************************************ +ioctls LIRC_GET_SEND_MODE and LIRC_SET_SEND_MODE +************************************************ + +Name +==== + +LIRC_GET_SEND_MODE/LIRC_SET_SEND_MODE - Get/set supported transmit mode. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *tx_modes ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_SEND_MODE + +``tx_modes`` + Bitmask with the supported transmit modes. + + +Description +=========== + +Get/set supported transmit mode. + +Only :ref:`LIRC_MODE_PULSE ` is supported by for IR send. + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-get-timeout.rst b/Documentation/media/uapi/rc/lirc-get-timeout.rst new file mode 100644 index 0000000000000000000000000000000000000000..6b8238f1f30e77a82ef8648941eef7fb91b9013b --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-get-timeout.rst @@ -0,0 +1,55 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_get_min_timeout: +.. _lirc_get_max_timeout: + +**************************************************** +ioctls LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT +**************************************************** + +Name +==== + +LIRC_GET_MIN_TIMEOUT / LIRC_GET_MAX_TIMEOUT - Obtain the possible timeout +range for IR receive. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *timeout) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_GET_MIN_TIMEOUT or LIRC_GET_MAX_TIMEOUT + +``timeout`` + Timeout, in microseconds. + + +Description +=========== + +Some devices have internal timers that can be used to detect when +there's no IR activity for a long time. This can help lircd in +detecting that a IR signal is finished and can speed up the decoding +process. Returns an integer value with the minimum/maximum timeout +that can be set. + +.. note:: + + Some devices have a fixed timeout, in that case + both ioctls will return the same value even though the timeout + cannot be changed via :ref:`LIRC_SET_REC_TIMEOUT`. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-header.rst b/Documentation/media/uapi/rc/lirc-header.rst new file mode 100644 index 0000000000000000000000000000000000000000..487fe00e5517ddf5546dd3bc4cf0ffc0cb7f3716 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-header.rst @@ -0,0 +1,10 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_header: + +**************** +LIRC Header File +**************** + +.. kernel-include:: $BUILDDIR/lirc.h.rst + diff --git a/Documentation/media/uapi/rc/lirc-read.rst b/Documentation/media/uapi/rc/lirc-read.rst new file mode 100644 index 0000000000000000000000000000000000000000..8d4e9b6e507d7fea6c860879180c4691b82341a5 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-read.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc-read: + +*********** +LIRC read() +*********** + +Name +==== + +lirc-read - Read from a LIRC device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: ssize_t read( int fd, void *buf, size_t count ) + + +Arguments +========= + +``fd`` + File descriptor returned by ``open()``. + +``buf`` +``count`` + + +Description +=========== + +:ref:`read() ` attempts to read up to ``count`` bytes from file +descriptor ``fd`` into the buffer starting at ``buf``. If ``count`` is zero, +:ref:`read() ` returns zero and has no other results. If ``count`` +is greater than ``SSIZE_MAX``, the result is unspecified. + +The lircd userspace daemon reads raw IR data from the LIRC chardev. The +exact format of the data depends on what modes a driver supports, and +what mode has been selected. lircd obtains supported modes and sets the +active mode via the ioctl interface, detailed at :ref:`lirc_func`. +The generally preferred mode for receive is +:ref:`LIRC_MODE_MODE2 `, in which packets containing an +int value describing an IR signal are read from the chardev. + +See also +`http://www.lirc.org/html/technical.html `__ +for more info. + +Return Value +============ + +On success, the number of bytes read is returned. It is not an error if +this number is smaller than the number of bytes requested, or the amount +of data required for one frame. On error, -1 is returned, and the ``errno`` +variable is set appropriately. diff --git a/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst b/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst new file mode 100644 index 0000000000000000000000000000000000000000..e145d9d1902d293a7cd0da113ff5c017bd4fdd14 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst @@ -0,0 +1,48 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_measure_carrier_mode: + +*********************************** +ioctl LIRC_SET_MEASURE_CARRIER_MODE +*********************************** + +Name +==== + +LIRC_SET_MEASURE_CARRIER_MODE - enable or disable measure mode + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *enable ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_MEASURE_CARRIER_MODE + +``enable`` + enable = 1 means enable measure mode, enable = 0 means disable measure + mode. + + +Description +=========== + +.. _lirc-mode2-frequency: + +Enable or disable measure mode. If enabled, from the next key +press on, the driver will send ``LIRC_MODE2_FREQUENCY`` packets. By +default this should be turned off. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst b/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst new file mode 100644 index 0000000000000000000000000000000000000000..7cce9c8ba361eef4e89ebe8b141e09929bef2c3b --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_rec_carrier_range: + +******************************** +ioctl LIRC_SET_REC_CARRIER_RANGE +******************************** + +Name +==== + +LIRC_SET_REC_CARRIER_RANGE - Set lower bond of the carrier used to modulate +IR receive. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_REC_CARRIER_RANGE + +``frequency`` + Frequency of the carrier that modulates PWM data, in Hz. + +Description +=========== + +This ioctl sets the upper range of carrier frequency that will be recognized +by the IR receiver. + +.. note:: + + To set a range use :ref:`LIRC_SET_REC_CARRIER_RANGE + ` with the lower bound first and later call + :ref:`LIRC_SET_REC_CARRIER ` with the upper bound. + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst b/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst new file mode 100644 index 0000000000000000000000000000000000000000..17ddb4723caaee500164a049b8ae98013a90b38a --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst @@ -0,0 +1,48 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_rec_carrier: + +************************** +ioctl LIRC_SET_REC_CARRIER +************************** + +Name +==== + +LIRC_SET_REC_CARRIER - Set carrier used to modulate IR receive. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_REC_CARRIER + +``frequency`` + Frequency of the carrier that modulates PWM data, in Hz. + +Description +=========== + +Set receive carrier used to modulate IR PWM pulses and spaces. + +.. note:: + + If called together with :ref:`LIRC_SET_REC_CARRIER_RANGE`, this ioctl + sets the upper bound frequency that will be recognized by the device. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst b/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst new file mode 100644 index 0000000000000000000000000000000000000000..0c7f85d0ce3bffdfc7a63e12a732e870a68ac136 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_rec_timeout_reports: + +********************************** +ioctl LIRC_SET_REC_TIMEOUT_REPORTS +********************************** + +Name +==== + +LIRC_SET_REC_TIMEOUT_REPORTS - enable or disable timeout reports for IR receive + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *enable ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_REC_TIMEOUT_REPORTS + +``enable`` + enable = 1 means enable timeout report, enable = 0 means disable timeout + reports. + + +Description +=========== + +Enable or disable timeout reports for IR receive. By default, timeout reports +should be turned off. + +.. note:: + + This ioctl is only valid for :ref:`LIRC_MODE_MODE2 `. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst new file mode 100644 index 0000000000000000000000000000000000000000..ffc88f9fcd527b1dd18ccc22753eb254bad9a753 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst @@ -0,0 +1,52 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_rec_timeout: + +************************** +ioctl LIRC_SET_REC_TIMEOUT +************************** + +Name +==== + +LIRC_SET_REC_TIMEOUT - sets the integer value for IR inactivity timeout. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *timeout ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_REC_TIMEOUT + +``timeout`` + Timeout, in microseconds. + + +Description +=========== + +Sets the integer value for IR inactivity timeout. + +If supported by the hardware, setting it to 0 disables all hardware timeouts +and data should be reported as soon as possible. If the exact value +cannot be set, then the next possible value _greater_ than the +given value should be set. + +.. note:: + + The range of supported timeout is given by :ref:`LIRC_GET_MIN_TIMEOUT`. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-send-carrier.rst b/Documentation/media/uapi/rc/lirc-set-send-carrier.rst new file mode 100644 index 0000000000000000000000000000000000000000..4314d4c86ced23cf873e99b7f489611ab08fd350 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-send-carrier.rst @@ -0,0 +1,43 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_send_carrier: + +*************************** +ioctl LIRC_SET_SEND_CARRIER +*************************** + +Name +==== + +LIRC_SET_SEND_CARRIER - Set send carrier used to modulate IR TX. + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_SEND_CARRIER + +``frequency`` + Frequency of the carrier to be modulated, in Hz. + +Description +=========== + +Set send carrier used to modulate IR PWM pulses and spaces. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst b/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst new file mode 100644 index 0000000000000000000000000000000000000000..48e7bb15fb6906da0c96d1e1cc9be497384e243a --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_send_duty_cycle: + +****************************** +ioctl LIRC_SET_SEND_DUTY_CYCLE +****************************** + +Name +==== + +LIRC_SET_SEND_DUTY_CYCLE - Set the duty cycle of the carrier signal for +IR transmit. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *duty_cycle) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_SEND_DUTY_CYCLE + +``duty_cycle`` + Duty cicle, describing the pulse width in percent (from 1 to 99) of + the total cycle. Values 0 and 100 are reserved. + + +Description +=========== + +Get/set the duty cycle of the carrier signal for IR transmit. + +Currently, no special meaning is defined for 0 or 100, but this +could be used to switch off carrier generation in the future, so +these values should be reserved. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst b/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst new file mode 100644 index 0000000000000000000000000000000000000000..2b35e21b9bb954f6f3db63c0abc54531d26d757d --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst @@ -0,0 +1,53 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_transmitter_mask: + +******************************* +ioctl LIRC_SET_TRANSMITTER_MASK +******************************* + +Name +==== + +LIRC_SET_TRANSMITTER_MASK - Enables send codes on a given set of transmitters + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *mask ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_TRANSMITTER_MASK + +``mask`` + Mask with channels to enable tx. Channel 0 is the least significant bit. + + +Description +=========== + +Some IR TX devices have multiple output channels, in such case, +:ref:`LIRC_CAN_SET_TRANSMITTER_MASK ` is +returned via :ref:`LIRC_GET_FEATURES` and this ioctl sets what channels will +send IR codes. + +This ioctl enables the given set of transmitters. The first transmitter is +encoded by the least significant bit and so on. + +When an invalid bit mask is given, i.e. a bit is set, even though the device +does not have so many transitters, then this ioctl returns the number of +available transitters and does nothing otherwise. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst b/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst new file mode 100644 index 0000000000000000000000000000000000000000..cffb01fd1042c594bf8e3c9fa9b6bcc15acf7bc4 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst @@ -0,0 +1,56 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc_set_wideband_receiver: + +******************************** +ioctl LIRC_SET_WIDEBAND_RECEIVER +******************************** + +Name +==== + +LIRC_SET_WIDEBAND_RECEIVER - enable wide band receiver. + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *enable ) + +Arguments +========= + +``fd`` + File descriptor returned by open(). + +``request`` + LIRC_SET_WIDEBAND_RECEIVER + +``enable`` + enable = 1 means enable wideband receiver, enable = 0 means disable + wideband receiver. + + +Description +=========== + +Some receivers are equipped with special wide band receiver which is +intended to be used to learn output of existing remote. This ioctl +allows enabling or disabling it. + +This might be useful of receivers that have otherwise narrow band receiver +that prevents them to be used with some remotes. Wide band receiver might +also be more precise. On the other hand its disadvantage it usually +reduced range of reception. + +.. note:: Wide band receiver might be implictly enabled if you enable + carrier reports. In that case it will be disabled as soon as you disable + carrier reports. Trying to disable wide band receiver while carrier + reports are active will do nothing. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/lirc-write.rst b/Documentation/media/uapi/rc/lirc-write.rst new file mode 100644 index 0000000000000000000000000000000000000000..dcba3b1bee6ec1f397de0d59f942d74c797fda97 --- /dev/null +++ b/Documentation/media/uapi/rc/lirc-write.rst @@ -0,0 +1,58 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _lirc-write: + +************ +LIRC write() +************ + +Name +==== + +lirc-write - Write to a LIRC device + + +Synopsis +======== + +.. code-block:: c + + #include + + +.. cpp:function:: ssize_t write( int fd, void *buf, size_t count ) + + +Arguments +========= + +``fd`` + File descriptor returned by ``open()``. + +``buf`` +``count`` + + +Description +=========== + +:ref:`write() ` writes up to ``count`` bytes to the device +referenced by the file descriptor ``fd`` from the buffer starting at +``buf``. + +The data written to the chardev is a pulse/space sequence of integer +values. Pulses and spaces are only marked implicitly by their position. +The data must start and end with a pulse, therefore, the data must +always include an uneven number of samples. The write function must +block until the data has been transmitted by the hardware. If more data +is provided than the hardware can send, the driver returns ``EINVAL``. + + +Return Value +============ + +On success, the number of bytes read is returned. It is not an error if +this number is smaller than the number of bytes requested, or the amount +of data required for one frame. On error, -1 is returned, and the ``errno`` +variable is set appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. diff --git a/Documentation/media/uapi/rc/rc-intro.rst b/Documentation/media/uapi/rc/rc-intro.rst new file mode 100644 index 0000000000000000000000000000000000000000..3707c29d37eddd43696652ac004dc7eb2fd14217 --- /dev/null +++ b/Documentation/media/uapi/rc/rc-intro.rst @@ -0,0 +1,24 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _Remote_controllers_Intro: + +************ +Introduction +************ + +Currently, most analog and digital devices have a Infrared input for +remote controllers. Each manufacturer has their own type of control. It +is not rare for the same manufacturer to ship different types of +controls, depending on the device. + +A Remote Controller interface is mapped as a normal evdev/input +interface, just like a keyboard or a mouse. So, it uses all ioctls +already defined for any other input devices. + +However, remove controllers are more flexible than a normal input +device, as the IR receiver (and/or transmitter) can be used in +conjunction with a wide variety of different IR remotes. + +In order to allow flexibility, the Remote Controller subsystem allows +controlling the RC-specific attributes via +:ref:`the sysfs class nodes `. diff --git a/Documentation/media/uapi/rc/rc-sysfs-nodes.rst b/Documentation/media/uapi/rc/rc-sysfs-nodes.rst new file mode 100644 index 0000000000000000000000000000000000000000..6fb944fe21fdb49e4c8b72887e759a557f03b749 --- /dev/null +++ b/Documentation/media/uapi/rc/rc-sysfs-nodes.rst @@ -0,0 +1,143 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _remote_controllers_sysfs_nodes: + +******************************* +Remote Controller's sysfs nodes +******************************* + +As defined at ``Documentation/ABI/testing/sysfs-class-rc``, those are +the sysfs nodes that control the Remote Controllers: + + +.. _sys_class_rc: + +/sys/class/rc/ +============== + +The ``/sys/class/rc/`` class sub-directory belongs to the Remote +Controller core and provides a sysfs interface for configuring infrared +remote controller receivers. + + +.. _sys_class_rc_rcN: + +/sys/class/rc/rcN/ +================== + +A ``/sys/class/rc/rcN`` directory is created for each remote control +receiver device where N is the number of the receiver. + + +.. _sys_class_rc_rcN_protocols: + +/sys/class/rc/rcN/protocols +=========================== + +Reading this file returns a list of available protocols, something like: + +``rc5 [rc6] nec jvc [sony]`` + +Enabled protocols are shown in [] brackets. + +Writing "+proto" will add a protocol to the list of enabled protocols. + +Writing "-proto" will remove a protocol from the list of enabled +protocols. + +Writing "proto" will enable only "proto". + +Writing "none" will disable all protocols. + +Write fails with ``EINVAL`` if an invalid protocol combination or unknown +protocol name is used. + + +.. _sys_class_rc_rcN_filter: + +/sys/class/rc/rcN/filter +======================== + +Sets the scancode filter expected value. + +Use in combination with ``/sys/class/rc/rcN/filter_mask`` to set the +expected value of the bits set in the filter mask. If the hardware +supports it then scancodes which do not match the filter will be +ignored. Otherwise the write will fail with an error. + +This value may be reset to 0 if the current protocol is altered. + + +.. _sys_class_rc_rcN_filter_mask: + +/sys/class/rc/rcN/filter_mask +============================= + +Sets the scancode filter mask of bits to compare. Use in combination +with ``/sys/class/rc/rcN/filter`` to set the bits of the scancode which +should be compared against the expected value. A value of 0 disables the +filter to allow all valid scancodes to be processed. + +If the hardware supports it then scancodes which do not match the filter +will be ignored. Otherwise the write will fail with an error. + +This value may be reset to 0 if the current protocol is altered. + + +.. _sys_class_rc_rcN_wakeup_protocols: + +/sys/class/rc/rcN/wakeup_protocols +================================== + +Reading this file returns a list of available protocols to use for the +wakeup filter, something like: + +``rc5 rc6 nec jvc [sony]`` + +The enabled wakeup protocol is shown in [] brackets. + +Writing "+proto" will add a protocol to the list of enabled wakeup +protocols. + +Writing "-proto" will remove a protocol from the list of enabled wakeup +protocols. + +Writing "proto" will use "proto" for wakeup events. + +Writing "none" will disable wakeup. + +Write fails with ``EINVAL`` if an invalid protocol combination or unknown +protocol name is used, or if wakeup is not supported by the hardware. + + +.. _sys_class_rc_rcN_wakeup_filter: + +/sys/class/rc/rcN/wakeup_filter +=============================== + +Sets the scancode wakeup filter expected value. Use in combination with +``/sys/class/rc/rcN/wakeup_filter_mask`` to set the expected value of +the bits set in the wakeup filter mask to trigger a system wake event. + +If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. suspend +to RAM or power off. Otherwise the write will fail with an error. + +This value may be reset to 0 if the wakeup protocol is altered. + + +.. _sys_class_rc_rcN_wakeup_filter_mask: + +/sys/class/rc/rcN/wakeup_filter_mask +==================================== + +Sets the scancode wakeup filter mask of bits to compare. Use in +combination with ``/sys/class/rc/rcN/wakeup_filter`` to set the bits of +the scancode which should be compared against the expected value to +trigger a system wake event. + +If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. suspend +to RAM or power off. Otherwise the write will fail with an error. + +This value may be reset to 0 if the wakeup protocol is altered. diff --git a/Documentation/media/uapi/rc/rc-table-change.rst b/Documentation/media/uapi/rc/rc-table-change.rst new file mode 100644 index 0000000000000000000000000000000000000000..d604896bca8783f048b7a45760f731c0d2139652 --- /dev/null +++ b/Documentation/media/uapi/rc/rc-table-change.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _Remote_controllers_table_change: + +******************************************* +Changing default Remote Controller mappings +******************************************* + +The event interface provides two ioctls to be used against the +/dev/input/event device, to allow changing the default keymapping. + +This program demonstrates how to replace the keymap tables. + + +.. toctree:: + :maxdepth: 1 + + keytable.c diff --git a/Documentation/media/uapi/rc/rc-tables.rst b/Documentation/media/uapi/rc/rc-tables.rst new file mode 100644 index 0000000000000000000000000000000000000000..0bb16c4af27d5672a46f877fba7356d48552562c --- /dev/null +++ b/Documentation/media/uapi/rc/rc-tables.rst @@ -0,0 +1,757 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _Remote_controllers_tables: + +************************ +Remote controller tables +************************ + +Unfortunately, for several years, there was no effort to create uniform +IR keycodes for different devices. This caused the same IR keyname to be +mapped completely differently on different IR devices. This resulted +that the same IR keyname to be mapped completely different on different +IR's. Due to that, V4L2 API now specifies a standard for mapping Media +keys on IR. + +This standard should be used by both V4L/DVB drivers and userspace +applications + +The modules register the remote as keyboard within the linux input +layer. This means that the IR key strokes will look like normal keyboard +key strokes (if CONFIG_INPUT_KEYBOARD is enabled). Using the event +devices (CONFIG_INPUT_EVDEV) it is possible for applications to access +the remote via /dev/input/event devices. + + +.. _rc_standard_keymap: + +.. flat-table:: IR default keymapping + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - Key code + + - Meaning + + - Key examples on IR + + - .. row 2 + + - **Numeric keys** + + - .. row 3 + + - ``KEY_0`` + + - Keyboard digit 0 + + - 0 + + - .. row 4 + + - ``KEY_1`` + + - Keyboard digit 1 + + - 1 + + - .. row 5 + + - ``KEY_2`` + + - Keyboard digit 2 + + - 2 + + - .. row 6 + + - ``KEY_3`` + + - Keyboard digit 3 + + - 3 + + - .. row 7 + + - ``KEY_4`` + + - Keyboard digit 4 + + - 4 + + - .. row 8 + + - ``KEY_5`` + + - Keyboard digit 5 + + - 5 + + - .. row 9 + + - ``KEY_6`` + + - Keyboard digit 6 + + - 6 + + - .. row 10 + + - ``KEY_7`` + + - Keyboard digit 7 + + - 7 + + - .. row 11 + + - ``KEY_8`` + + - Keyboard digit 8 + + - 8 + + - .. row 12 + + - ``KEY_9`` + + - Keyboard digit 9 + + - 9 + + - .. row 13 + + - **Movie play control** + + - .. row 14 + + - ``KEY_FORWARD`` + + - Instantly advance in time + + - >> / FORWARD + + - .. row 15 + + - ``KEY_BACK`` + + - Instantly go back in time + + - <<< / BACK + + - .. row 16 + + - ``KEY_FASTFORWARD`` + + - Play movie faster + + - >>> / FORWARD + + - .. row 17 + + - ``KEY_REWIND`` + + - Play movie back + + - REWIND / BACKWARD + + - .. row 18 + + - ``KEY_NEXT`` + + - Select next chapter / sub-chapter / interval + + - NEXT / SKIP + + - .. row 19 + + - ``KEY_PREVIOUS`` + + - Select previous chapter / sub-chapter / interval + + - << / PREV / PREVIOUS + + - .. row 20 + + - ``KEY_AGAIN`` + + - Repeat the video or a video interval + + - REPEAT / LOOP / RECALL + + - .. row 21 + + - ``KEY_PAUSE`` + + - Pause sroweam + + - PAUSE / FREEZE + + - .. row 22 + + - ``KEY_PLAY`` + + - Play movie at the normal timeshift + + - NORMAL TIMESHIFT / LIVE / > + + - .. row 23 + + - ``KEY_PLAYPAUSE`` + + - Alternate between play and pause + + - PLAY / PAUSE + + - .. row 24 + + - ``KEY_STOP`` + + - Stop sroweam + + - STOP + + - .. row 25 + + - ``KEY_RECORD`` + + - Start/stop recording sroweam + + - CAPTURE / REC / RECORD/PAUSE + + - .. row 26 + + - ``KEY_CAMERA`` + + - Take a picture of the image + + - CAMERA ICON / CAPTURE / SNAPSHOT + + - .. row 27 + + - ``KEY_SHUFFLE`` + + - Enable shuffle mode + + - SHUFFLE + + - .. row 28 + + - ``KEY_TIME`` + + - Activate time shift mode + + - TIME SHIFT + + - .. row 29 + + - ``KEY_TITLE`` + + - Allow changing the chapter + + - CHAPTER + + - .. row 30 + + - ``KEY_SUBTITLE`` + + - Allow changing the subtitle + + - SUBTITLE + + - .. row 31 + + - **Image control** + + - .. row 32 + + - ``KEY_BRIGHTNESSDOWN`` + + - Decrease Brightness + + - BRIGHTNESS DECREASE + + - .. row 33 + + - ``KEY_BRIGHTNESSUP`` + + - Increase Brightness + + - BRIGHTNESS INCREASE + + - .. row 34 + + - ``KEY_ANGLE`` + + - Switch video camera angle (on videos with more than one angle + stored) + + - ANGLE / SWAP + + - .. row 35 + + - ``KEY_EPG`` + + - Open the Elecrowonic Play Guide (EPG) + + - EPG / GUIDE + + - .. row 36 + + - ``KEY_TEXT`` + + - Activate/change closed caption mode + + - CLOSED CAPTION/TELETEXT / DVD TEXT / TELETEXT / TTX + + - .. row 37 + + - **Audio control** + + - .. row 38 + + - ``KEY_AUDIO`` + + - Change audio source + + - AUDIO SOURCE / AUDIO / MUSIC + + - .. row 39 + + - ``KEY_MUTE`` + + - Mute/unmute audio + + - MUTE / DEMUTE / UNMUTE + + - .. row 40 + + - ``KEY_VOLUMEDOWN`` + + - Decrease volume + + - VOLUME- / VOLUME DOWN + + - .. row 41 + + - ``KEY_VOLUMEUP`` + + - Increase volume + + - VOLUME+ / VOLUME UP + + - .. row 42 + + - ``KEY_MODE`` + + - Change sound mode + + - MONO/STEREO + + - .. row 43 + + - ``KEY_LANGUAGE`` + + - Select Language + + - 1ST / 2ND LANGUAGE / DVD LANG / MTS/SAP / MTS SEL + + - .. row 44 + + - **Channel control** + + - .. row 45 + + - ``KEY_CHANNEL`` + + - Go to the next favorite channel + + - ALT / CHANNEL / CH SURFING / SURF / FAV + + - .. row 46 + + - ``KEY_CHANNELDOWN`` + + - Decrease channel sequencially + + - CHANNEL - / CHANNEL DOWN / DOWN + + - .. row 47 + + - ``KEY_CHANNELUP`` + + - Increase channel sequencially + + - CHANNEL + / CHANNEL UP / UP + + - .. row 48 + + - ``KEY_DIGITS`` + + - Use more than one digit for channel + + - PLUS / 100/ 1xx / xxx / -/-- / Single Double Triple Digit + + - .. row 49 + + - ``KEY_SEARCH`` + + - Start channel autoscan + + - SCAN / AUTOSCAN + + - .. row 50 + + - **Colored keys** + + - .. row 51 + + - ``KEY_BLUE`` + + - IR Blue key + + - BLUE + + - .. row 52 + + - ``KEY_GREEN`` + + - IR Green Key + + - GREEN + + - .. row 53 + + - ``KEY_RED`` + + - IR Red key + + - RED + + - .. row 54 + + - ``KEY_YELLOW`` + + - IR Yellow key + + - YELLOW + + - .. row 55 + + - **Media selection** + + - .. row 56 + + - ``KEY_CD`` + + - Change input source to Compact Disc + + - CD + + - .. row 57 + + - ``KEY_DVD`` + + - Change input to DVD + + - DVD / DVD MENU + + - .. row 58 + + - ``KEY_EJECTCLOSECD`` + + - Open/close the CD/DVD player + + - -> ) / CLOSE / OPEN + + - .. row 59 + + - ``KEY_MEDIA`` + + - Turn on/off Media application + + - PC/TV / TURN ON/OFF APP + + - .. row 60 + + - ``KEY_PC`` + + - Selects from TV to PC + + - PC + + - .. row 61 + + - ``KEY_RADIO`` + + - Put into AM/FM radio mode + + - RADIO / TV/FM / TV/RADIO / FM / FM/RADIO + + - .. row 62 + + - ``KEY_TV`` + + - Select tv mode + + - TV / LIVE TV + + - .. row 63 + + - ``KEY_TV2`` + + - Select Cable mode + + - AIR/CBL + + - .. row 64 + + - ``KEY_VCR`` + + - Select VCR mode + + - VCR MODE / DTR + + - .. row 65 + + - ``KEY_VIDEO`` + + - Alternate between input modes + + - SOURCE / SELECT / DISPLAY / SWITCH INPUTS / VIDEO + + - .. row 66 + + - **Power control** + + - .. row 67 + + - ``KEY_POWER`` + + - Turn on/off computer + + - SYSTEM POWER / COMPUTER POWER + + - .. row 68 + + - ``KEY_POWER2`` + + - Turn on/off application + + - TV ON/OFF / POWER + + - .. row 69 + + - ``KEY_SLEEP`` + + - Activate sleep timer + + - SLEEP / SLEEP TIMER + + - .. row 70 + + - ``KEY_SUSPEND`` + + - Put computer into suspend mode + + - STANDBY / SUSPEND + + - .. row 71 + + - **Window control** + + - .. row 72 + + - ``KEY_CLEAR`` + + - Stop sroweam and return to default input video/audio + + - CLEAR / RESET / BOSS KEY + + - .. row 73 + + - ``KEY_CYCLEWINDOWS`` + + - Minimize windows and move to the next one + + - ALT-TAB / MINIMIZE / DESKTOP + + - .. row 74 + + - ``KEY_FAVORITES`` + + - Open the favorites sroweam window + + - TV WALL / Favorites + + - .. row 75 + + - ``KEY_MENU`` + + - Call application menu + + - 2ND CONTROLS (USA: MENU) / DVD/MENU / SHOW/HIDE CTRL + + - .. row 76 + + - ``KEY_NEW`` + + - Open/Close Picture in Picture + + - PIP + + - .. row 77 + + - ``KEY_OK`` + + - Send a confirmation code to application + + - OK / ENTER / RETURN + + - .. row 78 + + - ``KEY_SCREEN`` + + - Select screen aspect ratio + + - 4:3 16:9 SELECT + + - .. row 79 + + - ``KEY_ZOOM`` + + - Put device into zoom/full screen mode + + - ZOOM / FULL SCREEN / ZOOM+ / HIDE PANNEL / SWITCH + + - .. row 80 + + - **Navigation keys** + + - .. row 81 + + - ``KEY_ESC`` + + - Cancel current operation + + - CANCEL / BACK + + - .. row 82 + + - ``KEY_HELP`` + + - Open a Help window + + - HELP + + - .. row 83 + + - ``KEY_HOMEPAGE`` + + - Navigate to Homepage + + - HOME + + - .. row 84 + + - ``KEY_INFO`` + + - Open On Screen Display + + - DISPLAY INFORMATION / OSD + + - .. row 85 + + - ``KEY_WWW`` + + - Open the default browser + + - WEB + + - .. row 86 + + - ``KEY_UP`` + + - Up key + + - UP + + - .. row 87 + + - ``KEY_DOWN`` + + - Down key + + - DOWN + + - .. row 88 + + - ``KEY_LEFT`` + + - Left key + + - LEFT + + - .. row 89 + + - ``KEY_RIGHT`` + + - Right key + + - RIGHT + + - .. row 90 + + - **Miscellaneous keys** + + - .. row 91 + + - ``KEY_DOT`` + + - Return a dot + + - . + + - .. row 92 + + - ``KEY_FN`` + + - Select a function + + - FUNCTION + + +It should be noted that, sometimes, there some fundamental missing keys +at some cheaper IR's. Due to that, it is recommended to: + + +.. _rc_keymap_notes: + +.. flat-table:: Notes + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - On simpler IR's, without separate channel keys, you need to map UP + as ``KEY_CHANNELUP`` + + - .. row 2 + + - On simpler IR's, without separate channel keys, you need to map + DOWN as ``KEY_CHANNELDOWN`` + + - .. row 3 + + - On simpler IR's, without separate volume keys, you need to map + LEFT as ``KEY_VOLUMEDOWN`` + + - .. row 4 + + - On simpler IR's, without separate volume keys, you need to map + RIGHT as ``KEY_VOLUMEUP`` diff --git a/Documentation/media/uapi/rc/remote_controllers.rst b/Documentation/media/uapi/rc/remote_controllers.rst new file mode 100644 index 0000000000000000000000000000000000000000..3e25cc9f65e0a19638bdcccec5390d0c287c3d5c --- /dev/null +++ b/Documentation/media/uapi/rc/remote_controllers.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: + +.. _remote_controllers: + +################################ +Part III - Remote Controller API +################################ + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 5 + :numbered: + + rc-intro + rc-sysfs-nodes + rc-tables + rc-table-change + lirc-dev + + +********************** +Revision and Copyright +********************** + +Authors: + +- Carvalho Chehab, Mauro + + - Initial version. + +**Copyright** |copy| 2009-2016 : Mauro Carvalho Chehab + +**************** +Revision History +**************** + +:revision: 3.15 / 2014-02-06 (*mcc*) + +Added the interface description and the RC sysfs class description. + + +:revision: 1.0 / 2009-09-06 (*mcc*) + +Initial revision diff --git a/Documentation/media/uapi/v4l/app-pri.rst b/Documentation/media/uapi/v4l/app-pri.rst new file mode 100644 index 0000000000000000000000000000000000000000..a8c41a7ec3965df56bcaf25ab5479e0bf83378e3 --- /dev/null +++ b/Documentation/media/uapi/v4l/app-pri.rst @@ -0,0 +1,30 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _app-pri: + +******************** +Application Priority +******************** + +When multiple applications share a device it may be desirable to assign +them different priorities. Contrary to the traditional "rm -rf /" school +of thought a video recording application could for example block other +applications from changing video controls or switching the current TV +channel. Another objective is to permit low priority applications +working in background, which can be preempted by user controlled +applications and automatically regain control of the device at a later +time. + +Since these features cannot be implemented entirely in user space V4L2 +defines the :ref:`VIDIOC_G_PRIORITY ` and +:ref:`VIDIOC_S_PRIORITY ` ioctls to request and +query the access priority associate with a file descriptor. Opening a +device assigns a medium priority, compatible with earlier versions of +V4L2 and drivers not supporting these ioctls. Applications requiring a +different priority will usually call :ref:`VIDIOC_S_PRIORITY +` after verifying the device with the +:ref:`VIDIOC_QUERYCAP` ioctl. + +Ioctls changing driver properties, such as +:ref:`VIDIOC_S_INPUT `, return an ``EBUSY`` error code +after another application obtained higher priority. diff --git a/Documentation/media/uapi/v4l/async.rst b/Documentation/media/uapi/v4l/async.rst new file mode 100644 index 0000000000000000000000000000000000000000..5affc0adb95b66578157b18f587cd08676ac62b5 --- /dev/null +++ b/Documentation/media/uapi/v4l/async.rst @@ -0,0 +1,9 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _async: + +**************** +Asynchronous I/O +**************** + +This method is not defined yet. diff --git a/Documentation/media/uapi/v4l/audio.rst b/Documentation/media/uapi/v4l/audio.rst new file mode 100644 index 0000000000000000000000000000000000000000..4dd11345866c996d353ab2c575675dd904882315 --- /dev/null +++ b/Documentation/media/uapi/v4l/audio.rst @@ -0,0 +1,95 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _audio: + +************************ +Audio Inputs and Outputs +************************ + +Audio inputs and outputs are physical connectors of a device. Video +capture devices have inputs, output devices have outputs, zero or more +each. Radio devices have no audio inputs or outputs. They have exactly +one tuner which in fact *is* an audio source, but this API associates +tuners with video inputs or outputs only, and radio devices have none of +these. [#f1]_ A connector on a TV card to loop back the received audio +signal to a sound card is not considered an audio output. + +Audio and video inputs and outputs are associated. Selecting a video +source also selects an audio source. This is most evident when the video +and audio source is a tuner. Further audio connectors can combine with +more than one video input or output. Assumed two composite video inputs +and two audio inputs exist, there may be up to four valid combinations. +The relation of video and audio connectors is defined in the +``audioset`` field of the respective struct +:ref:`v4l2_input ` or struct +:ref:`v4l2_output `, where each bit represents the index +number, starting at zero, of one audio input or output. + +To learn about the number and attributes of the available inputs and +outputs applications can enumerate them with the +:ref:`VIDIOC_ENUMAUDIO` and +:ref:`VIDIOC_ENUMAUDOUT ` ioctl, respectively. +The struct :ref:`v4l2_audio ` returned by the +:ref:`VIDIOC_ENUMAUDIO` ioctl also contains signal +:status information applicable when the current audio input is queried. + +The :ref:`VIDIOC_G_AUDIO ` and +:ref:`VIDIOC_G_AUDOUT ` ioctls report the current +audio input and output, respectively. + +.. note:: Note that, unlike :ref:`VIDIOC_G_INPUT ` and + :ref:`VIDIOC_G_OUTPUT ` these ioctls return a + structure as :ref:`VIDIOC_ENUMAUDIO` and + :ref:`VIDIOC_ENUMAUDOUT ` do, not just an index. + +To select an audio input and change its properties applications call the +:ref:`VIDIOC_S_AUDIO ` ioctl. To select an audio +output (which presently has no changeable properties) applications call +the :ref:`VIDIOC_S_AUDOUT ` ioctl. + +Drivers must implement all audio input ioctls when the device has +multiple selectable audio inputs, all audio output ioctls when the +device has multiple selectable audio outputs. When the device has any +audio inputs or outputs the driver must set the ``V4L2_CAP_AUDIO`` flag +in the struct :ref:`v4l2_capability ` returned by +the :ref:`VIDIOC_QUERYCAP` ioctl. + + +Example: Information about the current audio input +================================================== + +.. code-block:: c + + struct v4l2_audio audio; + + memset(&audio, 0, sizeof(audio)); + + if (-1 == ioctl(fd, VIDIOC_G_AUDIO, &audio)) { + perror("VIDIOC_G_AUDIO"); + exit(EXIT_FAILURE); + } + + printf("Current input: %s\\n", audio.name); + + +Example: Switching to the first audio input +=========================================== + +.. code-block:: c + + struct v4l2_audio audio; + + memset(&audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */ + + audio.index = 0; + + if (-1 == ioctl(fd, VIDIOC_S_AUDIO, &audio)) { + perror("VIDIOC_S_AUDIO"); + exit(EXIT_FAILURE); + } + +.. [#f1] + Actually struct :ref:`v4l2_audio ` ought to have a + ``tuner`` field like struct :ref:`v4l2_input `, not + only making the API more consistent but also permitting radio devices + with multiple tuners. diff --git a/Documentation/media/uapi/v4l/biblio.rst b/Documentation/media/uapi/v4l/biblio.rst new file mode 100644 index 0000000000000000000000000000000000000000..1cedcfc043273d9fa16c5d39c25a29b4f8f3667a --- /dev/null +++ b/Documentation/media/uapi/v4l/biblio.rst @@ -0,0 +1,391 @@ +.. -*- coding: utf-8; mode: rst -*- + +********** +References +********** + + +.. _cea608: + +CEA 608-E +========= + + +:title: CEA-608-E R-2014 "Line 21 Data Services" + +:author: Consumer Electronics Association (http://www.ce.org) + +.. _en300294: + +EN 300 294 +========== + + +:title: EN 300 294 "625-line television Wide Screen Signalling (WSS)" + +:author: European Telecommunication Standards Institute (http://www.etsi.org) + +.. _ets300231: + +ETS 300 231 +=========== + + +:title: ETS 300 231 "Specification of the domestic video Programme Delivery Control system (PDC)" + +:author: European Telecommunication Standards Institute (http://www.etsi.org) + +.. _ets300706: + +ETS 300 706 +=========== + + +:title: ETS 300 706 "Enhanced Teletext specification" + +:author: European Telecommunication Standards Institute (http://www.etsi.org) + +.. _mpeg2part1: + +ISO 13818-1 +=========== + + +:title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology — Generic coding of moving pictures and associated audio information: Systems" + +:author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) + +.. _mpeg2part2: + +ISO 13818-2 +=========== + + +:title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology — Generic coding of moving pictures and associated audio information: Video" + +:author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) + +.. _itu470: + +ITU BT.470 +========== + + +:title: ITU-R Recommendation BT.470-6 "Conventional Television Systems" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _itu601: + +ITU BT.601 +========== + + +:title: ITU-R Recommendation BT.601-5 "Studio Encoding Parameters of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _itu653: + +ITU BT.653 +========== + + +:title: ITU-R Recommendation BT.653-3 "Teletext systems" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _itu709: + +ITU BT.709 +========== + + +:title: ITU-R Recommendation BT.709-5 "Parameter values for the HDTV standards for production and international programme exchange" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _itu1119: + +ITU BT.1119 +=========== + + +:title: ITU-R Recommendation BT.1119 "625-line television Wide Screen Signalling (WSS)" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _jfif: + +JFIF +==== + + +:title: JPEG File Interchange Format +:subtitle: Version 1.02 + +:author: Independent JPEG Group (http://www.ijg.org) + +.. _itu-t81: + +ITU-T.81 +======== + + +:title: ITU-T Recommendation T.81 "Information Technology — Digital Compression and Coding of Continous-Tone Still Images — Requirements and Guidelines" + +:author: International Telecommunication Union (http://www.itu.int) + +.. _w3c-jpeg-jfif: + +W3C JPEG JFIF +============= + + +:title: JPEG JFIF + +:author: The World Wide Web Consortium (http://www.w3.org) + +.. _smpte12m: + +SMPTE 12M +========= + + +:title: SMPTE 12M-1999 "Television, Audio and Film - Time and Control Code" + +:author: Society of Motion Picture and Television Engineers (http://www.smpte.org) + +.. _smpte170m: + +SMPTE 170M +========== + + +:title: SMPTE 170M-1999 "Television - Composite Analog Video Signal - NTSC for Studio Applications" + +:author: Society of Motion Picture and Television Engineers (http://www.smpte.org) + +.. _smpte240m: + +SMPTE 240M +========== + + +:title: SMPTE 240M-1999 "Television - Signal Parameters - 1125-Line High-Definition Production" + +:author: Society of Motion Picture and Television Engineers (http://www.smpte.org) + +.. _smpte431: + +SMPTE RP 431-2 +============== + + +:title: SMPTE RP 431-2:2011 "D-Cinema Quality - Reference Projector and Environment" + +:author: Society of Motion Picture and Television Engineers (http://www.smpte.org) + +.. _smpte2084: + +SMPTE ST 2084 +============= + + +:title: SMPTE ST 2084:2014 "High Dynamic Range Electro-Optical Transfer Function of Master Reference Displays" + +:author: Society of Motion Picture and Television Engineers (http://www.smpte.org) + +.. _srgb: + +sRGB +==== + + +:title: IEC 61966-2-1 ed1.0 "Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB" + +:author: International Electrotechnical Commission (http://www.iec.ch) + +.. _sycc: + +sYCC +==== + + +:title: IEC 61966-2-1-am1 ed1.0 "Amendment 1 - Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB" + +:author: International Electrotechnical Commission (http://www.iec.ch) + +.. _xvycc: + +xvYCC +===== + + +:title: IEC 61966-2-4 ed1.0 "Multimedia systems and equipment - Colour measurement and management - Part 2-4: Colour management - Extended-gamut YCC colour space for video applications - xvYCC" + +:author: International Electrotechnical Commission (http://www.iec.ch) + +.. _adobergb: + +AdobeRGB +======== + + +:title: Adobe© RGB (1998) Color Image Encoding Version 2005-05 + +:author: Adobe Systems Incorporated (http://www.adobe.com) + +.. _oprgb: + +opRGB +===== + + +:title: IEC 61966-2-5 "Multimedia systems and equipment - Colour measurement and management - Part 2-5: Colour management - Optional RGB colour space - opRGB" + +:author: International Electrotechnical Commission (http://www.iec.ch) + +.. _itu2020: + +ITU BT.2020 +=========== + + +:title: ITU-R Recommendation BT.2020 (08/2012) "Parameter values for ultra-high definition television systems for production and international programme exchange" + +:author: International Telecommunication Union (http://www.itu.ch) + +.. _tech3213: + +EBU Tech 3213 +============= + + +:title: E.B.U. Standard for Chromaticity Tolerances for Studio Monitors" + +:author: European Broadcast Union (http://www.ebu.ch) + +.. _iec62106: + +IEC 62106 +========= + + +:title: Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz + +:author: International Electrotechnical Commission (http://www.iec.ch) + +.. _nrsc4: + +NRSC-4-B +======== + + +:title: NRSC-4-B: United States RBDS Standard + +:author: National Radio Systems Committee (http://www.nrscstandards.org) + +.. _iso12232: + +ISO 12232:2006 +============== + + +:title: Photography — Digital still cameras — Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index + +:author: International Organization for Standardization (http://www.iso.org) + +.. _cea861: + +CEA-861-E +========= + + +:title: A DTV Profile for Uncompressed High Speed Digital Interfaces + +:author: Consumer Electronics Association (http://www.ce.org) + +.. _vesadmt: + +VESA DMT +======== + + +:title: VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT) + +:author: Video Electronics Standards Association (http://www.vesa.org) + +.. _vesaedid: + +EDID +==== + + +:title: VESA Enhanced Extended Display Identification Data Standard +:subtitle: Release A, Revision 2 + +:author: Video Electronics Standards Association (http://www.vesa.org) + +.. _hdcp: + +HDCP +==== + + +:title: High-bandwidth Digital Content Protection System +:subtitle: Revision 1.3 + +:author: Digital Content Protection LLC (http://www.digital-cp.com) + +.. _hdmi: + +HDMI +==== + + +:title: High-Definition Multimedia Interface +:subtitle: Specification Version 1.4a + +:author: HDMI Licensing LLC (http://www.hdmi.org) + +.. _hdmi2: + +HDMI2 +===== + +:title: High-Definition Multimedia Interface +:subtitle: Specification Version 2.0 + +:author: HDMI Licensing LLC (http://www.hdmi.org) + +.. _dp: + +DP +== + + +:title: VESA DisplayPort Standard +:subtitle: Version 1, Revision 2 + +:author: Video Electronics Standards Association (http://www.vesa.org) + +.. _poynton: + +poynton +======= + + +:title: Digital Video and HDTV, Algorithms and Interfaces + +:author: Charles Poynton + +.. _colimg: + +colimg +====== + + +:title: Color Imaging: Fundamentals and Applications + +:author: Erik Reinhard et al. diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst new file mode 100644 index 0000000000000000000000000000000000000000..5deb4a46f99265d355be2b0c9a9b7e9bb1873fb6 --- /dev/null +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -0,0 +1,982 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _buffer: + +******* +Buffers +******* + +A buffer contains data exchanged by application and driver using one of +the Streaming I/O methods. In the multi-planar API, the data is held in +planes, while the buffer structure acts as a container for the planes. +Only pointers to buffers (planes) are exchanged, the data itself is not +copied. These pointers, together with meta-information like timestamps +or field parity, are stored in a struct :ref:`struct v4l2_buffer `, +argument to the :ref:`VIDIOC_QUERYBUF`, +:ref:`VIDIOC_QBUF` and +:ref:`VIDIOC_DQBUF ` ioctl. In the multi-planar API, +some plane-specific members of struct :ref:`struct v4l2_buffer `, +such as pointers and sizes for each plane, are stored in struct +:ref:`struct v4l2_plane ` instead. In that case, struct +:ref:`struct v4l2_buffer ` contains an array of plane structures. + +Dequeued video buffers come with timestamps. The driver decides at which +part of the frame and with which clock the timestamp is taken. Please +see flags in the masks ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` and +``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` in :ref:`buffer-flags`. These flags +are always valid and constant across all buffers during the whole video +stream. Changes in these flags may take place as a side effect of +:ref:`VIDIOC_S_INPUT ` or +:ref:`VIDIOC_S_OUTPUT ` however. The +``V4L2_BUF_FLAG_TIMESTAMP_COPY`` timestamp type which is used by e.g. on +mem-to-mem devices is an exception to the rule: the timestamp source +flags are copied from the OUTPUT video buffer to the CAPTURE video +buffer. + + +.. _v4l2-buffer: + +struct v4l2_buffer +================== + +.. flat-table:: struct v4l2_buffer + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 1 2 + + + - .. row 1 + + - __u32 + + - ``index`` + + - + - Number of the buffer, set by the application except when calling + :ref:`VIDIOC_DQBUF `, then it is set by the + driver. This field can range from zero to the number of buffers + allocated with the :ref:`VIDIOC_REQBUFS` ioctl + (struct :ref:`v4l2_requestbuffers ` + ``count``), plus any buffers allocated with + :ref:`VIDIOC_CREATE_BUFS` minus one. + + - .. row 2 + + - __u32 + + - ``type`` + + - + - Type of the buffer, same as struct + :ref:`v4l2_format ` ``type`` or struct + :ref:`v4l2_requestbuffers ` ``type``, set + by the application. See :ref:`v4l2-buf-type` + + - .. row 3 + + - __u32 + + - ``bytesused`` + + - + - The number of bytes occupied by the data in the buffer. It depends + on the negotiated data format and may change with each buffer for + compressed variable size data like JPEG images. Drivers must set + this field when ``type`` refers to a capture stream, applications + when it refers to an output stream. If the application sets this + to 0 for an output stream, then ``bytesused`` will be set to the + size of the buffer (see the ``length`` field of this struct) by + the driver. For multiplanar formats this field is ignored and the + ``planes`` pointer is used instead. + + - .. row 4 + + - __u32 + + - ``flags`` + + - + - Flags set by the application or driver, see :ref:`buffer-flags`. + + - .. row 5 + + - __u32 + + - ``field`` + + - + - Indicates the field order of the image in the buffer, see + :ref:`v4l2-field`. This field is not used when the buffer + contains VBI data. Drivers must set it when ``type`` refers to a + capture stream, applications when it refers to an output stream. + + - .. row 6 + + - struct timeval + + - ``timestamp`` + + - + - For capture streams this is time when the first data byte was + captured, as returned by the :c:func:`clock_gettime()` function + for the relevant clock id; see ``V4L2_BUF_FLAG_TIMESTAMP_*`` in + :ref:`buffer-flags`. For output streams the driver stores the + time at which the last data byte was actually sent out in the + ``timestamp`` field. This permits applications to monitor the + drift between the video and system clock. For output streams that + use ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` the application has to fill + in the timestamp which will be copied by the driver to the capture + stream. + + - .. row 7 + + - struct :ref:`v4l2_timecode ` + + - ``timecode`` + + - + - When ``type`` is ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` and the + ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this + structure contains a frame timecode. In + :ref:`V4L2_FIELD_ALTERNATE ` mode the top and + bottom field contain the same timecode. Timecodes are intended to + help video editing and are typically recorded on video tapes, but + also embedded in compressed formats like MPEG. This field is + independent of the ``timestamp`` and ``sequence`` fields. + + - .. row 8 + + - __u32 + + - ``sequence`` + + - + - Set by the driver, counting the frames (not fields!) in sequence. + This field is set for both input and output devices. + + - .. row 9 + + - :cspan:`3` + + In :ref:`V4L2_FIELD_ALTERNATE ` mode the top and + bottom field have the same sequence number. The count starts at + zero and includes dropped or repeated frames. A dropped frame was + received by an input device but could not be stored due to lack of + free buffer space. A repeated frame was displayed again by an + output device because the application did not pass new data in + time. + + .. note:: This may count the frames received e.g. over USB, without + taking into account the frames dropped by the remote hardware due + to limited compression throughput or bus bandwidth. These devices + identify by not enumerating any video standards, see + :ref:`standard`. + + - .. row 10 + + - __u32 + + - ``memory`` + + - + - This field must be set by applications and/or drivers in + accordance with the selected I/O method. See :ref:`v4l2-memory` + + - .. row 11 + + - union + + - ``m`` + + - .. row 12 + + - + - __u32 + + - ``offset`` + + - For the single-planar API and when ``memory`` is + ``V4L2_MEMORY_MMAP`` this is the offset of the buffer from the + start of the device memory. The value is returned by the driver + and apart of serving as parameter to the + :ref:`mmap() ` function not useful for applications. + See :ref:`mmap` for details + + - .. row 13 + + - + - unsigned long + + - ``userptr`` + + - For the single-planar API and when ``memory`` is + ``V4L2_MEMORY_USERPTR`` this is a pointer to the buffer (casted to + unsigned long type) in virtual memory, set by the application. See + :ref:`userp` for details. + + - .. row 14 + + - + - struct v4l2_plane + + - ``*planes`` + + - When using the multi-planar API, contains a userspace pointer to + an array of struct :ref:`v4l2_plane `. The size of + the array should be put in the ``length`` field of this + :ref:`struct v4l2_buffer ` structure. + + - .. row 15 + + - + - int + + - ``fd`` + + - For the single-plane API and when ``memory`` is + ``V4L2_MEMORY_DMABUF`` this is the file descriptor associated with + a DMABUF buffer. + + - .. row 16 + + - __u32 + + - ``length`` + + - + - Size of the buffer (not the payload) in bytes for the + single-planar API. This is set by the driver based on the calls to + :ref:`VIDIOC_REQBUFS` and/or + :ref:`VIDIOC_CREATE_BUFS`. For the + multi-planar API the application sets this to the number of + elements in the ``planes`` array. The driver will fill in the + actual number of valid elements in that array. + + - .. row 17 + + - __u32 + + - ``reserved2`` + + - + - A place holder for future extensions. Drivers and applications + must set this to 0. + + - .. row 18 + + - __u32 + + - ``reserved`` + + - + - A place holder for future extensions. Drivers and applications + must set this to 0. + + + +.. _v4l2-plane: + +struct v4l2_plane +================= + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 1 2 + + + - .. row 1 + + - __u32 + + - ``bytesused`` + + - + - The number of bytes occupied by data in the plane (its payload). + Drivers must set this field when ``type`` refers to a capture + stream, applications when it refers to an output stream. If the + application sets this to 0 for an output stream, then + ``bytesused`` will be set to the size of the plane (see the + ``length`` field of this struct) by the driver. + + .. note:: Note that the actual image data starts at ``data_offset`` + which may not be 0. + + - .. row 2 + + - __u32 + + - ``length`` + + - + - Size in bytes of the plane (not its payload). This is set by the + driver based on the calls to + :ref:`VIDIOC_REQBUFS` and/or + :ref:`VIDIOC_CREATE_BUFS`. + + - .. row 3 + + - union + + - ``m`` + + - + - + + - .. row 4 + + - + - __u32 + + - ``mem_offset`` + + - When the memory type in the containing struct + :ref:`v4l2_buffer ` is ``V4L2_MEMORY_MMAP``, this + is the value that should be passed to :ref:`mmap() `, + similar to the ``offset`` field in struct + :ref:`v4l2_buffer `. + + - .. row 5 + + - + - unsigned long + + - ``userptr`` + + - When the memory type in the containing struct + :ref:`v4l2_buffer ` is ``V4L2_MEMORY_USERPTR``, + this is a userspace pointer to the memory allocated for this plane + by an application. + + - .. row 6 + + - + - int + + - ``fd`` + + - When the memory type in the containing struct + :ref:`v4l2_buffer ` is ``V4L2_MEMORY_DMABUF``, + this is a file descriptor associated with a DMABUF buffer, similar + to the ``fd`` field in struct :ref:`v4l2_buffer `. + + - .. row 7 + + - __u32 + + - ``data_offset`` + + - + - Offset in bytes to video data in the plane. Drivers must set this + field when ``type`` refers to a capture stream, applications when + it refers to an output stream. + + .. note:: That data_offset is included in ``bytesused``. So the + size of the image in the plane is ``bytesused``-``data_offset`` + at offset ``data_offset`` from the start of the plane. + + - .. row 8 + + - __u32 + + - ``reserved[11]`` + + - + - Reserved for future use. Should be zeroed by drivers and + applications. + + + +.. _v4l2-buf-type: + +enum v4l2_buf_type +================== + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. row 1 + + - ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` + + - 1 + + - Buffer of a single-planar video capture stream, see + :ref:`capture`. + + - .. row 2 + + - ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` + + - 9 + + - Buffer of a multi-planar video capture stream, see + :ref:`capture`. + + - .. row 3 + + - ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` + + - 2 + + - Buffer of a single-planar video output stream, see + :ref:`output`. + + - .. row 4 + + - ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` + + - 10 + + - Buffer of a multi-planar video output stream, see :ref:`output`. + + - .. row 5 + + - ``V4L2_BUF_TYPE_VIDEO_OVERLAY`` + + - 3 + + - Buffer for video overlay, see :ref:`overlay`. + + - .. row 6 + + - ``V4L2_BUF_TYPE_VBI_CAPTURE`` + + - 4 + + - Buffer of a raw VBI capture stream, see :ref:`raw-vbi`. + + - .. row 7 + + - ``V4L2_BUF_TYPE_VBI_OUTPUT`` + + - 5 + + - Buffer of a raw VBI output stream, see :ref:`raw-vbi`. + + - .. row 8 + + - ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE`` + + - 6 + + - Buffer of a sliced VBI capture stream, see :ref:`sliced`. + + - .. row 9 + + - ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT`` + + - 7 + + - Buffer of a sliced VBI output stream, see :ref:`sliced`. + + - .. row 10 + + - ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY`` + + - 8 + + - Buffer for video output overlay (OSD), see :ref:`osd`. + + - .. row 11 + + - ``V4L2_BUF_TYPE_SDR_CAPTURE`` + + - 11 + + - Buffer for Software Defined Radio (SDR) capture stream, see + :ref:`sdr`. + + - .. row 12 + + - ``V4L2_BUF_TYPE_SDR_OUTPUT`` + + - 12 + + - Buffer for Software Defined Radio (SDR) output stream, see + :ref:`sdr`. + + + +.. _buffer-flags: + +Buffer Flags +============ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`V4L2-BUF-FLAG-MAPPED`: + + - ``V4L2_BUF_FLAG_MAPPED`` + + - 0x00000001 + + - The buffer resides in device memory and has been mapped into the + application's address space, see :ref:`mmap` for details. + Drivers set or clear this flag when the + :ref:`VIDIOC_QUERYBUF`, + :ref:`VIDIOC_QBUF` or + :ref:`VIDIOC_DQBUF ` ioctl is called. Set by the + driver. + + - .. _`V4L2-BUF-FLAG-QUEUED`: + + - ``V4L2_BUF_FLAG_QUEUED`` + + - 0x00000002 + + - Internally drivers maintain two buffer queues, an incoming and + outgoing queue. When this flag is set, the buffer is currently on + the incoming queue. It automatically moves to the outgoing queue + after the buffer has been filled (capture devices) or displayed + (output devices). Drivers set or clear this flag when the + ``VIDIOC_QUERYBUF`` ioctl is called. After (successful) calling + the ``VIDIOC_QBUF``\ ioctl it is always set and after + ``VIDIOC_DQBUF`` always cleared. + + - .. _`V4L2-BUF-FLAG-DONE`: + + - ``V4L2_BUF_FLAG_DONE`` + + - 0x00000004 + + - When this flag is set, the buffer is currently on the outgoing + queue, ready to be dequeued from the driver. Drivers set or clear + this flag when the ``VIDIOC_QUERYBUF`` ioctl is called. After + calling the ``VIDIOC_QBUF`` or ``VIDIOC_DQBUF`` it is always + cleared. Of course a buffer cannot be on both queues at the same + time, the ``V4L2_BUF_FLAG_QUEUED`` and ``V4L2_BUF_FLAG_DONE`` flag + are mutually exclusive. They can be both cleared however, then the + buffer is in "dequeued" state, in the application domain so to + say. + + - .. _`V4L2-BUF-FLAG-ERROR`: + + - ``V4L2_BUF_FLAG_ERROR`` + + - 0x00000040 + + - When this flag is set, the buffer has been dequeued successfully, + although the data might have been corrupted. This is recoverable, + streaming may continue as normal and the buffer may be reused + normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is + called. + + - .. _`V4L2-BUF-FLAG-KEYFRAME`: + + - ``V4L2_BUF_FLAG_KEYFRAME`` + + - 0x00000008 + + - Drivers set or clear this flag when calling the ``VIDIOC_DQBUF`` + ioctl. It may be set by video capture devices when the buffer + contains a compressed image which is a key frame (or field), i. e. + can be decompressed on its own. Also known as an I-frame. + Applications can set this bit when ``type`` refers to an output + stream. + + - .. _`V4L2-BUF-FLAG-PFRAME`: + + - ``V4L2_BUF_FLAG_PFRAME`` + + - 0x00000010 + + - Similar to ``V4L2_BUF_FLAG_KEYFRAME`` this flags predicted frames + or fields which contain only differences to a previous key frame. + Applications can set this bit when ``type`` refers to an output + stream. + + - .. _`V4L2-BUF-FLAG-BFRAME`: + + - ``V4L2_BUF_FLAG_BFRAME`` + + - 0x00000020 + + - Similar to ``V4L2_BUF_FLAG_KEYFRAME`` this flags a bi-directional + predicted frame or field which contains only the differences + between the current frame and both the preceding and following key + frames to specify its content. Applications can set this bit when + ``type`` refers to an output stream. + + - .. _`V4L2-BUF-FLAG-TIMECODE`: + + - ``V4L2_BUF_FLAG_TIMECODE`` + + - 0x00000100 + + - The ``timecode`` field is valid. Drivers set or clear this flag + when the ``VIDIOC_DQBUF`` ioctl is called. Applications can set + this bit and the corresponding ``timecode`` structure when + ``type`` refers to an output stream. + + - .. _`V4L2-BUF-FLAG-PREPARED`: + + - ``V4L2_BUF_FLAG_PREPARED`` + + - 0x00000400 + + - The buffer has been prepared for I/O and can be queued by the + application. Drivers set or clear this flag when the + :ref:`VIDIOC_QUERYBUF`, + :ref:`VIDIOC_PREPARE_BUF `, + :ref:`VIDIOC_QBUF` or + :ref:`VIDIOC_DQBUF ` ioctl is called. + + - .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`: + + - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` + + - 0x00000800 + + - Caches do not have to be invalidated for this buffer. Typically + applications shall use this flag if the data captured in the + buffer is not going to be touched by the CPU, instead the buffer + will, probably, be passed on to a DMA-capable hardware unit for + further processing or output. + + - .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`: + + - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` + + - 0x00001000 + + - Caches do not have to be cleaned for this buffer. Typically + applications shall use this flag for output buffers if the data in + this buffer has not been created by the CPU but by some + DMA-capable unit, in which case caches have not been used. + + - .. _`V4L2-BUF-FLAG-LAST`: + + - ``V4L2_BUF_FLAG_LAST`` + + - 0x00100000 + + - Last buffer produced by the hardware. mem2mem codec drivers set + this flag on the capture queue for the last buffer when the + :ref:`VIDIOC_QUERYBUF` or + :ref:`VIDIOC_DQBUF ` ioctl is called. Due to + hardware limitations, the last buffer may be empty. In this case + the driver will set the ``bytesused`` field to 0, regardless of + the format. Any Any subsequent call to the + :ref:`VIDIOC_DQBUF ` ioctl will not block anymore, + but return an ``EPIPE`` error code. + + - .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`: + + - ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` + + - 0x0000e000 + + - Mask for timestamp types below. To test the timestamp type, mask + out bits not belonging to timestamp type by performing a logical + and operation with buffer flags and timestamp mask. + + - .. _`V4L2-BUF-FLAG-TIMESTAMP-UNKNOWN`: + + - ``V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN`` + + - 0x00000000 + + - Unknown timestamp type. This type is used by drivers before Linux + 3.9 and may be either monotonic (see below) or realtime (wall + clock). Monotonic clock has been favoured in embedded systems + whereas most of the drivers use the realtime clock. Either kinds + of timestamps are available in user space via + :c:func:`clock_gettime(2)` using clock IDs ``CLOCK_MONOTONIC`` + and ``CLOCK_REALTIME``, respectively. + + - .. _`V4L2-BUF-FLAG-TIMESTAMP-MONOTONIC`: + + - ``V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC`` + + - 0x00002000 + + - The buffer timestamp has been taken from the ``CLOCK_MONOTONIC`` + clock. To access the same clock outside V4L2, use + :c:func:`clock_gettime(2)`. + + - .. _`V4L2-BUF-FLAG-TIMESTAMP-COPY`: + + - ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` + + - 0x00004000 + + - The CAPTURE buffer timestamp has been taken from the corresponding + OUTPUT buffer. This flag applies only to mem2mem devices. + + - .. _`V4L2-BUF-FLAG-TSTAMP-SRC-MASK`: + + - ``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` + + - 0x00070000 + + - Mask for timestamp sources below. The timestamp source defines the + point of time the timestamp is taken in relation to the frame. + Logical 'and' operation between the ``flags`` field and + ``V4L2_BUF_FLAG_TSTAMP_SRC_MASK`` produces the value of the + timestamp source. Applications must set the timestamp source when + ``type`` refers to an output stream and + ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` is set. + + - .. _`V4L2-BUF-FLAG-TSTAMP-SRC-EOF`: + + - ``V4L2_BUF_FLAG_TSTAMP_SRC_EOF`` + + - 0x00000000 + + - End Of Frame. The buffer timestamp has been taken when the last + pixel of the frame has been received or the last pixel of the + frame has been transmitted. In practice, software generated + timestamps will typically be read from the clock a small amount of + time after the last pixel has been received or transmitten, + depending on the system and other activity in it. + + - .. _`V4L2-BUF-FLAG-TSTAMP-SRC-SOE`: + + - ``V4L2_BUF_FLAG_TSTAMP_SRC_SOE`` + + - 0x00010000 + + - Start Of Exposure. The buffer timestamp has been taken when the + exposure of the frame has begun. This is only valid for the + ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type. + + + +.. _v4l2-memory: + +enum v4l2_memory +================ + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. row 1 + + - ``V4L2_MEMORY_MMAP`` + + - 1 + + - The buffer is used for :ref:`memory mapping ` I/O. + + - .. row 2 + + - ``V4L2_MEMORY_USERPTR`` + + - 2 + + - The buffer is used for :ref:`user pointer ` I/O. + + - .. row 3 + + - ``V4L2_MEMORY_OVERLAY`` + + - 3 + + - [to do] + + - .. row 4 + + - ``V4L2_MEMORY_DMABUF`` + + - 4 + + - The buffer is used for :ref:`DMA shared buffer ` I/O. + + + +Timecodes +========= + +The :ref:`struct v4l2_timecode ` structure is designed to hold a +:ref:`smpte12m` or similar timecode. (struct +:c:type:`struct timeval` timestamps are stored in struct +:ref:`v4l2_buffer ` field ``timestamp``.) + + +.. _v4l2-timecode: + +struct v4l2_timecode +-------------------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + + - .. row 1 + + - __u32 + + - ``type`` + + - Frame rate the timecodes are based on, see :ref:`timecode-type`. + + - .. row 2 + + - __u32 + + - ``flags`` + + - Timecode flags, see :ref:`timecode-flags`. + + - .. row 3 + + - __u8 + + - ``frames`` + + - Frame count, 0 ... 23/24/29/49/59, depending on the type of + timecode. + + - .. row 4 + + - __u8 + + - ``seconds`` + + - Seconds count, 0 ... 59. This is a binary, not BCD number. + + - .. row 5 + + - __u8 + + - ``minutes`` + + - Minutes count, 0 ... 59. This is a binary, not BCD number. + + - .. row 6 + + - __u8 + + - ``hours`` + + - Hours count, 0 ... 29. This is a binary, not BCD number. + + - .. row 7 + + - __u8 + + - ``userbits``\ [4] + + - The "user group" bits from the timecode. + + + +.. _timecode-type: + +Timecode Types +-------------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. row 1 + + - ``V4L2_TC_TYPE_24FPS`` + + - 1 + + - 24 frames per second, i. e. film. + + - .. row 2 + + - ``V4L2_TC_TYPE_25FPS`` + + - 2 + + - 25 frames per second, i. e. PAL or SECAM video. + + - .. row 3 + + - ``V4L2_TC_TYPE_30FPS`` + + - 3 + + - 30 frames per second, i. e. NTSC video. + + - .. row 4 + + - ``V4L2_TC_TYPE_50FPS`` + + - 4 + + - + + - .. row 5 + + - ``V4L2_TC_TYPE_60FPS`` + + - 5 + + - + + + +.. _timecode-flags: + +Timecode Flags +-------------- + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. row 1 + + - ``V4L2_TC_FLAG_DROPFRAME`` + + - 0x0001 + + - Indicates "drop frame" semantics for counting frames in 29.97 fps + material. When set, frame numbers 0 and 1 at the start of each + minute, except minutes 0, 10, 20, 30, 40, 50 are omitted from the + count. + + - .. row 2 + + - ``V4L2_TC_FLAG_COLORFRAME`` + + - 0x0002 + + - The "color frame" flag. + + - .. row 3 + + - ``V4L2_TC_USERBITS_field`` + + - 0x000C + + - Field mask for the "binary group flags". + + - .. row 4 + + - ``V4L2_TC_USERBITS_USERDEFINED`` + + - 0x0000 + + - Unspecified format. + + - .. row 5 + + - ``V4L2_TC_USERBITS_8BITCHARS`` + + - 0x0008 + + - 8-bit ISO characters. diff --git a/Documentation/media/uapi/v4l/capture-example.rst b/Documentation/media/uapi/v4l/capture-example.rst new file mode 100644 index 0000000000000000000000000000000000000000..ac1cd057e25b9646a674b0e13ca403245697bfb8 --- /dev/null +++ b/Documentation/media/uapi/v4l/capture-example.rst @@ -0,0 +1,13 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _capture-example: + +********************* +Video Capture Example +********************* + + +.. toctree:: + :maxdepth: 1 + + capture.c diff --git a/Documentation/media/uapi/v4l/capture.c.rst b/Documentation/media/uapi/v4l/capture.c.rst new file mode 100644 index 0000000000000000000000000000000000000000..56525a0fb2faf2ab532eaac1f47b59d093c67ef2 --- /dev/null +++ b/Documentation/media/uapi/v4l/capture.c.rst @@ -0,0 +1,664 @@ +.. -*- coding: utf-8; mode: rst -*- + +file: media/v4l/capture.c +========================= + +.. code-block:: c + + /* + * V4L2 video capture example + * + * This program can be used and distributed without restrictions. + * + * This program is provided with the V4L2 API + * see https://linuxtv.org/docs.php for more information + */ + + #include + #include + #include + #include + + #include /* getopt_long() */ + + #include /* low-level i/o */ + #include + #include + #include + #include + #include + #include + #include + + #include + + #define CLEAR(x) memset(&(x), 0, sizeof(x)) + + enum io_method { + IO_METHOD_READ, + IO_METHOD_MMAP, + IO_METHOD_USERPTR, + }; + + struct buffer { + void *start; + size_t length; + }; + + static char *dev_name; + static enum io_method io = IO_METHOD_MMAP; + static int fd = -1; + struct buffer *buffers; + static unsigned int n_buffers; + static int out_buf; + static int force_format; + static int frame_count = 70; + + static void errno_exit(const char *s) + { + fprintf(stderr, "%s error %d, %s\\n", s, errno, strerror(errno)); + exit(EXIT_FAILURE); + } + + static int xioctl(int fh, int request, void *arg) + { + int r; + + do { + r = ioctl(fh, request, arg); + } while (-1 == r && EINTR == errno); + + return r; + } + + static void process_image(const void *p, int size) + { + if (out_buf) + fwrite(p, size, 1, stdout); + + fflush(stderr); + fprintf(stderr, "."); + fflush(stdout); + } + + static int read_frame(void) + { + struct v4l2_buffer buf; + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + if (-1 == read(fd, buffers[0].start, buffers[0].length)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("read"); + } + } + + process_image(buffers[0].start, buffers[0].length); + break; + + case IO_METHOD_MMAP: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + assert(buf.index < n_buffers); + + process_image(buffers[buf.index].start, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + + case IO_METHOD_USERPTR: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + for (i = 0; i < n_buffers; ++i) + if (buf.m.userptr == (unsigned long)buffers[i].start + && buf.length == buffers[i].length) + break; + + assert(i < n_buffers); + + process_image((void *)buf.m.userptr, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + } + + return 1; + } + + static void mainloop(void) + { + unsigned int count; + + count = frame_count; + + while (count-- > 0) { + for (;;) { + fd_set fds; + struct timeval tv; + int r; + + FD_ZERO(&fds); + FD_SET(fd, &fds); + + /* Timeout. */ + tv.tv_sec = 2; + tv.tv_usec = 0; + + r = select(fd + 1, &fds, NULL, NULL, &tv); + + if (-1 == r) { + if (EINTR == errno) + continue; + errno_exit("select"); + } + + if (0 == r) { + fprintf(stderr, "select timeout\\n"); + exit(EXIT_FAILURE); + } + + if (read_frame()) + break; + /* EAGAIN - continue select loop. */ + } + } + } + + static void stop_capturing(void) + { + enum v4l2_buf_type type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMOFF, &type)) + errno_exit("VIDIOC_STREAMOFF"); + break; + } + } + + static void start_capturing(void) + { + unsigned int i; + enum v4l2_buf_type type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) { + struct v4l2_buffer buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = i; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) { + struct v4l2_buffer buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + buf.index = i; + buf.m.userptr = (unsigned long)buffers[i].start; + buf.length = buffers[i].length; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + } + } + + static void uninit_device(void) + { + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + free(buffers[0].start); + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) + if (-1 == munmap(buffers[i].start, buffers[i].length)) + errno_exit("munmap"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) + free(buffers[i].start); + break; + } + + free(buffers); + } + + static void init_read(unsigned int buffer_size) + { + buffers = calloc(1, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\\n"); + exit(EXIT_FAILURE); + } + + buffers[0].length = buffer_size; + buffers[0].start = malloc(buffer_size); + + if (!buffers[0].start) { + fprintf(stderr, "Out of memory\\n"); + exit(EXIT_FAILURE); + } + } + + static void init_mmap(void) + { + struct v4l2_requestbuffers req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "memory mappingn", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + if (req.count < 2) { + fprintf(stderr, "Insufficient buffer memory on %s\\n", + dev_name); + exit(EXIT_FAILURE); + } + + buffers = calloc(req.count, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < req.count; ++n_buffers) { + struct v4l2_buffer buf; + + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = n_buffers; + + if (-1 == xioctl(fd, VIDIOC_QUERYBUF, &buf)) + errno_exit("VIDIOC_QUERYBUF"); + + buffers[n_buffers].length = buf.length; + buffers[n_buffers].start = + mmap(NULL /* start anywhere */, + buf.length, + PROT_READ | PROT_WRITE /* required */, + MAP_SHARED /* recommended */, + fd, buf.m.offset); + + if (MAP_FAILED == buffers[n_buffers].start) + errno_exit("mmap"); + } + } + + static void init_userp(unsigned int buffer_size) + { + struct v4l2_requestbuffers req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "user pointer i/on", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + buffers = calloc(4, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < 4; ++n_buffers) { + buffers[n_buffers].length = buffer_size; + buffers[n_buffers].start = malloc(buffer_size); + + if (!buffers[n_buffers].start) { + fprintf(stderr, "Out of memory\\n"); + exit(EXIT_FAILURE); + } + } + } + + static void init_device(void) + { + struct v4l2_capability cap; + struct v4l2_cropcap cropcap; + struct v4l2_crop crop; + struct v4l2_format fmt; + unsigned int min; + + if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) { + if (EINVAL == errno) { + fprintf(stderr, "%s is no V4L2 device\\n", + dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_QUERYCAP"); + } + } + + if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { + fprintf(stderr, "%s is no video capture device\\n", + dev_name); + exit(EXIT_FAILURE); + } + + switch (io) { + case IO_METHOD_READ: + if (!(cap.capabilities & V4L2_CAP_READWRITE)) { + fprintf(stderr, "%s does not support read i/o\\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + if (!(cap.capabilities & V4L2_CAP_STREAMING)) { + fprintf(stderr, "%s does not support streaming i/o\\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + } + + + /* Select video input, video standard and tune here. */ + + + CLEAR(cropcap); + + cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (0 == xioctl(fd, VIDIOC_CROPCAP, &cropcap)) { + crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + crop.c = cropcap.defrect; /* reset to default */ + + if (-1 == xioctl(fd, VIDIOC_S_CROP, &crop)) { + switch (errno) { + case EINVAL: + /* Cropping not supported. */ + break; + default: + /* Errors ignored. */ + break; + } + } + } else { + /* Errors ignored. */ + } + + + CLEAR(fmt); + + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (force_format) { + fmt.fmt.pix.width = 640; + fmt.fmt.pix.height = 480; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; + + if (-1 == xioctl(fd, VIDIOC_S_FMT, &fmt)) + errno_exit("VIDIOC_S_FMT"); + + /* Note VIDIOC_S_FMT may change width and height. */ + } else { + /* Preserve original settings as set by v4l2-ctl for example */ + if (-1 == xioctl(fd, VIDIOC_G_FMT, &fmt)) + errno_exit("VIDIOC_G_FMT"); + } + + /* Buggy driver paranoia. */ + min = fmt.fmt.pix.width * 2; + if (fmt.fmt.pix.bytesperline < min) + fmt.fmt.pix.bytesperline = min; + min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; + if (fmt.fmt.pix.sizeimage < min) + fmt.fmt.pix.sizeimage = min; + + switch (io) { + case IO_METHOD_READ: + init_read(fmt.fmt.pix.sizeimage); + break; + + case IO_METHOD_MMAP: + init_mmap(); + break; + + case IO_METHOD_USERPTR: + init_userp(fmt.fmt.pix.sizeimage); + break; + } + } + + static void close_device(void) + { + if (-1 == close(fd)) + errno_exit("close"); + + fd = -1; + } + + static void open_device(void) + { + struct stat st; + + if (-1 == stat(dev_name, &st)) { + fprintf(stderr, "Cannot identify '%s': %d, %s\\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } + + if (!S_ISCHR(st.st_mode)) { + fprintf(stderr, "%s is no devicen", dev_name); + exit(EXIT_FAILURE); + } + + fd = open(dev_name, O_RDWR /* required */ | O_NONBLOCK, 0); + + if (-1 == fd) { + fprintf(stderr, "Cannot open '%s': %d, %s\\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } + } + + static void usage(FILE *fp, int argc, char **argv) + { + fprintf(fp, + "Usage: %s [options]\\n\\n" + "Version 1.3\\n" + "Options:\\n" + "-d | --device name Video device name [%s]n" + "-h | --help Print this messagen" + "-m | --mmap Use memory mapped buffers [default]n" + "-r | --read Use read() callsn" + "-u | --userp Use application allocated buffersn" + "-o | --output Outputs stream to stdoutn" + "-f | --format Force format to 640x480 YUYVn" + "-c | --count Number of frames to grab [%i]n" + "", + argv[0], dev_name, frame_count); + } + + static const char short_options[] = "d:hmruofc:"; + + static const struct option + long_options[] = { + { "device", required_argument, NULL, 'd' }, + { "help", no_argument, NULL, 'h' }, + { "mmap", no_argument, NULL, 'm' }, + { "read", no_argument, NULL, 'r' }, + { "userp", no_argument, NULL, 'u' }, + { "output", no_argument, NULL, 'o' }, + { "format", no_argument, NULL, 'f' }, + { "count", required_argument, NULL, 'c' }, + { 0, 0, 0, 0 } + }; + + int main(int argc, char **argv) + { + dev_name = "/dev/video0"; + + for (;;) { + int idx; + int c; + + c = getopt_long(argc, argv, + short_options, long_options, &idx); + + if (-1 == c) + break; + + switch (c) { + case 0: /* getopt_long() flag */ + break; + + case 'd': + dev_name = optarg; + break; + + case 'h': + usage(stdout, argc, argv); + exit(EXIT_SUCCESS); + + case 'm': + io = IO_METHOD_MMAP; + break; + + case 'r': + io = IO_METHOD_READ; + break; + + case 'u': + io = IO_METHOD_USERPTR; + break; + + case 'o': + out_buf++; + break; + + case 'f': + force_format++; + break; + + case 'c': + errno = 0; + frame_count = strtol(optarg, NULL, 0); + if (errno) + errno_exit(optarg); + break; + + default: + usage(stderr, argc, argv); + exit(EXIT_FAILURE); + } + } + + open_device(); + init_device(); + start_capturing(); + mainloop(); + stop_capturing(); + uninit_device(); + close_device(); + fprintf(stderr, "\\n"); + return 0; + } diff --git a/Documentation/media/uapi/v4l/colorspaces.rst b/Documentation/media/uapi/v4l/colorspaces.rst new file mode 100644 index 0000000000000000000000000000000000000000..322eb94c1d44a949360c383bd3d2c8053606aaa7 --- /dev/null +++ b/Documentation/media/uapi/v4l/colorspaces.rst @@ -0,0 +1,163 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _colorspaces: + +*********** +Colorspaces +*********** + +'Color' is a very complex concept and depends on physics, chemistry and +biology. Just because you have three numbers that describe the 'red', +'green' and 'blue' components of the color of a pixel does not mean that +you can accurately display that color. A colorspace defines what it +actually *means* to have an RGB value of e.g. (255, 0, 0). That is, +which color should be reproduced on the screen in a perfectly calibrated +environment. + +In order to do that we first need to have a good definition of color, +i.e. some way to uniquely and unambiguously define a color so that +someone else can reproduce it. Human color vision is trichromatic since +the human eye has color receptors that are sensitive to three different +wavelengths of light. Hence the need to use three numbers to describe +color. Be glad you are not a mantis shrimp as those are sensitive to 12 +different wavelengths, so instead of RGB we would be using the +ABCDEFGHIJKL colorspace... + +Color exists only in the eye and brain and is the result of how strongly +color receptors are stimulated. This is based on the Spectral Power +Distribution (SPD) which is a graph showing the intensity (radiant +power) of the light at wavelengths covering the visible spectrum as it +enters the eye. The science of colorimetry is about the relationship +between the SPD and color as perceived by the human brain. + +Since the human eye has only three color receptors it is perfectly +possible that different SPDs will result in the same stimulation of +those receptors and are perceived as the same color, even though the SPD +of the light is different. + +In the 1920s experiments were devised to determine the relationship +between SPDs and the perceived color and that resulted in the CIE 1931 +standard that defines spectral weighting functions that model the +perception of color. Specifically that standard defines functions that +can take an SPD and calculate the stimulus for each color receptor. +After some further mathematical transforms these stimuli are known as +the *CIE XYZ tristimulus* values and these X, Y and Z values describe a +color as perceived by a human unambiguously. These X, Y and Z values are +all in the range [0…1]. + +The Y value in the CIE XYZ colorspace corresponds to luminance. Often +the CIE XYZ colorspace is transformed to the normalized CIE xyY +colorspace: + +x = X / (X + Y + Z) + +y = Y / (X + Y + Z) + +The x and y values are the chromaticity coordinates and can be used to +define a color without the luminance component Y. It is very confusing +to have such similar names for these colorspaces. Just be aware that if +colors are specified with lower case 'x' and 'y', then the CIE xyY +colorspace is used. Upper case 'X' and 'Y' refer to the CIE XYZ +colorspace. Also, y has nothing to do with luminance. Together x and y +specify a color, and Y the luminance. That is really all you need to +remember from a practical point of view. At the end of this section you +will find reading resources that go into much more detail if you are +interested. + +A monitor or TV will reproduce colors by emitting light at three +different wavelengths, the combination of which will stimulate the color +receptors in the eye and thus cause the perception of color. +Historically these wavelengths were defined by the red, green and blue +phosphors used in the displays. These *color primaries* are part of what +defines a colorspace. + +Different display devices will have different primaries and some +primaries are more suitable for some display technologies than others. +This has resulted in a variety of colorspaces that are used for +different display technologies or uses. To define a colorspace you need +to define the three color primaries (these are typically defined as x, y +chromaticity coordinates from the CIE xyY colorspace) but also the white +reference: that is the color obtained when all three primaries are at +maximum power. This determines the relative power or energy of the +primaries. This is usually chosen to be close to daylight which has been +defined as the CIE D65 Illuminant. + +To recapitulate: the CIE XYZ colorspace uniquely identifies colors. +Other colorspaces are defined by three chromaticity coordinates defined +in the CIE xyY colorspace. Based on those a 3x3 matrix can be +constructed that transforms CIE XYZ colors to colors in the new +colorspace. + +Both the CIE XYZ and the RGB colorspace that are derived from the +specific chromaticity primaries are linear colorspaces. But neither the +eye, nor display technology is linear. Doubling the values of all +components in the linear colorspace will not be perceived as twice the +intensity of the color. So each colorspace also defines a transfer +function that takes a linear color component value and transforms it to +the non-linear component value, which is a closer match to the +non-linear performance of both the eye and displays. Linear component +values are denoted RGB, non-linear are denoted as R'G'B'. In general +colors used in graphics are all R'G'B', except in openGL which uses +linear RGB. Special care should be taken when dealing with openGL to +provide linear RGB colors or to use the built-in openGL support to apply +the inverse transfer function. + +The final piece that defines a colorspace is a function that transforms +non-linear R'G'B' to non-linear Y'CbCr. This function is determined by +the so-called luma coefficients. There may be multiple possible Y'CbCr +encodings allowed for the same colorspace. Many encodings of color +prefer to use luma (Y') and chroma (CbCr) instead of R'G'B'. Since the +human eye is more sensitive to differences in luminance than in color +this encoding allows one to reduce the amount of color information +compared to the luma data. Note that the luma (Y') is unrelated to the Y +in the CIE XYZ colorspace. Also note that Y'CbCr is often called YCbCr +or YUV even though these are strictly speaking wrong. + +Sometimes people confuse Y'CbCr as being a colorspace. This is not +correct, it is just an encoding of an R'G'B' color into luma and chroma +values. The underlying colorspace that is associated with the R'G'B' +color is also associated with the Y'CbCr color. + +The final step is how the RGB, R'G'B' or Y'CbCr values are quantized. +The CIE XYZ colorspace where X, Y and Z are in the range [0…1] describes +all colors that humans can perceive, but the transform to another +colorspace will produce colors that are outside the [0…1] range. Once +clamped to the [0…1] range those colors can no longer be reproduced in +that colorspace. This clamping is what reduces the extent or gamut of +the colorspace. How the range of [0…1] is translated to integer values +in the range of [0…255] (or higher, depending on the color depth) is +called the quantization. This is *not* part of the colorspace +definition. In practice RGB or R'G'B' values are full range, i.e. they +use the full [0…255] range. Y'CbCr values on the other hand are limited +range with Y' using [16…235] and Cb and Cr using [16…240]. + +Unfortunately, in some cases limited range RGB is also used where the +components use the range [16…235]. And full range Y'CbCr also exists +using the [0…255] range. + +In order to correctly interpret a color you need to know the +quantization range, whether it is R'G'B' or Y'CbCr, the used Y'CbCr +encoding and the colorspace. From that information you can calculate the +corresponding CIE XYZ color and map that again to whatever colorspace +your display device uses. + +The colorspace definition itself consists of the three chromaticity +primaries, the white reference chromaticity, a transfer function and the +luma coefficients needed to transform R'G'B' to Y'CbCr. While some +colorspace standards correctly define all four, quite often the +colorspace standard only defines some, and you have to rely on other +standards for the missing pieces. The fact that colorspaces are often a +mix of different standards also led to very confusing naming conventions +where the name of a standard was used to name a colorspace when in fact +that standard was part of various other colorspaces as well. + +If you want to read more about colors and colorspaces, then the +following resources are useful: :ref:`poynton` is a good practical +book for video engineers, :ref:`colimg` has a much broader scope and +describes many more aspects of color (physics, chemistry, biology, +etc.). The +`http://www.brucelindbloom.com `__ +website is an excellent resource, especially with respect to the +mathematics behind colorspace conversions. The wikipedia +`CIE 1931 colorspace `__ +article is also very useful. diff --git a/Documentation/media/uapi/v4l/common-defs.rst b/Documentation/media/uapi/v4l/common-defs.rst new file mode 100644 index 0000000000000000000000000000000000000000..39058216b630b40f00577e96071f11d244fddc69 --- /dev/null +++ b/Documentation/media/uapi/v4l/common-defs.rst @@ -0,0 +1,13 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _common-defs: + +****************************************************** +Common definitions for V4L2 and V4L2 subdev interfaces +****************************************************** + + +.. toctree:: + :maxdepth: 1 + + selections-common diff --git a/Documentation/media/uapi/v4l/common.rst b/Documentation/media/uapi/v4l/common.rst new file mode 100644 index 0000000000000000000000000000000000000000..13f2ed3fc5a6c4ce1d0fa5e9e5306b639491504b --- /dev/null +++ b/Documentation/media/uapi/v4l/common.rst @@ -0,0 +1,46 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _common: + +################### +Common API Elements +################### +Programming a V4L2 device consists of these steps: + +- Opening the device + +- Changing device properties, selecting a video and audio input, video + standard, picture brightness a. o. + +- Negotiating a data format + +- Negotiating an input/output method + +- The actual input/output loop + +- Closing the device + +In practice most steps are optional and can be executed out of order. It +depends on the V4L2 device type, you can read about the details in +:ref:`devices`. In this chapter we will discuss the basic concepts +applicable to all devices. + + +.. toctree:: + :maxdepth: 1 + + open + querycap + app-pri + video + audio + tuner + standard + dv-timings + control + extended-controls + format + planar-apis + crop + selection-api + streaming-par diff --git a/Documentation/media/uapi/v4l/compat.rst b/Documentation/media/uapi/v4l/compat.rst new file mode 100644 index 0000000000000000000000000000000000000000..8b5e1cebd8f4f894ca50d1a10e187f058128e955 --- /dev/null +++ b/Documentation/media/uapi/v4l/compat.rst @@ -0,0 +1,18 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _compat: + +******* +Changes +******* + +The following chapters document the evolution of the V4L2 API, errata or +extensions. They are also intended to help application and driver +writers to port or update their code. + + +.. toctree:: + :maxdepth: 1 + + diff-v4l + hist-v4l2 diff --git a/Documentation/media/uapi/v4l/control.rst b/Documentation/media/uapi/v4l/control.rst new file mode 100644 index 0000000000000000000000000000000000000000..10ab53dd31631b15595349bcd5014ff64b6c5a43 --- /dev/null +++ b/Documentation/media/uapi/v4l/control.rst @@ -0,0 +1,538 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _control: + +************* +User Controls +************* + +Devices typically have a number of user-settable controls such as +brightness, saturation and so on, which would be presented to the user +on a graphical user interface. But, different devices will have +different controls available, and furthermore, the range of possible +values, and the default value will vary from device to device. The +control ioctls provide the information and a mechanism to create a nice +user interface for these controls that will work correctly with any +device. + +All controls are accessed using an ID value. V4L2 defines several IDs +for specific purposes. Drivers can also implement their own custom +controls using ``V4L2_CID_PRIVATE_BASE`` [#f1]_ and higher values. The +pre-defined control IDs have the prefix ``V4L2_CID_``, and are listed in +:ref:`control-id`. The ID is used when querying the attributes of a +control, and when getting or setting the current value. + +Generally applications should present controls to the user without +assumptions about their purpose. Each control comes with a name string +the user is supposed to understand. When the purpose is non-intuitive +the driver writer should provide a user manual, a user interface plug-in +or a driver specific panel application. Predefined IDs were introduced +to change a few controls programmatically, for example to mute a device +during a channel switch. + +Drivers may enumerate different controls after switching the current +video input or output, tuner or modulator, or audio input or output. +Different in the sense of other bounds, another default and current +value, step size or other menu items. A control with a certain *custom* +ID can also change name and type. + +If a control is not applicable to the current configuration of the +device (for example, it doesn't apply to the current video input) +drivers set the ``V4L2_CTRL_FLAG_INACTIVE`` flag. + +Control values are stored globally, they do not change when switching +except to stay within the reported bounds. They also do not change e. g. +when the device is opened or closed, when the tuner radio frequency is +changed or generally never without application request. + +V4L2 specifies an event mechanism to notify applications when controls +change value (see +:ref:`VIDIOC_SUBSCRIBE_EVENT`, event +``V4L2_EVENT_CTRL``), panel applications might want to make use of that +in order to always reflect the correct control value. + +All controls use machine endianness. + + +.. _control-id: + +Control IDs +=========== + +``V4L2_CID_BASE`` + First predefined ID, equal to ``V4L2_CID_BRIGHTNESS``. + +``V4L2_CID_USER_BASE`` + Synonym of ``V4L2_CID_BASE``. + +``V4L2_CID_BRIGHTNESS`` ``(integer)`` + Picture brightness, or more precisely, the black level. + +``V4L2_CID_CONTRAST`` ``(integer)`` + Picture contrast or luma gain. + +``V4L2_CID_SATURATION`` ``(integer)`` + Picture color saturation or chroma gain. + +``V4L2_CID_HUE`` ``(integer)`` + Hue or color balance. + +``V4L2_CID_AUDIO_VOLUME`` ``(integer)`` + Overall audio volume. Note some drivers also provide an OSS or ALSA + mixer interface. + +``V4L2_CID_AUDIO_BALANCE`` ``(integer)`` + Audio stereo balance. Minimum corresponds to all the way left, + maximum to right. + +``V4L2_CID_AUDIO_BASS`` ``(integer)`` + Audio bass adjustment. + +``V4L2_CID_AUDIO_TREBLE`` ``(integer)`` + Audio treble adjustment. + +``V4L2_CID_AUDIO_MUTE`` ``(boolean)`` + Mute audio, i. e. set the volume to zero, however without affecting + ``V4L2_CID_AUDIO_VOLUME``. Like ALSA drivers, V4L2 drivers must mute + at load time to avoid excessive noise. Actually the entire device + should be reset to a low power consumption state. + +``V4L2_CID_AUDIO_LOUDNESS`` ``(boolean)`` + Loudness mode (bass boost). + +``V4L2_CID_BLACK_LEVEL`` ``(integer)`` + Another name for brightness (not a synonym of + ``V4L2_CID_BRIGHTNESS``). This control is deprecated and should not + be used in new drivers and applications. + +``V4L2_CID_AUTO_WHITE_BALANCE`` ``(boolean)`` + Automatic white balance (cameras). + +``V4L2_CID_DO_WHITE_BALANCE`` ``(button)`` + This is an action control. When set (the value is ignored), the + device will do a white balance and then hold the current setting. + Contrast this with the boolean ``V4L2_CID_AUTO_WHITE_BALANCE``, + which, when activated, keeps adjusting the white balance. + +``V4L2_CID_RED_BALANCE`` ``(integer)`` + Red chroma balance. + +``V4L2_CID_BLUE_BALANCE`` ``(integer)`` + Blue chroma balance. + +``V4L2_CID_GAMMA`` ``(integer)`` + Gamma adjust. + +``V4L2_CID_WHITENESS`` ``(integer)`` + Whiteness for grey-scale devices. This is a synonym for + ``V4L2_CID_GAMMA``. This control is deprecated and should not be + used in new drivers and applications. + +``V4L2_CID_EXPOSURE`` ``(integer)`` + Exposure (cameras). [Unit?] + +``V4L2_CID_AUTOGAIN`` ``(boolean)`` + Automatic gain/exposure control. + +``V4L2_CID_GAIN`` ``(integer)`` + Gain control. + +``V4L2_CID_HFLIP`` ``(boolean)`` + Mirror the picture horizontally. + +``V4L2_CID_VFLIP`` ``(boolean)`` + Mirror the picture vertically. + +.. _v4l2-power-line-frequency: + +``V4L2_CID_POWER_LINE_FREQUENCY`` ``(enum)`` + Enables a power line frequency filter to avoid flicker. Possible + values for ``enum v4l2_power_line_frequency`` are: + ``V4L2_CID_POWER_LINE_FREQUENCY_DISABLED`` (0), + ``V4L2_CID_POWER_LINE_FREQUENCY_50HZ`` (1), + ``V4L2_CID_POWER_LINE_FREQUENCY_60HZ`` (2) and + ``V4L2_CID_POWER_LINE_FREQUENCY_AUTO`` (3). + +``V4L2_CID_HUE_AUTO`` ``(boolean)`` + Enables automatic hue control by the device. The effect of setting + ``V4L2_CID_HUE`` while automatic hue control is enabled is + undefined, drivers should ignore such request. + +``V4L2_CID_WHITE_BALANCE_TEMPERATURE`` ``(integer)`` + This control specifies the white balance settings as a color + temperature in Kelvin. A driver should have a minimum of 2800 + (incandescent) to 6500 (daylight). For more information about color + temperature see + `Wikipedia `__. + +``V4L2_CID_SHARPNESS`` ``(integer)`` + Adjusts the sharpness filters in a camera. The minimum value + disables the filters, higher values give a sharper picture. + +``V4L2_CID_BACKLIGHT_COMPENSATION`` ``(integer)`` + Adjusts the backlight compensation in a camera. The minimum value + disables backlight compensation. + +``V4L2_CID_CHROMA_AGC`` ``(boolean)`` + Chroma automatic gain control. + +``V4L2_CID_CHROMA_GAIN`` ``(integer)`` + Adjusts the Chroma gain control (for use when chroma AGC is + disabled). + +``V4L2_CID_COLOR_KILLER`` ``(boolean)`` + Enable the color killer (i. e. force a black & white image in case + of a weak video signal). + +.. _v4l2-colorfx: + +``V4L2_CID_COLORFX`` ``(enum)`` + Selects a color effect. The following values are defined: + + + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + + - .. row 1 + + - ``V4L2_COLORFX_NONE`` + + - Color effect is disabled. + + - .. row 2 + + - ``V4L2_COLORFX_ANTIQUE`` + + - An aging (old photo) effect. + + - .. row 3 + + - ``V4L2_COLORFX_ART_FREEZE`` + + - Frost color effect. + + - .. row 4 + + - ``V4L2_COLORFX_AQUA`` + + - Water color, cool tone. + + - .. row 5 + + - ``V4L2_COLORFX_BW`` + + - Black and white. + + - .. row 6 + + - ``V4L2_COLORFX_EMBOSS`` + + - Emboss, the highlights and shadows replace light/dark boundaries + and low contrast areas are set to a gray background. + + - .. row 7 + + - ``V4L2_COLORFX_GRASS_GREEN`` + + - Grass green. + + - .. row 8 + + - ``V4L2_COLORFX_NEGATIVE`` + + - Negative. + + - .. row 9 + + - ``V4L2_COLORFX_SEPIA`` + + - Sepia tone. + + - .. row 10 + + - ``V4L2_COLORFX_SKETCH`` + + - Sketch. + + - .. row 11 + + - ``V4L2_COLORFX_SKIN_WHITEN`` + + - Skin whiten. + + - .. row 12 + + - ``V4L2_COLORFX_SKY_BLUE`` + + - Sky blue. + + - .. row 13 + + - ``V4L2_COLORFX_SOLARIZATION`` + + - Solarization, the image is partially reversed in tone, only color + values above or below a certain threshold are inverted. + + - .. row 14 + + - ``V4L2_COLORFX_SILHOUETTE`` + + - Silhouette (outline). + + - .. row 15 + + - ``V4L2_COLORFX_VIVID`` + + - Vivid colors. + + - .. row 16 + + - ``V4L2_COLORFX_SET_CBCR`` + + - The Cb and Cr chroma components are replaced by fixed coefficients + determined by ``V4L2_CID_COLORFX_CBCR`` control. + + + +``V4L2_CID_COLORFX_CBCR`` ``(integer)`` + Determines the Cb and Cr coefficients for ``V4L2_COLORFX_SET_CBCR`` + color effect. Bits [7:0] of the supplied 32 bit value are + interpreted as Cr component, bits [15:8] as Cb component and bits + [31:16] must be zero. + +``V4L2_CID_AUTOBRIGHTNESS`` ``(boolean)`` + Enable Automatic Brightness. + +``V4L2_CID_ROTATE`` ``(integer)`` + Rotates the image by specified angle. Common angles are 90, 270 and + 180. Rotating the image to 90 and 270 will reverse the height and + width of the display window. It is necessary to set the new height + and width of the picture using the + :ref:`VIDIOC_S_FMT ` ioctl according to the + rotation angle selected. + +``V4L2_CID_BG_COLOR`` ``(integer)`` + Sets the background color on the current output device. Background + color needs to be specified in the RGB24 format. The supplied 32 bit + value is interpreted as bits 0-7 Red color information, bits 8-15 + Green color information, bits 16-23 Blue color information and bits + 24-31 must be zero. + +``V4L2_CID_ILLUMINATORS_1 V4L2_CID_ILLUMINATORS_2`` ``(boolean)`` + Switch on or off the illuminator 1 or 2 of the device (usually a + microscope). + +``V4L2_CID_MIN_BUFFERS_FOR_CAPTURE`` ``(integer)`` + This is a read-only control that can be read by the application and + used as a hint to determine the number of CAPTURE buffers to pass to + REQBUFS. The value is the minimum number of CAPTURE buffers that is + necessary for hardware to work. + +``V4L2_CID_MIN_BUFFERS_FOR_OUTPUT`` ``(integer)`` + This is a read-only control that can be read by the application and + used as a hint to determine the number of OUTPUT buffers to pass to + REQBUFS. The value is the minimum number of OUTPUT buffers that is + necessary for hardware to work. + +.. _v4l2-alpha-component: + +``V4L2_CID_ALPHA_COMPONENT`` ``(integer)`` + Sets the alpha color component. When a capture device (or capture + queue of a mem-to-mem device) produces a frame format that includes + an alpha component (e.g. + :ref:`packed RGB image formats `) and the alpha value + is not defined by the device or the mem-to-mem input data this + control lets you select the alpha component value of all pixels. + When an output device (or output queue of a mem-to-mem device) + consumes a frame format that doesn't include an alpha component and + the device supports alpha channel processing this control lets you + set the alpha component value of all pixels for further processing + in the device. + +``V4L2_CID_LASTP1`` + End of the predefined control IDs (currently + ``V4L2_CID_ALPHA_COMPONENT`` + 1). + +``V4L2_CID_PRIVATE_BASE`` + ID of the first custom (driver specific) control. Applications + depending on particular custom controls should check the driver name + and version, see :ref:`querycap`. + +Applications can enumerate the available controls with the +:ref:`VIDIOC_QUERYCTRL` and +:ref:`VIDIOC_QUERYMENU ` ioctls, get and set a +control value with the :ref:`VIDIOC_G_CTRL ` and +:ref:`VIDIOC_S_CTRL ` ioctls. Drivers must implement +``VIDIOC_QUERYCTRL``, ``VIDIOC_G_CTRL`` and ``VIDIOC_S_CTRL`` when the +device has one or more controls, ``VIDIOC_QUERYMENU`` when it has one or +more menu type controls. + + +.. _enum_all_controls: + +Example: Enumerating all user controls +====================================== + +.. code-block:: c + + + struct v4l2_queryctrl queryctrl; + struct v4l2_querymenu querymenu; + + static void enumerate_menu(void) + { + printf(" Menu items:\\n"); + + memset(&querymenu, 0, sizeof(querymenu)); + querymenu.id = queryctrl.id; + + for (querymenu.index = queryctrl.minimum; + querymenu.index <= queryctrl.maximum; + querymenu.index++) { + if (0 == ioctl(fd, VIDIOC_QUERYMENU, &querymenu)) { + printf(" %s\\n", querymenu.name); + } + } + } + + memset(&queryctrl, 0, sizeof(queryctrl)); + + for (queryctrl.id = V4L2_CID_BASE; + queryctrl.id < V4L2_CID_LASTP1; + queryctrl.id++) { + if (0 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf("Control %s\\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu(); + } else { + if (errno == EINVAL) + continue; + + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); + } + } + + for (queryctrl.id = V4L2_CID_PRIVATE_BASE;; + queryctrl.id++) { + if (0 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf("Control %s\\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu(); + } else { + if (errno == EINVAL) + break; + + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); + } + } + + +Example: Enumerating all user controls (alternative) +==================================================== + +.. code-block:: c + + memset(&queryctrl, 0, sizeof(queryctrl)); + + queryctrl.id = V4L2_CTRL_CLASS_USER | V4L2_CTRL_FLAG_NEXT_CTRL; + while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) { + if (V4L2_CTRL_ID2CLASS(queryctrl.id) != V4L2_CTRL_CLASS_USER) + break; + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf("Control %s\\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu(); + + queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; + } + if (errno != EINVAL) { + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); + } + +Example: Changing controls +========================== + +.. code-block:: c + + struct v4l2_queryctrl queryctrl; + struct v4l2_control control; + + memset(&queryctrl, 0, sizeof(queryctrl)); + queryctrl.id = V4L2_CID_BRIGHTNESS; + + if (-1 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) { + if (errno != EINVAL) { + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); + } else { + printf("V4L2_CID_BRIGHTNESS is not supportedn"); + } + } else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { + printf("V4L2_CID_BRIGHTNESS is not supportedn"); + } else { + memset(&control, 0, sizeof (control)); + control.id = V4L2_CID_BRIGHTNESS; + control.value = queryctrl.default_value; + + if (-1 == ioctl(fd, VIDIOC_S_CTRL, &control)) { + perror("VIDIOC_S_CTRL"); + exit(EXIT_FAILURE); + } + } + + memset(&control, 0, sizeof(control)); + control.id = V4L2_CID_CONTRAST; + + if (0 == ioctl(fd, VIDIOC_G_CTRL, &control)) { + control.value += 1; + + /* The driver may clamp the value or return ERANGE, ignored here */ + + if (-1 == ioctl(fd, VIDIOC_S_CTRL, &control) + && errno != ERANGE) { + perror("VIDIOC_S_CTRL"); + exit(EXIT_FAILURE); + } + /* Ignore if V4L2_CID_CONTRAST is unsupported */ + } else if (errno != EINVAL) { + perror("VIDIOC_G_CTRL"); + exit(EXIT_FAILURE); + } + + control.id = V4L2_CID_AUDIO_MUTE; + control.value = 1; /* silence */ + + /* Errors ignored */ + ioctl(fd, VIDIOC_S_CTRL, &control); + +.. [#f1] + The use of ``V4L2_CID_PRIVATE_BASE`` is problematic because different + drivers may use the same ``V4L2_CID_PRIVATE_BASE`` ID for different + controls. This makes it hard to programatically set such controls + since the meaning of the control with that ID is driver dependent. In + order to resolve this drivers use unique IDs and the + ``V4L2_CID_PRIVATE_BASE`` IDs are mapped to those unique IDs by the + kernel. Consider these ``V4L2_CID_PRIVATE_BASE`` IDs as aliases to + the real IDs. + + Many applications today still use the ``V4L2_CID_PRIVATE_BASE`` IDs + instead of using :ref:`VIDIOC_QUERYCTRL` with + the ``V4L2_CTRL_FLAG_NEXT_CTRL`` flag to enumerate all IDs, so + support for ``V4L2_CID_PRIVATE_BASE`` is still around. diff --git a/Documentation/media/uapi/v4l/crop.rst b/Documentation/media/uapi/v4l/crop.rst new file mode 100644 index 0000000000000000000000000000000000000000..0913822347af617e1d791993301c4ae246f41e2f --- /dev/null +++ b/Documentation/media/uapi/v4l/crop.rst @@ -0,0 +1,303 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _crop: + +************************************* +Image Cropping, Insertion and Scaling +************************************* + +Some video capture devices can sample a subsection of the picture and +shrink or enlarge it to an image of arbitrary size. We call these +abilities cropping and scaling. Some video output devices can scale an +image up or down and insert it at an arbitrary scan line and horizontal +offset into a video signal. + +Applications can use the following API to select an area in the video +signal, query the default area and the hardware limits. + +.. note:: Despite their name, the :ref:`VIDIOC_CROPCAP `, + :ref:`VIDIOC_G_CROP ` and :ref:`VIDIOC_S_CROP + ` ioctls apply to input as well as output devices. + +Scaling requires a source and a target. On a video capture or overlay +device the source is the video signal, and the cropping ioctls determine +the area actually sampled. The target are images read by the application +or overlaid onto the graphics screen. Their size (and position for an +overlay) is negotiated with the :ref:`VIDIOC_G_FMT ` +and :ref:`VIDIOC_S_FMT ` ioctls. + +On a video output device the source are the images passed in by the +application, and their size is again negotiated with the +:ref:`VIDIOC_G_FMT ` and :ref:`VIDIOC_S_FMT ` +ioctls, or may be encoded in a compressed video stream. The target is +the video signal, and the cropping ioctls determine the area where the +images are inserted. + +Source and target rectangles are defined even if the device does not +support scaling or the :ref:`VIDIOC_G_CROP ` and +:ref:`VIDIOC_S_CROP ` ioctls. Their size (and position +where applicable) will be fixed in this case. + +.. note:: All capture and output devices must support the + :ref:`VIDIOC_CROPCAP ` ioctl such that applications + can determine if scaling takes place. + + +Cropping Structures +=================== + + +.. _crop-scale: + +.. figure:: crop_files/crop.* + :alt: crop.pdf / crop.gif + :align: center + + Image Cropping, Insertion and Scaling + + The cropping, insertion and scaling process + + + +For capture devices the coordinates of the top left corner, width and +height of the area which can be sampled is given by the ``bounds`` +substructure of the struct :ref:`v4l2_cropcap ` returned +by the :ref:`VIDIOC_CROPCAP ` ioctl. To support a wide +range of hardware this specification does not define an origin or units. +However by convention drivers should horizontally count unscaled samples +relative to 0H (the leading edge of the horizontal sync pulse, see +:ref:`vbi-hsync`). Vertically ITU-R line numbers of the first field +(see ITU R-525 line numbering for :ref:`525 lines ` and for +:ref:`625 lines `), multiplied by two if the driver +can capture both fields. + +The top left corner, width and height of the source rectangle, that is +the area actually sampled, is given by struct +:ref:`v4l2_crop ` using the same coordinate system as +struct :ref:`v4l2_cropcap `. Applications can use the +:ref:`VIDIOC_G_CROP ` and :ref:`VIDIOC_S_CROP ` +ioctls to get and set this rectangle. It must lie completely within the +capture boundaries and the driver may further adjust the requested size +and/or position according to hardware limitations. + +Each capture device has a default source rectangle, given by the +``defrect`` substructure of struct +:ref:`v4l2_cropcap `. The center of this rectangle +shall align with the center of the active picture area of the video +signal, and cover what the driver writer considers the complete picture. +Drivers shall reset the source rectangle to the default when the driver +is first loaded, but not later. + +For output devices these structures and ioctls are used accordingly, +defining the *target* rectangle where the images will be inserted into +the video signal. + + +Scaling Adjustments +=================== + +Video hardware can have various cropping, insertion and scaling +limitations. It may only scale up or down, support only discrete scaling +factors, or have different scaling abilities in horizontal and vertical +direction. Also it may not support scaling at all. At the same time the +struct :ref:`v4l2_crop ` rectangle may have to be aligned, +and both the source and target rectangles may have arbitrary upper and +lower size limits. In particular the maximum ``width`` and ``height`` in +struct :ref:`v4l2_crop ` may be smaller than the struct +:ref:`v4l2_cropcap `. ``bounds`` area. Therefore, as +usual, drivers are expected to adjust the requested parameters and +return the actual values selected. + +Applications can change the source or the target rectangle first, as +they may prefer a particular image size or a certain area in the video +signal. If the driver has to adjust both to satisfy hardware +limitations, the last requested rectangle shall take priority, and the +driver should preferably adjust the opposite one. The +:ref:`VIDIOC_TRY_FMT ` ioctl however shall not change +the driver state and therefore only adjust the requested rectangle. + +Suppose scaling on a video capture device is restricted to a factor 1:1 +or 2:1 in either direction and the target image size must be a multiple +of 16 × 16 pixels. The source cropping rectangle is set to defaults, +which are also the upper limit in this example, of 640 × 400 pixels at +offset 0, 0. An application requests an image size of 300 × 225 pixels, +assuming video will be scaled down from the "full picture" accordingly. +The driver sets the image size to the closest possible values 304 × 224, +then chooses the cropping rectangle closest to the requested size, that +is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is +still valid, thus unmodified. Given the default cropping rectangle +reported by :ref:`VIDIOC_CROPCAP ` the application can +easily propose another offset to center the cropping rectangle. + +Now the application may insist on covering an area using a picture +aspect ratio closer to the original request, so it asks for a cropping +rectangle of 608 × 456 pixels. The present scaling factors limit +cropping to 640 × 384, so the driver returns the cropping size 608 × 384 +and adjusts the image size to closest possible 304 × 192. + + +Examples +======== + +Source and target rectangles shall remain unchanged across closing and +reopening a device, such that piping data into or out of a device will +work without special preparations. More advanced applications should +ensure the parameters are suitable before starting I/O. + +.. note:: On the next two examples, a video capture device is assumed; + change ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` for other types of device. + +Example: Resetting the cropping parameters +========================================== + +.. code-block:: c + + struct v4l2_cropcap cropcap; + struct v4l2_crop crop; + + memset (&cropcap, 0, sizeof (cropcap)); + cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (-1 == ioctl (fd, VIDIOC_CROPCAP, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); + } + + memset (&crop, 0, sizeof (crop)); + crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + crop.c = cropcap.defrect; + + /* Ignore if cropping is not supported (EINVAL). */ + + if (-1 == ioctl (fd, VIDIOC_S_CROP, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); + } + + +Example: Simple downscaling +=========================== + +.. code-block:: c + + struct v4l2_cropcap cropcap; + struct v4l2_format format; + + reset_cropping_parameters (); + + /* Scale down to 1/4 size of full picture. */ + + memset (&format, 0, sizeof (format)); /* defaults */ + + format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + format.fmt.pix.width = cropcap.defrect.width >> 1; + format.fmt.pix.height = cropcap.defrect.height >> 1; + format.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + + if (-1 == ioctl (fd, VIDIOC_S_FMT, &format)) { + perror ("VIDIOC_S_FORMAT"); + exit (EXIT_FAILURE); + } + + /* We could check the actual image size now, the actual scaling factor + or if the driver can scale at all. */ + +Example: Selecting an output area +================================= + +.. note:: This example assumes an output device. + +.. code-block:: c + + struct v4l2_cropcap cropcap; + struct v4l2_crop crop; + + memset (&cropcap, 0, sizeof (cropcap)); + cropcap.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + + if (-1 == ioctl (fd, VIDIOC_CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); + } + + memset (&crop, 0, sizeof (crop)); + + crop.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + crop.c = cropcap.defrect; + + /* Scale the width and height to 50 % of their original size + and center the output. */ + + crop.c.width /= 2; + crop.c.height /= 2; + crop.c.left += crop.c.width / 2; + crop.c.top += crop.c.height / 2; + + /* Ignore if cropping is not supported (EINVAL). */ + + if (-1 == ioctl (fd, VIDIOC_S_CROP, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); + } + +Example: Current scaling factor and pixel aspect +================================================ + +.. note:: This example assumes a video capture device. + +.. code-block:: c + + struct v4l2_cropcap cropcap; + struct v4l2_crop crop; + struct v4l2_format format; + double hscale, vscale; + double aspect; + int dwidth, dheight; + + memset (&cropcap, 0, sizeof (cropcap)); + cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (-1 == ioctl (fd, VIDIOC_CROPCAP, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); + } + + memset (&crop, 0, sizeof (crop)); + crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (-1 == ioctl (fd, VIDIOC_G_CROP, &crop)) { + if (errno != EINVAL) { + perror ("VIDIOC_G_CROP"); + exit (EXIT_FAILURE); + } + + /* Cropping not supported. */ + crop.c = cropcap.defrect; + } + + memset (&format, 0, sizeof (format)); + format.fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (-1 == ioctl (fd, VIDIOC_G_FMT, &format)) { + perror ("VIDIOC_G_FMT"); + exit (EXIT_FAILURE); + } + + /* The scaling applied by the driver. */ + + hscale = format.fmt.pix.width / (double) crop.c.width; + vscale = format.fmt.pix.height / (double) crop.c.height; + + aspect = cropcap.pixelaspect.numerator / + (double) cropcap.pixelaspect.denominator; + aspect = aspect * hscale / vscale; + + /* Devices following ITU-R BT.601 do not capture + square pixels. For playback on a computer monitor + we should scale the images to this size. */ + + dwidth = format.fmt.pix.width / aspect; + dheight = format.fmt.pix.height; diff --git a/Documentation/media/uapi/v4l/crop_files/crop.gif b/Documentation/media/uapi/v4l/crop_files/crop.gif new file mode 100644 index 0000000000000000000000000000000000000000..3b9e7d836d4b8a685e76ec6412fc28c9f5c16f27 Binary files /dev/null and b/Documentation/media/uapi/v4l/crop_files/crop.gif differ diff --git a/Documentation/media/uapi/v4l/crop_files/crop.pdf b/Documentation/media/uapi/v4l/crop_files/crop.pdf new file mode 100644 index 0000000000000000000000000000000000000000..c9fb81cd32f34d2b08cb601f3a1575af77e14275 Binary files /dev/null and b/Documentation/media/uapi/v4l/crop_files/crop.pdf differ diff --git a/Documentation/media/uapi/v4l/depth-formats.rst b/Documentation/media/uapi/v4l/depth-formats.rst new file mode 100644 index 0000000000000000000000000000000000000000..82f183870aaeb7c60e182768ead193d5f0d0eae8 --- /dev/null +++ b/Documentation/media/uapi/v4l/depth-formats.rst @@ -0,0 +1,15 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _depth-formats: + +************* +Depth Formats +************* + +Depth data provides distance to points, mapped onto the image plane + + +.. toctree:: + :maxdepth: 1 + + pixfmt-z16 diff --git a/Documentation/media/uapi/v4l/dev-capture.rst b/Documentation/media/uapi/v4l/dev-capture.rst new file mode 100644 index 0000000000000000000000000000000000000000..8d049471e1c2baa6301660ee0d2c33e6a48d3bf0 --- /dev/null +++ b/Documentation/media/uapi/v4l/dev-capture.rst @@ -0,0 +1,104 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _capture: + +*********************** +Video Capture Interface +*********************** + +Video capture devices sample an analog video signal and store the +digitized images in memory. Today nearly all devices can capture at full +25 or 30 frames/second. With this interface applications can control the +capture process and move images from the driver into user space. + +Conventionally V4L2 video capture devices are accessed through character +device special files named ``/dev/video`` and ``/dev/video0`` to +``/dev/video63`` with major number 81 and minor numbers 0 to 63. +``/dev/video`` is typically a symbolic link to the preferred video +device. + +.. note:: The same device file names are used for video output devices. + + +Querying Capabilities +===================== + +Devices supporting the video capture interface set the +``V4L2_CAP_VIDEO_CAPTURE`` or ``V4L2_CAP_VIDEO_CAPTURE_MPLANE`` flag in +the ``capabilities`` field of struct +:ref:`v4l2_capability ` returned by the +:ref:`VIDIOC_QUERYCAP` ioctl. As secondary device +functions they may also support the :ref:`video overlay ` +(``V4L2_CAP_VIDEO_OVERLAY``) and the :ref:`raw VBI capture ` +(``V4L2_CAP_VBI_CAPTURE``) interface. At least one of the read/write or +streaming I/O methods must be supported. Tuners and audio inputs are +optional. + + +Supplemental Functions +====================== + +Video capture devices shall support :ref:`audio input