[linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1118 bytes --]


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                 struct dvb_frontend_tune_settings fetunesettings;
1740                 enum dvbfe_delsys delsys = fepriv->fe_info.delivery;
...
1783                 } else {
1784                         /* default values */
1785                         switch (fepriv->fe_info.delivery) {
...
1817                         default:
1818                                 up(&fepriv->sem);
1819                                 return -EINVAL;
1820                         }

Should the code use fepriv->feparam.delivery instead of
fepriv->fe_info.delivery to sense the right delivery system ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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         case DVBFE_SET_PARAMS: {
> 1739                 struct dvb_frontend_tune_settings fetunesettings;
> 1740                 enum dvbfe_delsys delsys = fepriv->fe_info.delivery;
> ...
> 1783                 } else {
> 1784                         /* default values */
> 1785                         switch (fepriv->fe_info.delivery) {
> ...
> 1817                         default:
> 1818                                 up(&fepriv->sem);
> 1819                                 return -EINVAL;
> 1820                         }
> 
> Should the code use fepriv->feparam.delivery instead of
> fepriv->fe_info.delivery to sense the right delivery system ?

Which demodulator driver are you using to test your application ?

Though a bug, but that won't make any difference to what you are looking at,
since the delay and others are used in the case of swzigzag, which 
doesn't exist
at least for the existing demods using the track() callback at all.

This would be a fix for any demod drivers using the set_params() callback.

Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 3792 bytes --]


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 the kernel code - In
> >the dvb_frontend.c i see this code:
> >
> >1738         case DVBFE_SET_PARAMS: {
> >1739                 struct dvb_frontend_tune_settings fetunesettings;
> >1740                 enum dvbfe_delsys delsys = fepriv->fe_info.delivery;
> >...
> >1783                 } else {
> >1784                         /* default values */
> >1785                         switch (fepriv->fe_info.delivery) {
> >...
> >1817                         default:
> >1818                                 up(&fepriv->sem);
> >1819                                 return -EINVAL;
> >1820                         }
> >
> >Should the code use fepriv->feparam.delivery instead of
> >fepriv->fe_info.delivery to sense the right delivery system ?
> 
> Which demodulator driver are you using to test your application ?

STB0899 on a SkyStar HD - Using DVB-S2 on Astra 
 
> Though a bug, but that won't make any difference to what you are looking at,
> since the delay and others are used in the case of swzigzag, which 
> doesn't exist
> at least for the existing demods using the track() callback at all.

The problem i see and some people off list already acknowledged is that
the DVBFE_GET_INFO actually _SETS_ informations in the kernel about the
delivery system which gets even cached across frontend opens. 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
dvbfeparam in the DVBFE_SET_PARAM ioctl gets ignored. When running scan 
once after loading the module the delivery system gets set and suddenly
my little app works, but only for the frontend/delivery type i pressed
ctrl-c on running scan, and until i reload the module.

I changed the kernel dvb_frontend.c to actually use the dvbfeparam
delivery system type but then the demod driver stb0899 pukes into my
kernel log that it finds an unknown delivery system because it makes the very
same assumption that it should use the delivery from GET_INFO and not
SET_PARAM ... 

stb0899_drv.c:
1406 static int stb0899_get_info(struct dvb_frontend *fe, struct dvbfe_info *fe_info)
1407 {
1408         struct stb0899_state *state = fe->demodulator_priv;
1409 
1410         dprintk(verbose, FE_DEBUG, 1, "Get Info");
1411 
1412         state->delsys = fe_info->delivery;
1413         switch (state->delsys) {

Line 1412 caches informations in the frontend demod without purpose - Get info is just
that and not some state altering ioctl ...

> This would be a fix for any demod drivers using the set_params() callback.

Yep - something should be fixed - currently its a little inconsistent:

- A GET or READ call should never ever alter state - otherwise it should be named
  different. Its the same with read/write, peek/poke, load/store set/get.
  Just because i ask about informations concerning the DVB-S frontend does
  not mean that i will not start DVB-S2 or DSS.
- If DVBFE_SET_PARAM passes a struct which contains a delivery system it
  should either be honored or not even be there. On a SET call with a struct
  every application writers assumption is that the values in the struct passed
  actually get honored.

And this MUST be coherent for all demods.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 same with read/write, peek/poke, load/store set/get.
>   Just because i ask about informations concerning the DVB-S frontend does
>   not mean that i will not start DVB-S2 or DSS.

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.

Do you see the same bug with szap too ? 
(http://abraham.manu.googlepages.com/szap.c)


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1431 bytes --]

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_ 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 with:

	stb0899_search: Unsupported delivery system 0
	stb0899_read_status: Unsupported delivery system 0
	stb0899_search: Unsupported delivery system 0
	stb0899_read_status: Unsupported delivery system 0
	stb0899_search: Unsupported delivery system 0
	stb0899_read_status: Unsupported delivery system 0

although i set

	dvbfe_params.delivery=DVBFE_DELSYS_DVBS2;

> Do you see the same bug with szap too ? 
> (http://abraham.manu.googlepages.com/szap.c)

Its not a bug in szap - its a bug in the API - There is a delivery in
the dvbfe_param and i set it correctly - and it gets ignored. Running
zap before running my program causes it to work because zap runs
an GET_INFO ioctl which _SETS_ a delivery mode.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 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 with:
> 
> 	stb0899_search: Unsupported delivery system 0
> 	stb0899_read_status: Unsupported delivery system 0
> 	stb0899_search: Unsupported delivery system 0
> 	stb0899_read_status: Unsupported delivery system 0
> 	stb0899_search: Unsupported delivery system 0
> 	stb0899_read_status: Unsupported delivery system 0
> 
> although i set
> 
> 	dvbfe_params.delivery=DVBFE_DELSYS_DVBS2;

Yep, it isn't supposed to work that way with simply issuing SET_PARAMS.


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1486 bytes --]

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 with:
> >
> >	stb0899_search: Unsupported delivery system 0
> >	stb0899_read_status: Unsupported delivery system 0
> >	stb0899_search: Unsupported delivery system 0
> >	stb0899_read_status: Unsupported delivery system 0
> >	stb0899_search: Unsupported delivery system 0
> >	stb0899_read_status: Unsupported delivery system 0
> >
> >although i set
> >
> >	dvbfe_params.delivery=DVBFE_DELSYS_DVBS2;
> 
> Yep, it isn't supposed to work that way with simply issuing SET_PARAMS.

Okay - So either 

- remove the "delivery" in the dvbfe_params because it is unnecessary,
  confusing and broken, and rename the GET_INFO call to SET_DELIVERY
  or something which implies that its not a _GET_ call

or 

- 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 not get more adopters ..

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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
>>> complains in the dmesg with:
>>>
>>> 	stb0899_search: Unsupported delivery system 0
>>> 	stb0899_read_status: Unsupported delivery system 0
>>> 	stb0899_search: Unsupported delivery system 0
>>> 	stb0899_read_status: Unsupported delivery system 0
>>> 	stb0899_search: Unsupported delivery system 0
>>> 	stb0899_read_status: Unsupported delivery system 0
>>>
>>> although i set
>>>
>>> 	dvbfe_params.delivery=DVBFE_DELSYS_DVBS2;
>> Yep, it isn't supposed to work that way with simply issuing SET_PARAMS.
> 
> Okay - So either 
> 
> - remove the "delivery" in the dvbfe_params because it is unnecessary,
>   confusing and broken, and rename the GET_INFO call to SET_DELIVERY
>   or something which implies that its not a _GET_ call

As you can see, removing delivery is not an option, since GET_PARAMS 
operates
on the same data structure. Removal of which will require the application to
issue an additional ioctl call.

> or 
> 
> - 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 not get more adopters ..

Your 2nd option won't work at all. It is completely broken when you have
to query statistics, before a SET_PARAMS.

Additionally, this was quite discussed in a long discussion a while 
back. You
might like to read through those as well.

Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really
itches so much.

HTH,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 2455 bytes --]

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 not get more adopters ..
> 
> Your 2nd option won't work at all. It is completely broken when you have
> to query statistics, before a SET_PARAMS.

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 option in the
dvbfe_params gets ignored on a DVBFE_SET_PARAMS ? I dont see the
rational behind this... The option is there - correctly filled and
gets ignored or better overriden by previous ioctls - Every other
parameter for the delivery mode is in that struct.

Please tell me why the GET_INFO delsys/delivery option gets set as the next
to use delivery mode. Even if i want to have stats just dont fill them
when the delsys does not match the currently set delsys as that would
be the right thing - Querying DVB-S2 stats when tuned to DVB-S should
return nothing as there are no stats - but setting the delsys to DVB-S
is BROKEN as i asked for stats not to change the delsys.
 
> Additionally, this was quite discussed in a long discussion a while 
> back. You might like to read through those as well.

I did partially of it ... and i found the same corners of this API to be
broken by design.

> Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really
> itches so much.

No - its much more fundamental problem ... Options belonging
together are passed in seperate ioctls in non obvious (read: strange)
ways into the kernel (delivery system via GET_INFO and delivery options
via SET_PARAMS). 

Options which are together in the same struct are not used together e.g.
delivery mode and parameters are in the same struct which get passed by
an ioctl but get partially ignored or better overridden by previous 
ioctls in non obvious ways...

As i said - incoherent mess from the user api ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 incoherent mess which should better not get more adopters ..
>> Your 2nd option won't work at all. It is completely broken when you have
>> to query statistics, before a SET_PARAMS.
> 
> I have no problem with beeing able to query stats - I have a problem

You are wrong again. Please look at the code, how statistics related
operations are retrieved.


Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 783 bytes --]

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 the demod (e.g. STB0899) its a simply memcpy of a predefined
capabily struct - So why on earth does it set/change the in kernel
delivery system ?!?!

You are still not answering the rational behind ignoring the delivery
system in dvbfe_params/DVBFE_SET_PARAMS.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1166 bytes --]

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 operation might not be the first thing to do in a GUI based
operation where the user gets presented with a little capability show
and clickable channel lists etc ...

But there are application which simple want to tune with a user
defined configuration and simply want to tune or to get an error
and let the user sort it out. I dont care about the capabilities
of a frontend or stats - i want to tune - And when i open the
frontend and issue an ioctl which passes a struct with ALL INFORMATIONS
NECESSARY TO TUNE i expect it to do exactly that - to tune and not
to bail out with an error because i didnt ask for capabilites via
GET_INFO ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 and naming
>>>> is an incoherent mess which should better not get more adopters ..
>>> Your 2nd option won't work at all. It is completely broken when you have
>>> to query statistics, before a SET_PARAMS.
>> I have no problem with beeing able to query stats - I have a problem
> 
> You are wrong again. Please look at the code, how statistics related
> operations are retrieved.

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.

Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 name would be GET_CAPABILITY.
> In the demod (e.g. STB0899) its a simply memcpy of a predefined
> capabily struct - So why on earth does it set/change the in kernel
> delivery system ?!?!
> 
> You are still not answering the rational behind ignoring the delivery
> system in dvbfe_params/DVBFE_SET_PARAMS.

I already mentioned this in my previous email. Please read the previous 
mails
and or the old discussions.

 From my previous email:

Your 2nd option won't work at all. It is completely broken when you have
to query statistics, before a SET_PARAMS.

Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

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. I ask you to
point out why the kernel code decides to ignore it on SET_PARAMS.

> Your 2nd option won't work at all. It is completely broken when you have
> to query statistics, before a SET_PARAMS.

What statistics can i possibly ask for when i didnt set any parameters?
Why not return EAGAIN if i ask for stats which are not there - that
would be a sane way to respond to it instead of garbling the tuner state
on a GET_INFO ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

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 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.

Before powering up the radio you cant know whether they play your song
on your favorit radio station.

> The whole point is: there are 2 or more paths, which need to be selected 
> for any operation.

You are referring to what?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 in many cases.
> 
> A tune operation might not be the first thing to do in a GUI based
> operation where the user gets presented with a little capability show
> and clickable channel lists etc ...


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.

The whole point is: there are 2 or more paths, which need to be selected 
for any
operation.

HTH,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]

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 for a signal level when using a rotor, for a 
> real life example ?

