On Tue, Nov 22, 2005, Felix Domke wrote:
> in the tuxbox irc channel we were discussing how to tune to DVB-S2
> transponders, of course using all that not-yet-existing (at least not in
> numbers) hardware which we all wait for.
>
> The problem is that the current dvb_qpsk_parameters cannot really be
> extended without breaking backward compatibility, and still, -S2 isn't
> strictly QPSK but QAM too, but on the other hand has nothing to do with
> DVB-C and the already defined dvb_qam_parameters.
Maybe we should finally rename FE_QPSK etc. and dvb_qpsk_parameters etc.
to FE_TYPE_DVB_S etc. and dvb_tuning_parameters_dvb_t etc.,
and provide backwards compat #defines for "old" apps?
This wouldn't create binary compatibilty problems.
> Basically we had two ideas:
>
> The first one was:
>
> #define FE_SET_FRONTEND_EX _IOW('o', xx, struct
> dvb_frontend_parameters_ex)
>
> #define FE_STANDARD_DVB_S 0
> #define FE_STANDARD_DVB_C 1
> #define FE_STANDARD_DVB_T 2
> #define FE_STANDARD_DVB_S2 3
>
> struct dvb_frontend_parameters_ex {
> int standard; /* this is new! */
>
> __u32 frequency;
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qpsk2_parameters qpsk2; // qpsk + -S2 specific stuff
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_vsb_parameters vsb;
> } u;
> };
>
>
> The other method, which i prefer, is:
>
> #define FE_SET_STANDARD _IOW('o', xx, int)
>
> #define FE_STANDARD_DVB_S 0
> #define FE_STANDARD_DVB_C 1
> #define FE_STANDARD_DVB_T 2
> #define FE_STANDARD_DVB_S2 3
>
> FE_CAN_DVBS = xxx,
> FE_CAN_DVBC = xxx,
> FE_CAN_DVBT = xxx,
> FE_CAN_ATSC = xxx,
> FE_CAN_DVBS2 = xxx,
>
> The current dvb_frontend_parameters could be extended for the new
> standard. Each standard would define to use exactly one
> "dvb_xxx_parameters" in that union.
How about enum fe_rolloff_flag from Marcel's posting?
If the size of struct dvb_frontend_parameters changes we
break binary compatibility. However, since struct dvb_ofdm_parameters
is quite a bit larger than the other ones, it might work to
just add struct dvb_qpsk2_parameters to the union in
struct dvb_frontend_parameters.
> This method would also catch the DVB-S/DVB-T-combi frontends which
> lately appeared here. One could set the STANDARD, and the frontend would
> change it's complete personality (probably including other FE_CAN_-caps,
> changing the frequency_min/max/..-limits etc.). A frontend could decide
> to stop supporting SEC commands when switched to DVB-T mode etc.
Hm. How do we handle dvb_frontend_info.type?
> A final question was how to support DVB-H. Is DVB-H totally backward
> compatible to DVB-T? (ignoring the 4k mode, of course, but that could be
> added backward-compatible to DVB-T) Do we want to support that power
> management features, if yes, how? A new dvb_dvbh_parameters, based on
> the _ofdm-one, with some added fields? I never did anything DVB-H
> related, so please excuse my ignorance.
I know next to nothing about DVB-H.
Johannes
