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