In case of a rotor i expect the diseq commands to go out - tune the
frontend for the right modulation and frequency and then monitor the
signal level while turning the dish.

This needs tuning - right ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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 do it or not.
> 
> 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 for a signal level when using a rotor, for a 
real life
example ?


Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1294 bytes --]

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/tuner i would not expect to see any signal.
> >>How do you expect to look for a signal level when using a rotor, for a 
> >>real life example ?
> >
> >In case of a rotor i expect the diseq commands to go out - tune the
> >frontend for the right modulation and frequency and then monitor the
> >signal level while turning the dish.
> >
> >This needs tuning - right ?
> 
> No, this is fed from the AGC1 path1 integrator and the AGC1 path2 
> integrator.

Okay - you say turning the dish does not need tuning - so i issue
the DISEQ ioctls and start reading the signal level - whats the point
and what is this an argument for?

- How can this excuse ignoring the delivery in the DVBFE_SET_PARAMS?
- How can this justify setting the delivery system in DVBFE_GET_INFO ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Manu Abraham]

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.
>> How do you expect to look for a signal level when using a rotor, for a 
>> real life example ?
> 
> In case of a rotor i expect the diseq commands to go out - tune the
> frontend for the right modulation and frequency and then monitor the
> signal level while turning the dish.
> 
> This needs tuning - right ?

