Am Montag, den 03.03.2008, 22:13 +0100 schrieb Christoph Pfister:
> Am Montag 03 März 2008 schrieb Florian Lohoff:
>
> > I have no problem with beeing able to query stats - I have a problem
> > that a GET call changes in kernel state, and the SET calls options get
> > ignored where it should be th
Am Montag 03 März 2008 schrieb Florian Lohoff:
> I have no problem with beeing able to query stats - I have a problem
> that a GET call changes in kernel state, and the SET calls options get
> ignored where it should be the other way round.
>
> Probably you can tell me the reason the delivery opti
On Mon, Mar 03, 2008 at 06:24:50PM +0400, Manu Abraham wrote:
> >On Mon, Mar 03, 2008 at 06:17:58PM +0400, Manu Abraham wrote:
> >>>You mean tune and then check if there is a SIGNAL and possibly a LOCK? I
> >>>do that yes ... But first comes the tune - On an uninitialized state of
> >>>a demod/tune
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 06:17:58PM +0400, Manu Abraham wrote:
>>> You mean tune and then check if there is a SIGNAL and possibly a LOCK? I
>>> do that yes ... But first comes the tune - On an uninitialized state of
>>> a demod/tuner i would not expect to see any signal.
>> H
On Mon, Mar 03, 2008 at 06:17:58PM +0400, Manu Abraham wrote:
> >You mean tune and then check if there is a SIGNAL and possibly a LOCK? I
> >do that yes ... But first comes the tune - On an uninitialized state of
> >a demod/tuner i would not expect to see any signal.
>
> How do you expect to look
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 06:04:12PM +0400, Manu Abraham wrote:
>> The more important part is to first check for a signal, before
>> attempting a tune.
>> Lack of doing so, will result in a lot of frustration in many cases.
>> Though it is completely upto oneself whether to
On Mon, Mar 03, 2008 at 06:04:12PM +0400, Manu Abraham wrote:
> The more important part is to first check for a signal, before
> attempting a tune.
> Lack of doing so, will result in a lot of frustration in many cases.
> Though it is completely upto oneself whether to do it or not.
You mean tune
On Mon, Mar 03, 2008 at 05:55:48PM +0400, Manu Abraham wrote:
> I already mentioned this in my previous email. Please read the previous
> mails and or the old discussions.
Would you point the mail to me where you did - I cant find any - You
said that for GET_PARAMS you need the space to store it.
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 05:49:53PM +0400, Manu Abraham wrote:
>> Basically you seem to get the wrong end, (it's one whole line, no corners
>> to it) since you think that it all starts with a tune operation. No, a tune
>> operation is not the first operation that's to be done
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 05:41:17PM +0400, Manu Abraham wrote:
>> You are wrong again. Please look at the code, how statistics related
>> operations are retrieved.
>
> When i issue a DVBFE_GET_INFO i dont get stats i get informations
> about the delivery system - a better na
On Mon, Mar 03, 2008 at 05:49:53PM +0400, Manu Abraham wrote:
> Basically you seem to get the wrong end, (it's one whole line, no corners
> to it) since you think that it all starts with a tune operation. No, a tune
> operation is not the first operation that's to be done in many cases.
A tune ope
On Mon, Mar 03, 2008 at 05:41:17PM +0400, Manu Abraham wrote:
> You are wrong again. Please look at the code, how statistics related
> operations are retrieved.
When i issue a DVBFE_GET_INFO i dont get stats i get informations
about the delivery system - a better name would be GET_CAPABILITY.
In t
Manu Abraham wrote:
> Florian Lohoff wrote:
>> On Mon, Mar 03, 2008 at 04:03:09PM +0400, Manu Abraham wrote:
- make SET_PARAMS the call to honor delivery in dvbfe_params and remove
the setting of the delivery of GET_INFO
I'd prefere the 2nd option because currently the usage an
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 04:03:09PM +0400, Manu Abraham wrote:
>>> - make SET_PARAMS the call to honor delivery in dvbfe_params and remove
>>> the setting of the delivery of GET_INFO
>>>
>>> I'd prefere the 2nd option because currently the usage and naming
>>> is an incohere
On Mon, Mar 03, 2008 at 04:03:09PM +0400, Manu Abraham wrote:
> >- make SET_PARAMS the call to honor delivery in dvbfe_params and remove
> > the setting of the delivery of GET_INFO
> >
> >I'd prefere the 2nd option because currently the usage and naming
> >is an incoherent mess which should better
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 03:09:23PM +0400, Manu Abraham wrote:
>>> As i already wrote - SET_PARAMS is _NOT_ enough. Please try yourself.
>>> Unload/Load the module and simple issue a DVBFE_SET_PARAMS (NOT
>>> GET_INFO) and it doesnt tune/lock at least for STB0899 and it also
On Mon, Mar 03, 2008 at 03:09:23PM +0400, Manu Abraham wrote:
> >As i already wrote - SET_PARAMS is _NOT_ enough. Please try yourself.
> >Unload/Load the module and simple issue a DVBFE_SET_PARAMS (NOT
> >GET_INFO) and it doesnt tune/lock at least for STB0899 and it also
> >complains in the dmesg
Florian Lohoff wrote:
> On Mon, Mar 03, 2008 at 04:22:00AM +0400, Manu Abraham wrote:
>> This won't work. params will contain data only after you have
>> successfully issued
>> SET_PARAMS not before. For SET_PARAMS to work, you need the delivery system
>> cached for the operation.
>
> As i alread
On Mon, Mar 03, 2008 at 04:22:00AM +0400, Manu Abraham wrote:
> This won't work. params will contain data only after you have
> successfully issued
> SET_PARAMS not before. For SET_PARAMS to work, you need the delivery system
> cached for the operation.
As i already wrote - SET_PARAMS is _NOT_ en
Florian Lohoff wrote:
> Hi,
>
> This is
> why my application, which did not issue a GET_INFO but rather set the
> delivery system in the dvbfeparam, failed. The delivery in the
..
>
> - A GET or READ call should never ever alter state - otherwise it should be
> named
> different. Its the sa
Hi,
On Mon, Mar 03, 2008 at 02:43:33AM +0400, Manu Abraham wrote:
> Florian Lohoff wrote:
> >Hi,
> >i was wondering why i have a problem in my application that i need to
> >run scan once after loading the module, otherwise my DVBFE_SET_PARAMS
> >fails - I couldnt explain it until i looked into th
Florian Lohoff wrote:
> Hi,
> i was wondering why i have a problem in my application that i need to
> run scan once after loading the module, otherwise my DVBFE_SET_PARAMS
> fails - I couldnt explain it until i looked into the kernel code - In
> the dvb_frontend.c i see this code:
>
> 1738
Hi,
i was wondering why i have a problem in my application that i need to
run scan once after loading the module, otherwise my DVBFE_SET_PARAMS
fails - I couldnt explain it until i looked into the kernel code - In
the dvb_frontend.c i see this code:
1738 case DVBFE_SET_PARAMS: {
1739
23 matches
Mail list logo
