leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

media: dvbproperty.rst: improve notes about legacy frontend calls

Browse Source 
The description of the DVBv5 API was written a long time ago,
where the API was still new, and there were not apps using it.

Now that the API is stable and used by new applications, clarify
that DVBv3 calls should not be used and why.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This commit is contained in:
Mauro Carvalho Chehab 2017-08-26 06:07:13 -04:00
parent e9dc0f827f
commit 1e1d9c9679
1 changed files with 25 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
Documentation/media/uapi/dvb/dvbproperty.rst
View File

@ -12,23 +12,34 @@ antenna subsystem via Satellite Equipment Control (SEC), on satellite
systems. The actual parameters are specific to each particular digital systems. The actual parameters are specific to each particular digital
TV standards, and may change as the digital TV specs evolves. 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 In the past (up to DVB API version 3), the strategy used was to have a
needed to tune for DVB-S, DVB-C, DVB-T and ATSC delivery systems grouped union with the parameters needed to tune for DVB-S, DVB-C, DVB-T and
there. The problem is that, as the second generation standards appeared, ATSC delivery systems grouped there. The problem is that, as the second
those structs were not big enough to contain the additional parameters. generation standards appeared, the size of such union was not big
Also, the union didn't have any space left to be expanded without enough to group the structs that would be required for those new
breaking userspace. So, the decision was to deprecate the legacy standards. Also, extending it would break userspace.
union/struct based approach, in favor of a properties set approach.
So, the legacy union/struct based approach was deprecated, in favor
of a properties set approach.
This section describes the new and recommended way to set the frontend,
with suppports all digital TV delivery systems.
.. note:: .. note::
On Linux DVB API version 3, setting a frontend were done via 1. On Linux DVB API version 3, setting a frontend was done via
struct :c:type:`dvb_frontend_parameters`. struct :c:type:`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 2. Don't use DVB API version 3 calls on hardware with supports
old API has a very limited support to new standards and new hardware. newer standards. Such API provides no suport or a very limited
This section describes the new and recommended way to set the frontend, support to new standards and/or new hardware.
with suppports all digital TV delivery systems.
3. Nowadays, most frontends support multiple delivery systems.
Only with DVB v5 calls it is possible to switch between
the multiple delivery systems supported by a frontend.
4. DVB API version 5 is also called *S2API*, as the first
new standard added to it was DVB-S2.
Example: with the properties based approach, in order to set the tuner 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 to a DVB-C channel at 651 kHz, modulated with 256-QAM, FEC 3/4 and