[steve@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined]
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Steve Kerrison <steve@stevekerrison.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some (North American) providers use a non-standard mode called
"8psk turbo fec". Since there is no flag in the driver that
would allow an application to determine whether a particular
device can handle "turbo fec", the attached patch introduces
FE_CAN_TURBO_FEC.
Since there is no flag in the SI data that would indicate
that a transponder uses "turbo fec", VDR will assume that
all 8psk transponders on DVB-S use "turbo fec".
Tested-by: Derek Kelly <user.vdr@gmail.com>
Signed-off-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In ISDB-S, time-devision duplex is used to multiplexing several waves
in the same frequency. Each wave is identified by its own transport
stream ID, or TS ID. We need to provide some way to specify this ID
from user applications to handle ISDB-S frontends.
This code has been tested with the Earthsoft PT1 driver.
[mchehab@infradead.org: Fix merge conflicts with isdbt and rename the new parameter to DTV_ISDBS_TS_ID]
Signed-off-by: HIRANO Takahito <hiranotaka@zng.info>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch increments the DVB-API to version 5.1 in order to reflect the addition of ISDB-T and ISDB-Tsb on Linux' DVB-API.
Changes in detail:
- added a small document to describe how to use the API to tune to an ISDB-T or ISDB-Tsb channel
- added necessary fields to dtv_frontend_cache
- added a smarter clear-cache function which resets all fields of the dtv_frontend_cache
- added a TRANSMISSION_MODE_4K to fe_transmit_mode_t
Signed-off-by: Olivier Grenie <olgrenie@dibcom.fr>
Signed-off-by: Patrick Boettcher <pboettcher@dibcom.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
fix the following 'make headers_check' warnings:
usr/include/linux/dvb/frontend.h:29: include of <linux/types.h> is preferred over <asm/types.h>
usr/include/linux/dvb/frontend.h:76: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
The attached patch adds a capability flag that allows an application
to determine whether a particular device can handle "second generation
modulation" transponders. This is necessary in order for applications
to be able to decide which device to use for a given channel in
a multi device environment, where DVB-S and DVB-S2 devices are mixed.
It is assumed that a device capable of handling "second generation
modulation" can implicitly handle "first generation modulation".
The flag is not named anything with DVBS2 in order to allow its
use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
Acked-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A user tuning DVB-T via the S2API reports that this was not implemented,
and his tuning was failing.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tuning DVB-T via the S2API was failing, missing some essential items.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reports from users that using the new API for tuning DTV was failing,
and the cache was missing some essential items.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reviewing the code briefly and saw this.
You can't change more than DTV_IOCTL_MAX_MSGS at once, not 16.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
... and cleanup any drivers using them.
I've also removed NBC_QPSK and modified the cx24116 driver to check
the delivery_type also, removing some excess namespace baggage.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This means that when developers add new commands then they'll be see
the DTV_MAX_COMMAND define and will be more likely to modify it, without
having to modify the command validation code.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This allows application developers to query the dvb-core API version
dynamically, helping developers understand whether certain features
will be available.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This allows application developers to determine which particular
command in a sequence is invalid, or failing with error.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We don't want to push the ISDB-T definitions into the kernel until
we have a high level of confidence in the ISDB-T API. More testing
is required before this code is released.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Also added some compat code for the older API.
Added more ISDB message/command suggestions, current not connected in dvb-core.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The API now assumes that ioctl calls for FE_SET_PROPERTY and all
set commands, and FE_GET_PROPERTY are get commands.
Simplification.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After discussion the following changes were made:
1. Removed the typedefs in frontend.h, use structures.
2. In the frontend.h, remove the 16 command limit on the API and
switch to a flexible variable length API. For practical reasons
a #define limits this to 64, this should be discussed.
3. Changed dvb-core ioctl handing to deal with variable sequences
of commands.
tune-v0.0.3.c is required to use this API, it contains the interface changes.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The group preferred dtv_ over tv_, this implements it.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Implement frontend-specific tuning and the ability to disable zigzag
Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Andreas Oberritter