Re: [Regression 5.14] media: dvb userspace api

[Manu Abraham <abraham.manu@gmail.com>]

On Wed, Aug 25, 2021 at 12:03 PM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Em Wed, 25 Aug 2021 08:25:57 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
> > On Mon, Aug 23, 2021 at 10:30 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > I have reverted the header file move. But I would also heartily
> > > recommend that whatever user program includes those headers (VDR -
> > > anything else?) should take snapshots of these specific kernel
> > > headers.
> > >
> > > I'm not convinced that it makes sense to move the av7110 driver back
> > > from staging - it may continue to work, but it _is_ old and there is
> > > no maintenance - and I would certainly suggest that any other
> > > out-of-tree driver that uses these old interfaces that nothing else
> > > implements shouldn't do so, considering that nothing else implements
> > > them.
> >
> > Sorry for barging in between your discussion, but it seemed like you really
> > missed some perspective and hence.
> >
> > My 2 cents worth:
> > * Revert the header changes.
> >
> > * Let someone else with knowledge of it take over the maintenance
> > of the av7110 driver.
> >
> >   - This would allow other hardware also to be easily accommodated
> > in a similar manner.
> >
> > * Pull the out of tree drivers and allocate maintenance of those, to
> > someone who understands them. Don't you want more hardware to be
> > supported out of the box ?
> >
> > Should there be no driver for those DVB output hardware, but only for
> > V4L2 output devices ?
> >
> > There exists other hardware which As a person who worked on another
> > av7110 like driver (saa716x based s2 6400), which I can confirm.
> > The API is supposed to simplify life, not make it even more complex.
> > These devices would need lot of workarounds to work with the API that
> > which Mauro advocates, which might even break those drivers given
> > their complexity and size.
> >
> > It would make life a lot easier for the users, Mauro himself and
> > this long never ending discussion can be put to rest.
>
> The "full-featured" API that it is implemented on av7110 always had
> troubles. This is not only my view, but also the view of the
> original API authors,as can be seen at the DVBv4 WIP documentation:
>
>         https://www.linuxtv.org/downloads/legacy/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf
>
> It clearly says that, on chapter 2.2:
>
>         "2.2 Linux DVB API Version 3 problems


That's very misleading ! In fact, the legacy V3 API was upgraded to 3.1 and 3.2
and those issues were ironed out. You are talking about V3 while V3.2
fixed those
issues. The V4 API documentation is legacy and was there even before the
V3.2 API existed. It was even upgraded to V5, skipping V4 !


>
>          The Linux DVB API Version 3 has very limited support for
>          modern hardware."
>
> The "modern" there refers to hardware back in 2005!


This is exactly what I wrote just above.


> I worked on a project back 8 years ago that tried to use it for TV
> sets. It didn't work, because the API assumed a 1:1 mapping between
> tuners and A/V codecs, which works for simpler embedded hardware,
> but didn't cover smart TV hardware, where the number of frontends,
> demods and A/V codecs were different. You may even have multiple
> channels being displayed at the same time (Picture in Picture).
>
> On today's embedded hardware, you need something like the media
> controller, in order to dynamically re-configure the hardware
> pipelines between:
>
>         - multiple tuners (DVB-C, DVB-T/T2, DVB-S/S2);
>         - multiple demods[1];
>         - multiple A/V decoders;
>         - display compositor;
>         - audio I/O;
>         - CA modules;
>         - encrypt/decrypt hardware (required on some Countries in order
>           to allow recording programs on storage);
>         - storage.


Multiple frontends, tuners/demods, CAM's were already supported
There is no encrypt/decrypt hardware, either you have hardware
CAM's or SoftCAM's, which do the decryption for DVB streams.
These already exist with the old API itself.
The S2 6400, KNC S2 Twin and most others do have multiple first
and second generation frontends.

The DVB demux provides multiple PID's, you can have multiple PiP's
whatever you want.

For some SoC's with A/V codecs what you are saying is true.
It does not make sense for PCTV hardware to use the pipelines
you apparently describe. Such SoC's make use the extended API that
you advocate, but the standard PCTV, or standard STB hardware
we all are used to need not use the convoluted API being advocated.
For those SoC's one may use the V4L2 output. But for DVB output
devices, it makes no sense but going many steps backwards to use
the V4L2 output.


> From driver's perspective, it makes no sense to keep support for av7110,
> as TI stopped production of TMS320AV7110 a very long time ago. They
> don't even mention this product number anymore on their website.
>

What I meant: If there are some users for some hardware, it is impolite
to rip them out, especially when someone is volunteering to maintain them.
Rather than impolite, that's quite rude and arrogant.

I believe that is the de facto Linux kernel principle still, unless
there is some
real reason to rip it out.

FWIW, my 2c worth:
a) leave the headers where they belong, already done by Linus.

b) av7110: hand over the maintenance to someone who is happy and has
time to fiddle around with

c) Pull in the saa716x driver. I wrote the saa716x driver with NXP support
and with additional help from the community. It would be good to maintain
the credits to the original developers though.

You can pull the saa716x driver from Soeren, if he needs some help,
I can chip in whatever possible way. Let him have some fun with the driver.

Mauro: Look, it's not good to convolute and pollute the discussion with stuff
that are not relevant. Please! Have a heart; Don't do this drama..
People will just hate you for eons, for no good reason !

Friendly Regards,
MA