[linux-dvb] DVB API update

Marcel Siegert mws at linuxtv.org
Sun Sep 16 21:53:29 CEST 2007

On Sunday 16 September 2007, Rainer.scherg wrote:

hi rainer,

> Manu Abraham schrieb:
> > 
> >>   - 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.
> I did not made any deeper thoughts on how this could be implemented 
> best. What was the reason of this idea:
>    A university asked me some times ago, to enhance dvbsnoop to output
>    more detailled error reporting data than SIG, SNR, BER, UBLCK for
>    a specific frontend (DIBCOM3000).
> In this case it was related to the frontend. As you stated, a special
> object might be more useful and more flexible.
> > 
> > 
> >>   - 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.
> Following scenario (SAT):
>    Application 1 tunes device 2:
>       to freq  1234.567 MHz, V, HiBand, SAT "2", etc..
>    Application 2 tunes device 2:
>       to freq  1000.123 MHz, H, LoBand, SAT "1", etc..
>   Currently application 1 has no chance to query the current
>   frontend settings.

from my pov it would not be allowed to have application 2 tune to a different
transponder if application 1 still uses it.

and, where is the deep sense in this situation?
app 1 tunes to 1234....

app 2 tunes to 1000... and therefore destroys app 1`s data

app 1 checks periodically (via get current tuning param), 
if everything still is fine,
the result is this case is no, so app 1 would maybe 
try to retune to 1234-- and app2 would check and try to retune to 100....

i cant see sense in your example at all. 

where i can see the sense is, to query a frontend to get back the actual frontend settings, 
but your example has a totally different problem.

>   In a first step, a simple "query current frontend
>   settings" (last set data) for a device would be sufficient.
>   In a second step (future APIs), one could think about notification
>   by event handlers.

which notification? a userspace application should free a frontends usage, if is no longer
using it. am i wrong?
>   I also would ignore the LOCK state and always save/return the last
>   set parameters.
what do you mean with ignoring a LOCK state? also return frontend settings, if no LOCK
has been done on those? if that is your point, i am ok for that.


More information about the linux-dvb mailing list