No, this is fed from the AGC1 path1 integrator and the AGC1 path2 
integrator.

Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[Christoph Pfister]

Am Montag 03 März 2008 schrieb Florian Lohoff:
<snip>
> 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 option in the
> dvbfe_params gets ignored on a DVBFE_SET_PARAMS ? I dont see the
> rational behind this... The option is there - correctly filled and
> gets ignored or better overriden by previous ioctls - Every other
> parameter for the delivery mode is in that struct.
>
> Please tell me why the GET_INFO delsys/delivery option gets set as the next
> to use delivery mode. Even if i want to have stats just dont fill them
> when the delsys does not match the currently set delsys as that would
> be the right thing - Querying DVB-S2 stats when tuned to DVB-S should
> return nothing as there are no stats - but setting the delsys to DVB-S
> is BROKEN as i asked for stats not to change the delsys.
>
> > Additionally, this was quite discussed in a long discussion a while
> > back. You might like to read through those as well.
>
> I did partially of it ... and i found the same corners of this API to be
> broken by design.
>
> > Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really
> > itches so much.
>
> No - its much more fundamental problem ... Options belonging
> together are passed in seperate ioctls in non obvious (read: strange)
> ways into the kernel (delivery system via GET_INFO and delivery options
> via SET_PARAMS).
>
> Options which are together in the same struct are not used together e.g.
> delivery mode and parameters are in the same struct which get passed by
> an ioctl but get partially ignored or better overridden by previous
> ioctls in non obvious ways...
>
> As i said - incoherent mess from the user api ...

