On 2/27/06, Marcel Siegertwrote:
> -struct dvb_qam_parameters {
> +struct dvb_dvbc_parameters {
> __u32 symbol_rate; /* symbol rate in Symbols per second */
> fe_code_rate_t fec_inner; /* forward error correction (see above) */
> fe_modulation_t modulation; /* modulation type (see above) */
...
> +struct dvb_dvbs2_parameters {
> + __u32 symbol_rate; /* symbol rate in Symbols per second */
> + fe_code_rate_t fec_inner; /* forward error correction (see above) */
> + fe_rolloff_factor_t rolloff_factor; /* rolloff factor needed for dvb-s2 */
> + fe_modulation_t modulation; /* modulation type (see above) */
> +};
Just a tiny nit. can we keep the order of variables the same where
possible between dvb types? It should never matter, but it just makes
more sense to me. So the struct would look like this instead:
> +struct dvb_dvbs2_parameters {
> + __u32 symbol_rate; /* symbol rate in Symbols per second */
> + fe_code_rate_t fec_inner; /* forward error correction (see above) */
> + fe_modulation_t modulation; /* modulation type (see above) */
> + fe_rolloff_factor_t rolloff_factor; /* rolloff factor needed for dvb-s2 */
> +};
Also, why did you define FE_CAN_DVB_S2? Isn't
'FE_HAS_EXTENDED_CAM_VALUES' good enough to be able to determine this?
And as for the comment that goes with the FE_SET_STANDARD define, do
you expect the frontend to change its caps based on how set-standard
is defined? In general, I can see how this would be needed in some
cases, but for dvb-s/s2 cards, it is likely unnecessary as one is a
superset of the other.
Otherwise it looks ok to me. I can update the genpix patch to work
with this API easily enough. Are you planning to implement
FE_GET_EXTENDED_INFO and FE_SET_STANDARD once this gets approved?
Thanks
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
