multiple frontends on a single dvb adapter
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
2017-12-01 12:38 GMT+01:00 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. 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
Em Fri, 1 Dec 2017 12:38:14 +0100 pieterg 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
