Am 03.11.2011 08:49, schrieb Steffen Barszus:
Hi !
From a users point of view i would like to have some clarification on
this discussion.
Lets take a (now real world) example.
Having
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1
/dev/dvb/adapter0/net0
/dev/dvb/adapter1/demux0
/dev/dvb/adapter1/dvr0
/dev/dvb/adapter1/frontend0
/dev/dvb/adapter1/frontend1
/dev/dvb/adapter1/net0
for a C/T card, where one fe is C and the other is T , connector is
only one per adapter.
How is the logic to handle this ?
Two big issues i don't properly understand at the moment.
1.) VDR does not know that frontend1 is
related to demux0. since no application changes magically on its own,
can someone provide some information of what an application is expected
to do, to handle this properly. With this information it could be
discussed at i.e. vdr mailing list.
2.) How does an application/user/whatever know what can be used ?
I mean there is only C connected OR T - how can the application know
what fe can be used (assumed point 1. has been fixed). How would the
user know, which is which and how one should specify what is
connected ?
3.) ca/caio device handling - is this something an application should
implement ... and how.
Please help me to understand these points as this is something which
pops up regular in discussion with our (yavdr.org) users.
For 1 and 2 the only proper solution i see would be 1 frontend instead
of 2 with a possibility to specifiy the transport in one way or
another. (which -> to be discussed)
For me as an application developer it wouldn't make sense if the frontend handles multiple delivery types as outlined
in approach 2 and 3 from below. That would mean that *every* application has to ask the user and must provide some
configuration possibility. And there has to be a new ioctl to set the delivery type (or is there one I don't know about?).
Either I have DVB-C or DVB-T. So I would like to specify the delivery type at module load time with an option. Then
there would be one frontend and every (existent) application would "just work". And it's configured at one place.
Everyone who changes the connection frequently should learn to reload the module... :-)
Regards,
Lars.
Regards
Steffen
On Sat, 16 Jul 2011 17:40:53 +0200
Oliver Endriss<o.endriss@xxxxxx> wrote:
On Saturday 16 July 2011 16:54:50 Mauro Carvalho Chehab wrote:
Em 16-07-2011 11:16, Antti Palosaari escreveu:
On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote:
Em 15-07-2011 20:41, Antti Palosaari escreveu:
On 07/15/2011 08:01 PM, Andreas Oberritter wrote:
On 15.07.2011 15:25, Mauro Carvalho Chehab wrote:
Em 15-07-2011 05:26, Ralph Metzler escreveu:
At the same time I want to add delivery system properties to
support everything in one frontend device.
Adding a parameter to select C or T as default should help
in most cases where the application does not support
switching yet.
If I understood well, creating a multi-delivery type of
frontend for devices like DRX-K makes sense for me.
We need to take some care about how to add support for them,
to avoid breaking userspace, or to follow kernel deprecating
rules, by adding some legacy compatibility glue for a few
kernel versions. So, the sooner we add such support, the
better, as less drivers will need to support a "fallback"
mechanism.
The current DVB version 5 API doesn't prevent some userspace
application to change the delivery system[1] for a given
frontend. This feature is actually used by DVB-T2 and DVB-S2
drivers. This actually improved the DVB API multi-fe support,
by avoiding the need of create of a secondary frontend for
T2/S2.
Userspace applications can detect that feature by using
FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow
other types of changes like from/to DVB-T/DVB-C or from/to
DVB-T/ISDB-T. So, drivers that allow such type of delivery
system switch, using the same chip ended by needing to add
two frontends.
Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to
fe_caps_t, and add a way to query the type of delivery
systems supported by a driver.
[1]
http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM
I don't think it's necessary to add a new flag. It should be
sufficient to add a property like
"DTV_SUPPORTED_DELIVERY_SYSTEMS", which should be read-only
and return an array of type fe_delivery_system_t.
Querying this new property on present kernels hopefully fails
with a non-zero return code. in which case FE_GET_INFO should
be used to query the delivery system.
In future kernels we can provide a default implementation,
returning exactly one fe_delivery_system_t for unported
drivers. Other drivers should be able to override this default
implementation in their get_property callback.
One thing I want to say is that consider about devices which
does have MFE using two different *physical* demods, not
integrated to same silicon.
If you add such FE delsys switch mechanism it needs some more
glue to bind two physical FEs to one virtual FE. I see much
easier to keep all FEs as own - just register those under the
same adapter if FEs are shared.
In this case, the driver should just create two frontends, as
currently.
There's a difference when there are two physical FE's and just
one FE: with 2 FE's, the userspace application can just keep
both opened at the same time. Some applications (like vdr)
assumes that all multi-fe are like that.
Does this mean demod is not sleeping (.init() called)?
When there's just a single FE, but the driver needs to "fork" it
in two due to the API troubles, the driver needs to prevent the
usage of both fe's, either at open or at the ioctl level. So,
applications like vdr will only use the first frontend.
Lets take example. There is shared MFE having DVB-S, DVB-T and
DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S
have own.
Currently it will shown as:
Let me name the approaches:
Approach 1)
* adapter0
** frontend0 (DVB-S)
** frontend1 (DVB-T)
** frontend2 (DVB-C)
Approach 2)
Your new "ideal" solution will be:
* adapter0
** frontend0 (DVB-S/T/C)
Approach 3)
What really happens (mixed old and new):
Why does this happen?
* adapter0
** frontend0 (DVB-S)
** frontend1 (DVB-T/C)
What I've said before is that approach 3 is the "ideal" solution.
No, sorry.
It does not look very good to offer this kind of mixed solution,
since it is possible to offer only one solution for userspace,
new or old, but not mixing.
Good point.
There's an additional aspect to handle: if a driver that uses
approach 1, a conversion to either approach 2 or 3 would break
existing applications that can't handle with the new approach.
There's a 4th posibility: always offering fe0 with MFE
capabilities, and creating additional fe's for old applications
that can't cope with the new mode. For example, on a device that
supports DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown
as:
Approach 4) fe0 is a frontend "superset"
*adapter0
*frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE
superset *frontend1 (DVB-S/DVB-S2)
*frontend2 (DVB-T/DVB-T2)
*frontend3 (DVB-C)
*frontend4 (ISDB-T)
fe0 will need some special logic to allow redirecting a FE call to
the right fe, if there are more than one physical frontend bound
into the FE API.
I'm starting to think that (4) is the better approach, as it won't
break legacy applications, and it will provide an easier way for
new applications to control the frontend with just one frontend.
Nack. Do not make it more complicated than neccessary!
Approach (2) is the way to go.
I consider the current way as a clear abuse of the DVB API.
It is a bug, not a feature!
Originally it was intended to support multiple data paths per adapter.
For example, A dual tuner DVB-S card should have been implemented as
one adapter:
adapterX +--- demux0/frontend0/ca0/dvr0/net0
|
+--- demux1/frontend1/ca1/dvr1/net1
(Both tuners can be used concurrently without limitations.)
My proposal is:
If there is any kind of shared hardware, i.e. the application cannot
use both adapters independently, these hardware must be folded into a
single frontend.
It is not so hard to implement, even for separate chips:
The driver just has to "switch" from one set of frontend ops to
another.
Btw, which applications do really handle this fronten0/1 stuff
correctly? VDR definitely does not. Access to the frontend1 fails.
CU
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
