S2API: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
 
(60 intermediate revisions by 6 users not shown)
Line 1: Line 1:
S2API is a tag/value-based API which is a proposal for version 3.3 of the LinuxDVB API, adding support for
S2API is a tag/value-based API which was proposed (and accepted) as version 5.0 of the LinuxDVB API, adding
new digital media transmission standards including [[DVB-S2]] and ISDB-T, and creating a way to allow
support for new digital media transmission standards including [[DVB-S2]], and creating a way to allow
easier support of future transmission standards. It is currently under rapid development with the intention of merging it into the Linux kernel soon.
easier support of future transmission standards. It was developed and tested in autumn 2008 and was
merged into the Linux kernel version 2.6.28 which was released on 24 Dec 2008.

An [http://www.spinics.net/lists/linux-media/msg08494.html RFC on a proposal for adding support for ISDB-T/ISDB-Tsb to DVB-API v5] was issued on 3 Aug 2009, with the intention of reaching
consensus before the merge window for kernel version 2.6.32 was opened (9 Sep 2009).
Anyone with an interest is encouraged to take part in the discussion at linux-media@vger.kernel.org.
A pull request was issued on 14 Aug 2009: http://www.spinics.net/lists/linux-media/msg08896.html.


===Introduction===
===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.
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
proposed an alternative (Aug 29 2008) and announced that they no longer supported 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.
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.
Line 19: Line 26:
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.
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.


[[DiSEqC]] equipment control is unchanged in both S2API and multiproto APIs. Additional S2API tags to allow
The development repository is at http://linuxtv.org/hg/~stoth/s2 and tuning applications are here http://www.steventoth.net/linux/s2/ and here http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/szap-s2/archive/tip.tar.gz. Work is progressing well on the finalization of the API design and
DiSEqC commands be sent with the tag/value method (as an alternative to the legacy method) could be implemented.

The development repositories are at http://linuxtv.org/hg/~stoth/s2 and http://linuxtv.org/hg/~stoth/s2-mfe. Tuning applications are here http://www.steventoth.net/linux/s2/ and here http://mercurial.intuxication.org/hg/szap-s2/.
A channel scanning application is here http://mercurial.intuxication.org/hg/scan-s2.
Work is progressing well on the finalization of the API design and
porting of existing DVB-S2 drivers to work with it. Older drivers not requiring the new features can remain
porting of existing DVB-S2 drivers to work with it. Older drivers not requiring the new features can remain
unchanged. Device support in the tree now includes the
unchanged. Device support now includes:


*cx24116 demodulator driver
*cx24116 demodulator driver
Line 30: Line 42:
*[[DVBWorld HD 2104 CA+CI USB Box]] DVB-S/S2
*[[DVBWorld HD 2104 CA+CI USB Box]] DVB-S/S2
*[[SDMC DM1105]] PCI chip (used in DVBWorld 2002 DVB-S & 2004 DVB-S2)
*[[SDMC DM1105]] PCI chip (used in DVBWorld 2002 DVB-S & 2004 DVB-S2)
*[[DVBWorld 2004C]] DVB-S/S2 PCI
*[[DVBWorld]] [[DVBWorld DVB-S2 PCI2004C|DVB-S2 PCI2004C]] DVB-S/S2 PCI
* Silicon Labs si2109/2110 demodulator support
Patches ready for inclusion in tree
* [[DVBWorld]] 2102 and TeVii s600 DVB-S USB (si2109/2110 demod, Serit tuner) [http://linuxtv.org/pipermail/linux-dvb/2008-September/028963.html]
* Multiple frontend support (for example HVR4000 DVB-S/S2 + DVB-T)
* Omicom SS4 DVB-S/S2 support (cx24116 demod)
* TBS 8920 DVB-S/S2 support (cx24116 demod)
* Prof 7300 support (cx24116 demod)
* ST stv0288 demodulator support, stb6000 tuner, [[DVBWorld]] DW2002 PCI with Earda tuner, [[TeVii]] S420 PCI
* [[DVBWorld]] USB cards support (STV0288 demod, Earda EDS-1547 tuner)
* Multiple frontend support (for example HVR4000 DVB-S/S2 + DVB-T) (repository at http://linuxtv.org/hg/~stoth/s2-mfe)
Preliminary support
* stb0899 demodulator (TT S2-3200, S2-3600, S2-3650CI) from Igor Liplianin, tree at http://mercurial.intuxication.org/hg/s2-liplianin [http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029585.html]
* stb0899 demodulator (TT S2-3200) from Manu Abraham, tree at http://jusst.de/hg/v4l-dvb-test [http://linuxtv.org/pipermail/linux-dvb/2008-October/029735.html]
* Mantis PCI bridge (e.g. [[Azurewave AD SP400 CI (VP-1041)|Azurewave AD-SP400 CI (Twinhan VP-1041)]]) see [http://linuxtv.org/pipermail/linux-dvb/2008-October/029672.html]


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

A [[Kaffeine]] patch adding S2API and DVB-S2 support, written by one of that application's authors, has
been included in the Kaffeine SVN repository. It is available here: http://linuxtv.org/pipermail/linux-dvb/2008-October/029839.html, old version here [http://linuxtv.org/pipermail/linux-dvb/2008-September/029079.html]. This has been confirmed working with
the s2 and s2-mfe (multiple frontend) trees.

A [[VDR]] patch adding S2API support for DVB-S, DVB-S2, DVB-T and DVB-C is available here:
http://linuxtv.org/pipermail/linux-dvb/2008-October/029575.html. [[VDR]] supports officially S2API since 1.7.0, but you should use the newest 1.7.x version.


Driver code is largely independent of the API used, and hooking up an existing driver to work with a different
Driver code is largely independent of the API used, and hooking up an existing driver to work with a different
Line 41: Line 70:
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. For these reasons the
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. For these reasons the
selection of the best API may be considered independently from the available ported drivers and applications.
selection of the best API may be considered independently from the available ported drivers and applications.
If S2API is chosen, the existing multiproto drivers will not be lost -- with simple modifications they will become S2API drivers. Since the information transmitted across the API to the driver simply reflects the parameters
In particular, the existing multiproto drivers will not be lost -- with simple modifications they will become S2API drivers. Since the information transmitted across the API to the driver simply reflects the parameters
defined by the digital media standards (not the receiver hardware), moving a driver to a different API simply
defined by the digital media standards (not the receiver hardware), moving a driver to a different API simply
involves packing and unpacking the same information to and from a different format.
involves packing and unpacking the same information to and from a different format.

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


===Code review and merge===
===Code review and merge===
Line 52: Line 79:
for new features, device support and bug fixes. A number of the suggested changes have been incorporated and published for code review round 2. Status report here http://linuxtv.org/pipermail/linux-dvb/2008-September/028731.html.
for new features, device support and bug fixes. A number of the suggested changes have been incorporated and published for code review round 2. Status report here http://linuxtv.org/pipermail/linux-dvb/2008-September/028731.html.


S2API will be reviewed at the Linux Plumbers' Conference in Portland, Oregon, Wed 17th - Fri 19th September 2008: http://linuxplumbersconf.org/program/microconfs/getmc.php?mc=chehab08.
S2API and multiproto were reviewed at the Linux Plumbers' Conference in Portland, Oregon, Wed 17th - Fri 19th September 2008: http://linuxplumbersconf.org/program/microconfs/getmc.php?mc=chehab08. See [http://www.linuxtv.org/downloads/presentations/plumbers2008/stoth_dvb_round_table_new_api.pdf DVB round table -- New API].

An announcement regarding the conclusions of the review was made by the maintainer : http://linuxtv.org/pipermail/linux-dvb/2008-September/029155.html. S2API was selected for inclusion
in kernel 2.6.28. It was intended to add support for products with the STB0899 demodulator (TT-3200 and others)
before then, in addition to the device support listed above. Multiproto will therefore not be included in the Linux
kernel. This decision is final.

Kernel 2.6.27 was released on 9 Oct 2008 and the merge window for kernel 2.6.28 has opened and closed.
See http://lkml.org and
http://www.linuxfoundation.org/en/Linux_Weather_Forecast. The pull request to merge the S2API tree, including API and drivers, was issued (http://linuxtv.org/pipermail/linux-dvb/2008-September/029313.html) and S2API was merged into v4l-dvb. A review of the multiple frontend tree (s2-mfe) was conducted and it was merged into v4l-dvb. A review of the STB0899 support has also been started -- users and developers are invited to comment in the mailing list linux-dvb@linuxtv.org.
Kernel 2.6.28 was released on 24 Dec 2008, including S2API and the drivers which were ready at that
time.

===Documentation===

S2API is not (hopefully not yet) documented in [http://www.linuxtv.org/docs/dvbapi/dvbapi.html DVB API documentation], the current document version describes still the old DVB API 3.2.


[[Category:Development]]
The brief merge window for kernel 2.6.28 will open when 2.6.27 is released, likely in early October. So the work needs to be ready in good time for that. See
http://www.linuxfoundation.org/en/Linux_Weather_Forecast. Release candidate 2.6.27-rc6 is now available (http://lkml.org).

Latest revision as of 18:38, 23 January 2011

S2API is a tag/value-based API which was proposed (and accepted) as version 5.0 of the LinuxDVB API, adding support for new digital media transmission standards including DVB-S2, and creating a way to allow easier support of future transmission standards. It was developed and tested in autumn 2008 and was merged into the Linux kernel version 2.6.28 which was released on 24 Dec 2008.

An RFC on a proposal for adding support for ISDB-T/ISDB-Tsb to DVB-API v5 was issued on 3 Aug 2009, with the intention of reaching consensus before the merge window for kernel version 2.6.32 was opened (9 Sep 2009). Anyone with an interest is encouraged to take part in the discussion at linux-media@vger.kernel.org. A pull request was issued on 14 Aug 2009: http://www.spinics.net/lists/linux-media/msg08896.html.

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 proposed an alternative (Aug 29 2008) and announced that they no longer supported 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 digital media 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 sets a parameter is (DTV_FREQUENCY, 11954 MHz). A tuning command sequence 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.

DiSEqC equipment control is unchanged in both S2API and multiproto APIs. Additional S2API tags to allow DiSEqC commands be sent with the tag/value method (as an alternative to the legacy method) could be implemented.

The development repositories are at http://linuxtv.org/hg/~stoth/s2 and http://linuxtv.org/hg/~stoth/s2-mfe. Tuning applications are here http://www.steventoth.net/linux/s2/ and here http://mercurial.intuxication.org/hg/szap-s2/. A channel scanning application is here http://mercurial.intuxication.org/hg/scan-s2. Work is progressing well on the finalization of the API design and porting of existing DVB-S2 drivers to work with it. Older drivers not requiring the new features can remain unchanged. Device support now includes:

Preliminary support

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.

A Kaffeine patch adding S2API and DVB-S2 support, written by one of that application's authors, has been included in the Kaffeine SVN repository. It is available here: http://linuxtv.org/pipermail/linux-dvb/2008-October/029839.html, old version here [5]. This has been confirmed working with the s2 and s2-mfe (multiple frontend) trees.

A VDR patch adding S2API support for DVB-S, DVB-S2, DVB-T and DVB-C is available here: http://linuxtv.org/pipermail/linux-dvb/2008-October/029575.html. VDR supports officially S2API since 1.7.0, but you should use the newest 1.7.x version.

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. For these reasons the selection of the best API may be considered independently from the available ported drivers and applications. In particular, the existing multiproto drivers will not be lost -- with simple modifications they will become S2API drivers. Since the information transmitted across the API to the driver simply reflects the parameters defined by the digital media standards (not the receiver hardware), moving a driver to a different API simply involves packing and unpacking the same information to and from a different format.

Code review and merge

Code review round 1 is summarized here http://linuxtv.org/pipermail/linux-dvb/2008-September/028658.html. The quality and quantity of technical feedback from developers are encouraging. Some developers have contributed patches for new features, device support and bug fixes. A number of the suggested changes have been incorporated and published for code review round 2. Status report here http://linuxtv.org/pipermail/linux-dvb/2008-September/028731.html.

S2API and multiproto were reviewed at the Linux Plumbers' Conference in Portland, Oregon, Wed 17th - Fri 19th September 2008: http://linuxplumbersconf.org/program/microconfs/getmc.php?mc=chehab08. See DVB round table -- New API.

An announcement regarding the conclusions of the review was made by the maintainer : http://linuxtv.org/pipermail/linux-dvb/2008-September/029155.html. S2API was selected for inclusion in kernel 2.6.28. It was intended to add support for products with the STB0899 demodulator (TT-3200 and others) before then, in addition to the device support listed above. Multiproto will therefore not be included in the Linux kernel. This decision is final.

Kernel 2.6.27 was released on 9 Oct 2008 and the merge window for kernel 2.6.28 has opened and closed. See http://lkml.org and http://www.linuxfoundation.org/en/Linux_Weather_Forecast. The pull request to merge the S2API tree, including API and drivers, was issued (http://linuxtv.org/pipermail/linux-dvb/2008-September/029313.html) and S2API was merged into v4l-dvb. A review of the multiple frontend tree (s2-mfe) was conducted and it was merged into v4l-dvb. A review of the STB0899 support has also been started -- users and developers are invited to comment in the mailing list linux-dvb@linuxtv.org. Kernel 2.6.28 was released on 24 Dec 2008, including S2API and the drivers which were ready at that time.

Documentation

S2API is not (hopefully not yet) documented in DVB API documentation, the current document version describes still the old DVB API 3.2.