On Thursday 02 March 2006 13:54, Johannes Stezenbach wrote:
> On Thu, Mar 02, 2006, Marcel Siegert wrote:
> > On Thursday 02 March 2006 00:53, Johannes Stezenbach wrote:
> > > On Wed, Mar 01, 2006, Marcel Siegert wrote:
> > > > On Wednesday 01 March 2006 20:08, Johannes Stezenbach wrote:
> > > > > On Mon, Feb 27, 2006, Marcel Siegert wrote:
> > >
> > > typedef enum fe_type {
> > > FE_QPSK, // legacy, do not use in new applications
> > > FE_QAM, // legacy, do not use in new applications
> > > FE_OFDM, // legacy, do not use in new applications
> > > FE_ATSC = 3,
> > > FE_DVB_S = (1 << 2),
> > > FE_DVB_C = (1 << 3),
> > > FE_DVB_T = (1 << 4),
> > > FE_DVB_S2 = (1 << 6)
> > > } fe_type_t;
> > >
> > > A bit ugly, but would work for both old apps and reporting supported
> > > standards for new apps.
> > agreed. fixed within my tree, one trap is left :/
> > if new frontend driver just return e.g. FE_DVB_T automatically old applications would assume that
> > it is an FE_QPSK (which has enum value 0) frontend and fail.
> > i think i will overwork the return values within the frontend drivers to prevent this.
> > patch would be supplied afterwards.
>
> I think FE_GET_INFO should only return the old values 0...3.
> We can add a WARN_ON() in dvb_frontend.c to check that
> drivers conform.
and how will we report to an application that we have an e.g. FE_DVB_T (that would be single reported as FE_OFDM) frontend
combined with FE_DVB_C ( that would be single reported as FE_QAM )?
i mean if we do a return FE_OFDM | FE_QAM we will get a numeric return value of 3 that would equal an FE_ATSC in this case.
or, should combo frontends be reported in a different kind? got any solutions already in mind?
>
> > so, what are your thoughts on this?
> > take the v3 e.g. fe_modulation and let them be enum constants?
> > e.g.
> > typedef enum fe_code_rate {
> > FEC_NONE = 0,
> > FEC_1_2 = 1,
> > FEC_2_3 = 2,
> > FEC_3_4 = 3,
> > FEC_4_5 = 4,
> > FEC_5_6 = 5,
> > FEC_6_7 = 6,
> > FEC_7_8 = 7,
> > FEC_8_9 = 8,
> > FEC_AUTO = 9
> > } fe_code_rate_t;
> >
> > of course i would extend them also to contain the new given modulations fec rates ect.
>
> (A bit confused, I don't get it.)
>
> Maybe we could keep using the existing definitions of
> fe_modulation_t etc., and just add new values,
> and return a bitset of (1 << VSB_8) etc. in the capabilites.
my thought was that if we perform like it pasted in the example, we would keep old values the same,
and we will define enum constants then. thus our conversation from last night (enum underlying inttype)
would also be of no affective kind. i wouldn't set these via bitshifting, cause i don't think that there will be
code rates binary combined and thus we just would get a regression in amount of usable values.
> This would decrease the number of changed lines in frontend.h
> dramatically (although, for fe_modulation_t we might want to
> add the MOD_ prefix because of 8PSK etc. and provide backwards
> comapt #defines).
hmm, yes possible to do so. modulation types would better reflect standards as their names.
acked, i'll prepare this
>
> Johannes
>
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
