Rainer.scherg wrote:
> 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.
What i was thinking was the adapter as a parent retrieving information
from all the child objects.
The parent as a whole representing the adapter having very little info
about itself, the rest being composed out of various entities which are
being assembled together to form a one single chunk of data.
This also fills in the gap when different vendors are used (in most
cases) to comprise a global entity such as a card alone. You can think
of the current card config struct as a starting point, but just that it
is made a bit more effective when components from different vendors are
pulled in together to make a device, which brings in additional
constraints, which is not explicitly expressed by any of the vendors.
For a reference device this criteria does not apply, as all the
components are specified and in most cases tested and benchmarked on
Lab equipment.
The card manufacturer being clueless on that aspect. (What they do: take
a reference device, just like how people cut and paste code, cut and
paste happens in the schematic editor, which is the entry point for a
deviation from the Reference designs. Of course some designs which are
derivatives of the reference design are better than the reference design
themselves)
For example we have limits for each device (component would be right
term), but with each possible configuration, the actual limits posed are
different, which require the information from all the components put
together (eg: demod + tuner limits are hard to express unless it is
represented by a configuration, which handles the same. Also, i think it
might better to be represented as a global representation of the adapter
rather than a frontend.)
ie. IOW, the adapter is a representation of the final component
assembly, to put things very short.
As an example, on some of the cards that i do have, i have a discrete
GaAsFET stage in front of the frontend, which does shape and provide
some amount of gain to the frontend. This is an alteration to the actual
specifications of the devices that we look at in our drivers, which also
needs to be accounted, if we are looking at more precise information.
>>
>>> - 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.
This would mean that the driver would blindly save the TBD
(Tone/Burst/Diseqc) info, irrespective of a LOCK status. But then this
would present a problem if there was no valid LOCK, ie: there is a
chance that this data wasn't actually from a previous "successful"
event, but only a previous request.
Any advantages that you see in retrieving the previous request state ?
With regards to the diseqc state, since it is a FIFO, to what depth
would you like to save the information ? Or do you prefer to save a diff
of the state, pre and post cases ? (In daisy chained cases, the commands
could be longer, afaict)
In either case, this would mean that the driver to preserve a snapshot
of the state of an attempt at any given point of time.
I guess you are looking at a snapshot, rather than a return of
successful state values.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
