S2API: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
Line 9: Line 9:
Technically it is quite different from multiproto. Control of the frontend is implemented using a command sequence of (tag,value) pairs to set all the required parameters and then initiate tuning. Thus it no longer depends on fixed structs to hold parameter data.
Technically it is quite different from multiproto. Control of the frontend is implemented using a command sequence of (tag,value) pairs to set all the required parameters and then initiate tuning. Thus it no longer depends on fixed structs to hold parameter data.


A notable advantage of the tag/value technique is that it should make it much easier to keep up with future DVB transmission standards because this will at most require the definition of additional tags (i.e. commands) rather than a revision of the API. Transmission standards continue to multiply: some developers already have hardware using standards unsupported by multiproto, such as ISDB-T and DMB-T/H.
A notable advantage of the tag/value technique is that it should make it much easier to keep up with future DVB transmission standards because this will at most require the definition of additional tags (i.e. parameters) rather than a revision of the API. Transmission standards continue to multiply: some developers (and many consumers)
already have hardware using standards unsupported by multiproto, such as [http://en.wikipedia.org/wiki/ISDB-T#ISDB-T ISDB-T] and DMB-T/H. Other standards
are due to go live fairly soon, e.g. [http://en.wikipedia.org/wiki/DVB-T#DVB-T2 DVB-T2] (Nov 2009 in UK).


A typical example of a (tag,value) pair which forms a command is (TV_SET_FREQUENCY, 11954 MHz). A sequence of
A typical example of a (tag,value) pair which forms a command is (TV_SET_FREQUENCY, 11954 MHz). A sequence of
Line 22: Line 24:
*cx24116 demodulator driver
*cx24116 demodulator driver
*[[Hauppauge_WinTV-HVR-4000]] family of DVB-S2 products
*[[Hauppauge_WinTV-HVR-4000]] family of DVB-S2 products
*[[TeVii S460]]
*[[TeVii S460]] DVB-S/S2 PCI


Patches posted for inclusion in the tree:
Patches posted for inclusion in the tree:
*[[TeVii S650]] see http://linuxtv.org/pipermail/linux-dvb/2008-September/028611.html
*[[TeVii S650]] DVB-S/S2 USB see http://linuxtv.org/pipermail/linux-dvb/2008-September/028611.html
*[[DVBWorld HD 2104 CA+CI USB Box]] see http://linuxtv.org/pipermail/linux-dvb/2008-September/028611.html
*[[DVBWorld HD 2104 CA+CI USB Box]] see http://linuxtv.org/pipermail/linux-dvb/2008-September/028611.html



Revision as of 13:02, 9 September 2008

S2API is a tag/value-based API which is a proposal for version 3.3 of the Linux DVB API, adding support for new DVB transmission standards including DVB-S2. It is currently under rapid development with the intention of merging it into the Linux kernel soon.

Introduction

Following long standing frustration amongst developers and users about the lack of progress in getting multiproto into the Linux kernel, a group of four senior developers including the maintainer has proposed an alternative (Aug 29 2008) and announced that they no longer support multiproto. See http://linuxtv.org/pipermail/linux-dvb/2008-August/028313.html. The idea had been proposed earlier http://linuxtv.org/pipermail/linux-dvb/2007-November/021618.html. See also http://article.gmane.org/gmane.linux.drivers.dvb/36643.

Technically it is quite different from multiproto. Control of the frontend is implemented using a command sequence of (tag,value) pairs to set all the required parameters and then initiate tuning. Thus it no longer depends on fixed structs to hold parameter data.

A notable advantage of the tag/value technique is that it should make it much easier to keep up with future DVB transmission standards because this will at most require the definition of additional tags (i.e. parameters) rather than a revision of the API. Transmission standards continue to multiply: some developers (and many consumers) already have hardware using standards unsupported by multiproto, such as ISDB-T and DMB-T/H. Other standards are due to go live fairly soon, e.g. DVB-T2 (Nov 2009 in UK).

A typical example of a (tag,value) pair which forms a command is (TV_SET_FREQUENCY, 11954 MHz). A sequence of commands would typically include a full set of tuning parameters, LNB voltage and tone, and a "do tune" command. Sequences of commands may be made atomic by passing the whole command sequence in a single ioctl (for example a set of parameters followed by the tune command). Alternatively a sequence may be sent one command at a time. S2API thus offers an extra degree of flexibility over a multiproto-style approach, and the better application-to-driver communication could potentially be exploited for more advanced application functionality in in the future.

The development repository is at http://linuxtv.org/hg/~stoth/s2 and a tuning application is at http://www.steventoth.net/linux/s2/. Work still needs to be done to finish the API design and port the existing DVB-S2 drivers to work with it. Older drivers not requiring the new features can remain unchanged. Device support in the tree currently includes the

Patches posted for inclusion in the tree:

The HVR4000 and the S460 have both been tested successfully using the new API, see this thread http://linuxtv.org/pipermail/linux-dvb/2008-September/028544.html.

Driver code is largely independent of the API used, and hooking up an existing driver to work with a different API is quite simple (much easier than writing the driver in the first place), so this can be expected to progress rapidly. Similarly, for application code (e.g. Kaffeine, MythTV or VDR) the number of lines of code required to tune to a channel is small, and can easily be changed for a different API.

DiSEqC equipment control is unchanged in both S2API and multiproto APIs.

S2API will be reviewed at the Linux Plumbers' Conference in September 2008: http://linuxplumbersconf.org/program/microconfs/getmc.php?mc=chehab08.