Multiproto

Multiproto is a proposal for version 3.3 of the linux DVB API which includes extensions for cards which support multiple DVB protocols (DVB-S, DVB-S2, DVB-T, DVB-C, DVB-H, ATSC, DSS).

It is an experimental project and is not currently implemented in any released version of Linux. No firm plan has been made for its inclusion in Linux. Even worse, the author of some of the main parts of multiproto has
incomprehensibly attempted
to block its inclusion in Linux, highlighting both misunderstanding of the implications of the GPL and weak
project management within the Linux DVB community
http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023355.html.

Overview/Features

Discuss the features and facets of the project here ... this means you

Design Decisions

explain the choices made ... this means you

Technical Details

give a technical description of how the API change has been implemented ... this means you

New structs and enums have been added to expand the API for multiple frontends and the parameters required for protocols DVB-S, DSS, DVB-S2, DVB-T, DVB-H and ATSC. These are prefixed (at least for now) with "dvbfe_" and "DVBFE_" as opposed to the old "fe_" and "FE_". For details compare the old and new versions of include/linux/dvb/frontend.h. Currently multiproto implements both the new and old APIs and a glue layer to manage old/new drivers with new/old API calls. Presumably the plan is eventually to move to a pure 3.3 API and update all the drivers.

Evaluation

explain whether the design goals have been met or not ... this means you

1. Some application of Occam's Razor still needs to be made. There is repetition in the multiproto API arising from the use of
unions of structs to hold parameters (often the same ones) for each type of frontend.
However API calls (eg. ioctl dvbfe_params) can be addressed to individual frontends, i.e.
/dev/dvb/adapterN/frontendM, so this repetition could be removed to create a cleaner API. For example these variables:

If we simplify in this way, the relevant section of linux/include/linux/dvb/frontend.h would look like this:
(note I added _caps to some variables to indicate that they are actually ORd sets of capabilities)

2. There is a problem with the design of the multiproto API. The routine DVBFE_GET_INFO actually changes the kernel state (in particular the variable which holds the delivery system). Simply calling DVBFE_SET_PARAMS with a complete correct set of parameters does not work. The corresponding screwy userspace code can be seen in the patched http://abraham.manu.googlepages.com/szap.c where DVBFE_GET_INFO is used to SET the delivery system variable before DVBFE_SET_PARAMS is called. Such odd unexpected behaviour is confusing and should not be accepted in the Linux kernel. At the very least some work needs to be done to rename the routines sensibly. DVBFE_GET_INFO appears to have been
originally intended to provide information about the capabilities of the frontend, which is currently not apparent in its name. See http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024266.html and http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024281.html.

UPDATE March 09 2008: This appears to have been changed with the introduction of DVBFE_SET_DELSYS which is now used
to set the delivery system. Tuning is done with szap2. Unfortunately the variable delsys has been completely removed from the struct dvbfe_info, instead of just making it a user-readable variable (not a writeable one), analogous to the "type" variable in the old dvb_frontend_info (but with a different range of values, i.e. DVB-S/S2/C/T/H/DSS/ATSC vs. QPSK/QAM/OFDM/ATSC). It would be nice if delsys were put back in, with code to set its
value appropriately on DVBFE_GET_INFO calls.

Alternatives

Tag/Value-based API proposal
Amid 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. 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.
The design is somewhat
atomic in that a
whole command sequence may be passed in a single
ioctl. A notable advantage of this 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. A patch is available 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. Other drivers
are not affected.

Status and Migration Plan

explain how a migration from the current API to multiproto could be achieved ... this means you

No clear migration plan has yet been agreed.

The mantis tree (http://jusst.de/hg/mantis) which also uses the multiproto API has not yet been merged into multiproto, meaning that there is unnecessary duplication of the core code and any code fixes in either
tree are not automatically applied to both trees.

provide the details of where the drivers and patches and necessary tools are available ... this means you

provide details of how to compile for recent kernels -- this means you

Sample kernel output

provide the relevant portion of dmesg here

Tuner / DiSEqC / Player support

provide comprehensive details of how to upgrade multimedia applications to work with the new API ... this means you

Scanning and tuning applications generally will not work with the new API unless they are modified. The situation is arguably improving but the lack of patched applications (and guidance on patching) has hindered completion and testing of multiproto and new drivers, and adoption of the new API. Needless to say, patching drivers and multiple applications is a step too far for most potential testers.

dvb-apps : There is still no patched dvb-apps tree. Someone needs to create one ... why don't you?