Alan Nisota wrote:
My purpose here is simply to get the 8psk module in the board I have working. I'll be happy to work with anyone on doing so, but I'm a relative newbie to kernel programming, and don't really know my way around dvb-core yet, so I'm not sure my input into the API is particularly relevant.
every input may give inspiration and sense. participating on further development is needed, so just tell us your opinions on different topics.
That said, from an application point of view, being able to add support for dvb-s2 with the minimum amount of code change seems likely to be the fastest way to get support into the dvb apps out there. To me, Marcel's second patch seems to accomplish this (with a modification to support something like an FE_CAN_EXTENDED define, along with a second enum of capabilities). While using the v4 API method (each capability type gets an independant typedef) would certainly be more flexible, it seems to me, it would require more extensive changes in the apps to support.
yes, at first i thought the same way. but, each application that will use DVB-S2 and corresponding modulations ect. must be overworked. so it is not a real extensive change to existing apps. it is just IF dvb-s2 should be used, they have to implemented a bit more than just a new frontend tuning struct, everything existing wont be touched. if we want to have dvb-s2 support - imho we want - we must think about keeping existing apps compatible and cover all new things in a different layout of ioctl's or structs. the old - and still backwards compatible - capabilities enumeration is expenditure-provoked. so the one and only possibility to have options left for new capabilities that may occur in the near future is to have an extension to the old one. this one sould be styled in a e.g. api v4 way - reasons a) we have different structs/enums for different capabilities - this keeps more space for further upcoming values b) we can slightly migrate someday to api v4, when tuner drivers are available - in this case the apps do already contain lots of api v4 ioctl's so just the old ones (ok, and some constant names ect) must be changed. c) all designs in v4 will be reviewed for usability - and if needed can be implemented in a slight different way within v3, if the v4 design would lead us into new regressions. but these are also just my opinions. the hard way would be to force v4 development and keep v3 as a fallback for current hardware. comments? best regards marcel _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
