Marcel Siegert schrieb:
>>> 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
>
>
maybe the example was unlucky, but it should show the current problem.
It's just about querying some simple data.
There is no discussion about any application or its behavior.
So let's simplify the example:
take a shell/perl script with 2 forked, async. processes:
process 1 is just tuning (a) satellite(s) in steps (dvbtune).
process 2 is frequently querying the tuned data
and e.g. plots a diagram.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
