Re: multiple frontends on a single dvb adapter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2017-12-01 12:38 GMT+01:00 pieterg <pieterg@xxxxxxx>:
> 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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux