Re: Proposed modifications to dvb_frontend_ops

Chris Lee
2013-07-23T16:47:12Z

Not all tuners support all fec's

- genpix devices support an odd 5/11 fec for digicipher, pretty sure
no one else does.
- stv0899 supports 1/2, 2/3, 3/4, 5/6, 6/7, 7/8
- stv0900 supports 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10

Not all tuners support the entire range of fec's. I think this is more
the norm then the exception.

If the userland application can poll the driver for a list of
supported fec it allows them to have a list of valid tuning options
for the user to choose from, vs listing everything and hoping it
doesnt fail.

As stated Id much rather have a list made up from system -> modulation -> fec.

ie genpix

SYS_TURBO -> QPSK/8PSK
SYS_TURBO.QPSK -> 1/2, 2/3, 3/4, 5/6, 7/8
SYS_TURBO.8PSK -> 2/3, 3/4, 5/6, 8/9

but that could get more complicated to implement pretty quickly

Chris Lee

On Tue, Jul 23, 2013 at 7:35 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
> On Sat, Jul 20, 2013 at 1:57 AM, Chris Lee <updatelee@gmail.com> wrote:
>> In frontend.h we have a struct called dvb_frontend_ops, in there we
>> have an element called delsys to show the delivery systems supported
>> by the tuner, Id like to propose we add onto that with delmod and
>> delfec.
>>
>> Its not a perfect solution as sometimes a specific modulation or fec
>> is only availible on specific systems. But its better then what we
>> have now. The struct fe_caps isnt really suited for this, its missing
>> many systems, modulations, and fec's. Its just not expandable enough
>> to get all the supported sys/mod/fec a tuner supports in there.
>
> Question > Why should an application know all the modulations and
> FEC's supported by a demodulator ?
>
> Aren't demodulators compliant to their respective delivery systems ?
>
> Or do you mean to state that, you are trying to work around some
> demodulator quirks ?
>
>
> Regards,
>
> Manu