multiple frontends on a single dvb adapter

multiple frontends on a single dvb adapter

[pieterg]

Hi,

The recent removal of DMX_SET_SOURCE

https://github.com/torvalds/linux/commit/13adefbe9e566c6db91579e4ce17f1e5193d6f2c

and earlier removal of the set_source callback

https://github.com/torvalds/linux/commit/1e92bbe08ad9fc0d5ec05174c176a9bc54921733

leads to the question how the situation of having multiple frontends on
a single dvb adapter should be handled nowadays.
Suppose the routing is flexible, any demux could be sourced by any frontend.
In the past, this has been achieved by using the set_source callback,
allowing userspace to configure the routing by using the DMX_SET_SOURCE
ioctl.

The connect_frontend / disconnect_frontend callbacks are currently only
called for the memory frontend, so it seems no longer possible to select
hardware frontends.
How do you guys see this, what does the standard dictate in this case?
Should we assume a 1:1 mapping between frontendN:demuxN and forbid
dynamic routing? Or am I overlooking something?

In my opinion, supporting dynamic routing would be an advantage.
Especially when the number of (hardware) demuxes is smaller than the
number of (hardware) frontends.

Regards,
Pieter

Re: multiple frontends on a single dvb adapter

[Honza Petrouš]

2017-12-01 12:38 GMT+01:00 pieterg <pieterg@gmx.com>:
> Hi,
>
> The recent removal of DMX_SET_SOURCE
>
> https://github.com/torvalds/linux/commit/13adefbe9e566c6db91579e4ce17f1e5193d6f2c
>
> and earlier removal of the set_source callback
>
> https://github.com/torvalds/linux/commit/1e92bbe08ad9fc0d5ec05174c176a9bc54921733
>
> leads to the question how the situation of having multiple frontends on
> a single dvb adapter should be handled nowadays.
> Suppose the routing is flexible, any demux could be sourced by any frontend.
> In the past, this has been achieved by using the set_source callback,
> allowing userspace to configure the routing by using the DMX_SET_SOURCE
> ioctl.
>
> The connect_frontend / disconnect_frontend callbacks are currently only
> called for the memory frontend, so it seems no longer possible to select
> hardware frontends.
> How do you guys see this, what does the standard dictate in this case?
> Should we assume a 1:1 mapping between frontendN:demuxN and forbid
> dynamic routing? Or am I overlooking something?
>
> In my opinion, supporting dynamic routing would be an advantage.
> Especially when the number of (hardware) demuxes is smaller than the
> number of (hardware) frontends.


It was already discussed with Mauro, when me (and may be some others
complained about such removals).

The rule is simple - if you have HW with multiple frontends, then you can
provide patch and revive the old stuffs.

Mauro's POV is = no user of such callbacks/ioctl means removal of that.

/Honza

Re: multiple frontends on a single dvb adapter

[Mauro Carvalho Chehab]

Em Fri, 1 Dec 2017 12:38:14 +0100
pieterg <pieterg@gmx.com> escreveu:

> Hi,
> 
> The recent removal of DMX_SET_SOURCE
> 
> https://github.com/torvalds/linux/commit/13adefbe9e566c6db91579e4ce17f1e5193d6f2c
> 
> and earlier removal of the set_source callback
> 
> https://github.com/torvalds/linux/commit/1e92bbe08ad9fc0d5ec05174c176a9bc54921733
> 
> leads to the question how the situation of having multiple frontends on
> a single dvb adapter should be handled nowadays.
> Suppose the routing is flexible, any demux could be sourced by any frontend.
> In the past, this has been achieved by using the set_source callback,
> allowing userspace to configure the routing by using the DMX_SET_SOURCE
> ioctl.
> 
> The connect_frontend / disconnect_frontend callbacks are currently only
> called for the memory frontend, so it seems no longer possible to select
> hardware frontends.
> How do you guys see this, what does the standard dictate in this case?
> Should we assume a 1:1 mapping between frontendN:demuxN and forbid
> dynamic routing? Or am I overlooking something?
> 
> In my opinion, supporting dynamic routing would be an advantage.
> Especially when the number of (hardware) demuxes is smaller than the
> number of (hardware) frontends.

The best way to support dynamic routing is via the media controller
API. the DVB core already creates media controller entities for
the existing hardware, but the links for the non-trivial case
(e. g. there's no 1:1 mapping) should be created by the driver.

The big advantage of using the media controller is that you could
dynamically setup the pipeline, not only between frontend and
demux, but also with some other hardware. For example, with that,
you could easily add a CI module at the pipeline, for an scrambled
channel, or remove it, when the channel doesn't require, or when
it is required to store a movie scrambled (that's usually required
for embedded systems). At reproduction, a pipeline with the CI
descrambler could be used.


Thanks,
Mauro