Documentation/userspace-api/media/dvb/dvbproperty.rst
Source file repositories/reference/linux-study-clean/Documentation/userspace-api/media/dvb/dvbproperty.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/userspace-api/media/dvb/dvbproperty.rst- Extension
.rst- Size
- 4326 bytes
- Lines
- 127
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
stdio.hfcntl.hsys/ioctl.hlinux/dvb/frontend.h
Detected Declarations
function main
Annotated Snippet
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _frontend-properties:
**************
Property types
**************
Tuning into a Digital TV physical channel and starting decoding it
requires changing a set of parameters, in order to control the tuner,
the demodulator, the Linear Low-noise Amplifier (LNA) and to set the
antenna subsystem via Satellite Equipment Control - SEC (on satellite
systems). The actual parameters are specific to each particular digital
TV standards, and may change as the digital TV specs evolves.
In the past (up to DVB API version 3 - DVBv3), the strategy used was to have a
union with the parameters needed to tune for DVB-S, DVB-C, DVB-T and
ATSC delivery systems grouped there. The problem is that, as the second
generation standards appeared, the size of such union was not big
enough to group the structs that would be required for those new
standards. Also, extending it would break userspace.
So, the legacy union/struct based approach was deprecated, in favor
of a properties set approach. On such approach,
:ref:`FE_GET_PROPERTY and FE_SET_PROPERTY <FE_GET_PROPERTY>` are used
to setup the frontend and read its status.
The actual action is determined by a set of dtv_property cmd/data pairs.
With one single ioctl, is possible to get/set up to 64 properties.
This section describes the new and recommended way to set the frontend,
with supports all digital TV delivery systems.
.. note::
1. On Linux DVB API version 3, setting a frontend was done via
struct :c:type:`dvb_frontend_parameters`.
2. Don't use DVB API version 3 calls on hardware with supports
newer standards. Such API provides no support or a very limited
support to new standards and/or new hardware.
3. Nowadays, most frontends support multiple delivery systems.
Only with DVB API version 5 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**: in order to set the hardware to tune into a DVB-C channel
at 651 kHz, modulated with 256-QAM, FEC 3/4 and symbol rate of 5.217
Mbauds, those properties should be sent to
:ref:`FE_SET_PROPERTY <FE_GET_PROPERTY>` ioctl:
:ref:`DTV_DELIVERY_SYSTEM <DTV-DELIVERY-SYSTEM>` = SYS_DVBC_ANNEX_A
:ref:`DTV_FREQUENCY <DTV-FREQUENCY>` = 651000000
:ref:`DTV_MODULATION <DTV-MODULATION>` = QAM_256
:ref:`DTV_INVERSION <DTV-INVERSION>` = INVERSION_AUTO
:ref:`DTV_SYMBOL_RATE <DTV-SYMBOL-RATE>` = 5217000
:ref:`DTV_INNER_FEC <DTV-INNER-FEC>` = FEC_3_4
:ref:`DTV_TUNE <DTV-TUNE>`
The code that would that would do the above is show in
:ref:`dtv-prop-example`.
Annotation
- Immediate include surface: `stdio.h`, `fcntl.h`, `sys/ioctl.h`, `linux/dvb/frontend.h`.
- Detected declarations: `function main`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.