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.
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.
I also would ignore the LOCK state and always save/return the last
set parameters.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
