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.
regards
marcel
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
