Re: V4L2 spec

[wk <handygewinnspiel@gmx.de>]

>
> I think so. The better would be to convert DVB api to docbook (as used 
> by all other kernel documents), and add a developers document for the 
> kernel API for both at the kernel documentation structure).
>
> However, this is a huge task that someone should volunteer for doing, 
> otherwise, it won't happen.
>
> Cheers,
> Mauro
>
Sorry Mauro,

but i disagree with you.

Its a bad idea to expect someone else, the magic volunteer, doing work 
with *deep impact* on the dvb driver API structure or documentation.
Working on this topic determines complete usability of the driver, so 
MAIN DEVELOPERS have to REVIEW and CONTRIBUTE.
If they think, that they cannot do such work in parallel, they should to 
stop work on drivers for some time.

Status from application side of view at the moment: *not usable* without 
re-inventing the wheel.

The very same with the structures in frontend.h, a lot of things are not 
understandable. I give you some examples (i could give more...):

-  TRANSMISSION_MODE_4K is missing, but still mentioned in 300468 
v.1.9.1  "6.2.13.4 Terrestrial delivery system descriptor"
-  the same for BANDWIDTH_5_MHZ, also 300468 v.1.9.1  "6.2.13.4 
Terrestrial delivery system descriptor"
-  POLARIZATION for QPSK frontends  is nowhere defined in frontend.h at 
all, forcing applications to do its own definitions,
     "6.2.13.2 Satellite delivery system descriptor" gives clear 
definitions - so why are they not defined in frontend.h?
-  ATSC frontends are mixed cable and terrestrian, whereas older DVB-C 
and DVB-T are *strictly* separated
-  struct dvb_qpsk_parameters is missing (at least!) to be usable again
    * fe_modulation_t
    * fe_pilot_t
    * fe_rolloff_t
    * fe_delivery_system_t
    * west_east_flag
    * scrambling_sequence_selector
    * multiple_input_stream_flag

- nearly the same for dvb_qam_parameters, dvb_ofdm_parameters, 
dvb_atsc_parameters..., at least delivery_system needs to be here

Working on documentation would fix *all* of this problems.

Regards,
Winfried