Some quick thoughts:
- the new API should support the DVB API v3.x as an "API layer".
Otherwise it will take a long time, to get most dvb applications
running on the new API, which would make it hard to replace the
current API.
- A runtime version check of the API is needed. Currently the API
version is determined at compile time, which is useless, when
distributing binaries (one of the bad things on linux are
incompatible API changes over time).
A simple major.minor version number check will IMO do.
- a "user structure" for hardware specific data (e.g. retrieve
special data from a special frontend chip would be nice.
this should be optional (*NULL = not used or not implemented).
otherwise something like:
struct { char[xx] hw_info;
specific data...
} *;
- enum dvb_fe_modulation {
DVB_FE_QPSK = (1 << 0),
[...]
DVB_FE_QAM_256 = (1 << 5),
DVB_FE_QAM_AUTO = (1 << 6)
};
better would be something like this:
DVB_FE_QAM_AUTO = (1 << 15)
so, we have some space for future extensions...
- API 3 is missing a a function for retrieving current frontend
settings (e.g. on SAT LNB settings). It would be sufficient, when
simply the last parameters set are returned.
Currently on API3 a "second dvb application" can change the frontend,
whithout any chance for the "main dvb application" to detect this
easily.
Manu Abraham schrieb:
> Hi,
>
> Currently the DVB API is of version 3.2. We have had API changes and
> changes to no end to it. In fact there was much learning from the V3 API
> than any other version.
>
> We have an old V4 API that was supposed to be taking over the V3 API.
> But V4 is considered almost dead due to lack of modern hardware support
> such as SOC's for STB's.
>[...]
>
> I hope this doesn't mark the beginning of another flame war.
>
> Regards,
> Manu
>
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