+1

> Flo

Christoph

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

[hermann pitton]

Am Montag, den 03.03.2008, 22:13 +0100 schrieb Christoph Pfister:
> Am Montag 03 März 2008 schrieb Florian Lohoff:
> <snip>
> > 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 option in the
> > dvbfe_params gets ignored on a DVBFE_SET_PARAMS ? I dont see the
> > rational behind this... The option is there - correctly filled and
> > gets ignored or better overriden by previous ioctls - Every other
> > parameter for the delivery mode is in that struct.
> >
> > Please tell me why the GET_INFO delsys/delivery option gets set as the next
> > to use delivery mode. Even if i want to have stats just dont fill them
> > when the delsys does not match the currently set delsys as that would
> > be the right thing - Querying DVB-S2 stats when tuned to DVB-S should
> > return nothing as there are no stats - but setting the delsys to DVB-S
> > is BROKEN as i asked for stats not to change the delsys.
> >
> > > Additionally, this was quite discussed in a long discussion a while
> > > back. You might like to read through those as well.
> >
> > I did partially of it ... and i found the same corners of this API to be
> > broken by design.
> >
> > > Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really
> > > itches so much.
> >
> > No - its much more fundamental problem ... Options belonging
> > together are passed in seperate ioctls in non obvious (read: strange)
> > ways into the kernel (delivery system via GET_INFO and delivery options
> > via SET_PARAMS).
> >
> > Options which are together in the same struct are not used together e.g.
> > delivery mode and parameters are in the same struct which get passed by
> > an ioctl but get partially ignored or better overridden by previous
> > ioctls in non obvious ways...
> >
> > As i said - incoherent mess from the user api ...
> 
> +1
> 
> > Flo
> 
> Christoph
> 

I can't let it, something totally OT ...

The "AIRBUS" claimed nearly crashed in Hamburg recently,
during EMMA, was in totally normal flight operation.

At least the pilots don't have any guilt.

The reason for it was, some might think it is not normal, that the
expense per lost passenger is restricted to some 14000 old german marks,
IIRC:)

Cheers,
Hermann





_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb