Re: [PATCH] Multi protocol support (stage #1)

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

 



Apart from the S2 stuff (haven't looked at it in this
version of the patch), there are still a couple of
things which I don't like. Most of them I pointed
out earlier already, but to summaryize and give
some additional explanation:

- too much unnecessary capabilites stuff; I receive a private
  mail from Trent and answered:

  > See, the DVB Wiki lists a number of applications. You can check them
  > all, not one of then looks at fe_caps_t. Why should they?
  > If fe_type_t says it's e.g. a DVB-T frontend, that's all the
  > application needs to know.
  > 
  > I realise it's different for ATSC, so we have to come up with
  > a way to handle it. However, adding a ton of totally
  > superflous DVB capability cruft to the API is IMHO wrong.
  > (This is just my personal opinion, of course, if a number
  > of people vote for it I will simply be overruled.)
  > 
  > ATSC is different than DVB, so needs different handling.

  (Well, the DVB-S2 standard contains optional parts, so it
  seems useful to be able to query this, but for the mandatory
  parts and the other DVB standard it just is NOT useful.)

- _IGNORE values: IIRC you said the purpose is to avoid unnecessary
  I2C bus traffic for FE_GET_PARAMS; however I think the amount
  of I2C bus traffic is insignificantly low, if you disagree
  then please back it up with numbers (how many bytes
  transferred/registers read for FE_GET_PARAMS?)

- you patch contains changes which are independent of
  the API change (enum tuner_param, struct tuner_state etc.):
  please move them to a seperate patch

- struct dvbs_params etc. still have superflous pad


Johannes

_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux