Multiproto: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
Line 22: Line 22:
unions of structs to hold parameters (often the same ones) for each type of frontend.
unions of structs to hold parameters (often the same ones) for each type of frontend.
However API calls (eg. ioctl dvbfe_params) are addressed to an individual frontend
However API calls (eg. ioctl dvbfe_params) are addressed to an individual frontend
/dev/dvb/adapterN/frontendN so this repetition could be removed.
/dev/dvb/adapterN/frontendN so this repetition could be removed to create a cleaner
API. For example these variables:

dvbfe_params.delsys.dvbs.fec
dvbfe_params.delsys.dss.fec
dvbfe_params.delsys.dvbs2.fec
dvbfe_params.delsys.dvbc.fec

could be replaced by the simpler:

dvbfe_params.fec

Similarly for a number of other variables.


===Status and Migration Plan===
===Status and Migration Plan===

Revision as of 10:22, 27 February 2008

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.

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.

Simple enough you might think, but progress has been very slow. Since the first version, way back in April 2006, eight (8) versions of the entire Linux kernel have been released. See http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009522.html and http://kernelnewbies.org/Linux26Changes.

Evaluation and Alternatives

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

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) are addressed to an individual frontend /dev/dvb/adapterN/frontendN so this repetition could be removed to create a cleaner API. For example these variables:

dvbfe_params.delsys.dvbs.fec
dvbfe_params.delsys.dss.fec
dvbfe_params.delsys.dvbs2.fec
dvbfe_params.delsys.dvbc.fec

could be replaced by the simpler:

dvbfe_params.fec

Similarly for a number of other variables.

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.

Making it Work

How to get it:

hg clone http://jusst.de/hg/multiproto

or

http://jusst.de/hg/multiproto/archive/tip.tar.bz2

Drivers

There are currently no in-kernel multiproto drivers. There are several cards which have experimental support in the multiproto tree, perhaps with additional patches.

Provide details of which drivers work with multiproto ... this means you

See the descriptions for the following cards:

Azurewave AD-SP400 CI (Twinhan VP-1041)

Hauppauge WinTV-HVR-4000

TechnoTrend TT-budget S2-3200

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?

scan : see patched version at http://jusst.de/manu/scan.tar.bz2

szap: see patched version at http://abraham.manu.googlepages.com/szap.c Also see information about szap2 at http://allrussian.info/thread.php?postid=187408#post187408 and http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023836.html.

mplayer : someone needs to write a patch ... why don't you?

Kaffeine : someone needs to write a patch ... why don't you?

VDR : VDR version 1.5.14 and later require multiproto (v1.5.14 announcement: http://www.linuxtv.org/pipermail/vdr/2008-January/015302.html

MythTV : Two patches (one DVB-S/S2, one DVB-S only) have been posted http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022757.html. Current status?

dvbstream : Someone needs to write a patch ... why don't you? See http://www.linuxtv.org/pipermail/linux-dvb/2008-February/024056.html.

provide details of how to use with DiSEqC -- this means you

How to patch an application for Multiproto

provide guidance on patching applications to use multiproto -- this means you

To tune to a channel : using the patched szap above as a guide we see that

struct dvb_frontend_parameters tuneto;
...
ioctl(fefd, FE_SET_FRONTEND, &tuneto);

must be replaced by

struct dvbfe_params fe_params;
...
ioctl(fefd, DVBFE_SET_PARAMS, &fe_params);

where the parts of dvbfe_params.delsys relevant for the delivery system used (DVB-S/DSS/DVB-S2) need to be set before the call.

External Links