Hi,
Rainer.scherg wrote:
> 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.
>
We can have compatibility with the V3 API, that's what you meant ? I
guess so.
> - 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.
Right.
>
> - 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...
> } *;
>
Sounds good. In a tangent thought, in many cases when a special chip is
used sometimes there is an overall change in the hardware design.
In such a case, do you think, that if we abstract such an info, out as a
part of as a new object such as an adapter object, (such that more
information can be passed out clearly) would be a better approach,
rather than shoving everything we have into the frontend object ? (where
the adapter object becomes the parent object for all others)
Though i must say, that the frontend specific should be in the frontend,
but the adapter object could get the frontend specific information as a
part of it's own and present to the application. Though, you will be
able to query the frontend related information alone also, for carrying
around shorter chunks of data if the user wants to have only a small
subset of the information.
What do you think ?
> - 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...
True, this can avoid a dummy parameter, since we would like reserve this
space.
> - 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.
the dvb-core saving away the last successful LOCK state, will this help
? But in any case, the second application if it successfully lock's,
then this would change logically, since this becomes the
previous-previous successful locked state.
Is that what you meant, guess i didn't follow you correctly.
Thanks,
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
