Some questions timeout in rc_dev

Some questions timeout in rc_dev

[Rune Petersen]

Hi,


The intent of the timeout member in the rc_dev struct is a little unclear to me.
In rc-core.h it is described as:
	@timeout: optional time after which device stops sending data.

But if I look at the usage, it is used to detect idle in ir_raw.c which again is 
used by the RC-6 decoder to detect end of RC-6 6A transmissions.

This leaves me with a few questions:
  - Without the timeout (which is optional) the RC-6 decoder will not work
    properly with RC-6 6A transmissions wouldn't that make it required?

  - Why are the timeout set in the individual drivers so varied, shouldn't it
    depend on the encoding rather then the hardware used?
    The timeout set in the drivers ranges from 2750us(redrat3)
    to 1000000us(fintek_cir) and all the way to weird(streamzap)

  - Why is the timeout value controlled by the IR driver, when it us only
    used	by the rc-core.
    Wouldn't it make sense to have the timeout initialized to a sane value
    in a single place?


I would like to get rc to a state where it just works for me without 
modifications, I "just" need to know which changes I can get away without 
breaking it for everybody else =)

As things are right now the RC input feel very sluggish and unresponsive using a 
RC-6 6A remote and a ite-cir receiver.


Rune

Re: Some questions timeout in rc_dev

[Sean Young]

On Sun, Feb 16, 2014 at 10:54:01PM +0100, Rune Petersen wrote:
> The intent of the timeout member in the rc_dev struct is a little unclear to me.
> In rc-core.h it is described as:
> 	@timeout: optional time after which device stops sending data.
> 
> But if I look at the usage, it is used to detect idle in ir_raw.c
> which again is used by the RC-6 decoder to detect end of RC-6 6A
> transmissions.
> 
> This leaves me with a few questions:
>  - Without the timeout (which is optional) the RC-6 decoder will not work
>    properly with RC-6 6A transmissions wouldn't that make it required?

That sounds like a bug to me. The decoders shouldn't rely on the length 
of trailing space, probably it would be best to not rely on receiving the
trailing space if possible.

>  - Why are the timeout set in the individual drivers so varied, shouldn't it
>    depend on the encoding rather then the hardware used?
>    The timeout set in the drivers ranges from 2750us(redrat3)
>    to 1000000us(fintek_cir) and all the way to weird(streamzap)

The various devices have different timeouts; they will stop sending IR data
when there has been no activity for that amount of time.

>  - Why is the timeout value controlled by the IR driver, when it us only
>    used	by the rc-core.
>    Wouldn't it make sense to have the timeout initialized to a sane value
>    in a single place?

I guess the rc_dev->timeout is used for different things:

1) So that the drivers can advertise what timeout the hardware uses
2) The ttusbir and iguanair are devices which never timeout, so they
   rely on ir_raw_store_with_filter() to do timeout handling for them.

Some drivers have both hardware timeouts and use ir_raw_store_with_filter()
so timeout handling is done both in hardware and software.

> I would like to get rc to a state where it just works for me without
> modifications, I "just" need to know which changes I can get away
> without breaking it for everybody else =)
> 
> As things are right now the RC input feel very sluggish and
> unresponsive using a RC-6 6A remote and a ite-cir receiver.


Sean

Re: Some questions timeout in rc_dev

[Rune Petersen]

On 18/02/14 15:02, Sean Young wrote:
> On Sun, Feb 16, 2014 at 10:54:01PM +0100, Rune Petersen wrote:
>> The intent of the timeout member in the rc_dev struct is a little unclear to me.
>> In rc-core.h it is described as:
>> 	@timeout: optional time after which device stops sending data.
>>
>> But if I look at the usage, it is used to detect idle in ir_raw.c
>> which again is used by the RC-6 decoder to detect end of RC-6 6A
>> transmissions.
>>
>> This leaves me with a few questions:
>>   - Without the timeout (which is optional) the RC-6 decoder will not work
>>     properly with RC-6 6A transmissions wouldn't that make it required?
>
> That sounds like a bug to me. The decoders shouldn't rely on the length
> of trailing space, probably it would be best to not rely on receiving the
> trailing space if possible.

I can find no specs on RC-6 6A, but the length is supposed to be variable 8-128 
bits and there doesn't appear to be any bits for length in the transmission.
So the only way to detect the end is a space of 2667+us.

>
>>   - Why are the timeout set in the individual drivers so varied, shouldn't it
>>     depend on the encoding rather then the hardware used?
>>     The timeout set in the drivers ranges from 2750us(redrat3)
>>     to 1000000us(fintek_cir) and all the way to weird(streamzap)
>
> The various devices have different timeouts; they will stop sending IR data
> when there has been no activity for that amount of time.

Thought experiment:
Suppose the ir_raw_store_with_filter() code has a timeout _longer_ than this 
device timeout, it will never enter the idle state.
Suppose the ir_raw_store_with_filter() code has a timeout _shorter_ than this 
device timeout, it will enter the idle state, just faster.

Wouldn't this mean that the device timeout cannot be exceeded which I thought 
was the purpose of max_timeout in dev_rc?
>
>>   - Why is the timeout value controlled by the IR driver, when it us only
>>     used	by the rc-core.
>>     Wouldn't it make sense to have the timeout initialized to a sane value
>>     in a single place?
>
> I guess the rc_dev->timeout is used for different things:
>
> 1) So that the drivers can advertise what timeout the hardware uses
> 2) The ttusbir and iguanair are devices which never timeout, so they
>     rely on ir_raw_store_with_filter() to do timeout handling for them.
>
> Some drivers have both hardware timeouts and use ir_raw_store_with_filter()
> so timeout handling is done both in hardware and software.
>
>> I would like to get rc to a state where it just works for me without
>> modifications, I "just" need to know which changes I can get away
>> without breaking it for everybody else =)
>>
>> As things are right now the RC input feel very sluggish and
>> unresponsive using a RC-6 6A remote and a ite-cir receiver.
>
>
> Sean
>

Rune

Re: Some questions timeout in rc_dev

[Mauro Carvalho Chehab]

Em Tue, 18 Feb 2014 14:02:37 +0000
Sean Young <sean@mess.org> escreveu:

> On Sun, Feb 16, 2014 at 10:54:01PM +0100, Rune Petersen wrote:
> > The intent of the timeout member in the rc_dev struct is a little unclear to me.
> > In rc-core.h it is described as:
> > 	@timeout: optional time after which device stops sending data.
> > 
> > But if I look at the usage, it is used to detect idle in ir_raw.c
> > which again is used by the RC-6 decoder to detect end of RC-6 6A
> > transmissions.
> > 
> > This leaves me with a few questions:
> >  - Without the timeout (which is optional) the RC-6 decoder will not work
> >    properly with RC-6 6A transmissions wouldn't that make it required?
> 
> That sounds like a bug to me. The decoders shouldn't rely on the length 
> of trailing space, probably it would be best to not rely on receiving the
> trailing space if possible.

The trailing space is needed, because of some weird variants. For example,
there are some RC5-like protocols that have less bits. See for example the
15-bits variant at drivers/media/rc/ir-rc5-sz-decoder.

So, as a general rule, we're always waiting for a trailing space, to be sure
that the protocol matches. 
-- 

Cheers,
Mauro