Re: DVB API update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux