Some questions timeout in rc_dev
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
Quoted 11 lines · Rune Petersen
The intent of the timeout member in the
rc_devstruct is a little unclear to me. Inrc-core.hit 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.cwhich 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.
Quoted 4 lines
- 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.
Quoted 4 lines
- 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.
Quoted 6 lines
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
Quoted 9 lines · Sean Young
Quoted 8 lines · Rune Petersen
The intent of the timeout member in the
rc_devstruct is a little unclear to me. Inrc-core.hit 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.cwhich again is used by the RC-6 decoder to detect end of RC-6 6A transmissions.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
- 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?
Quoted 19 lines
Quoted 5 lines
- 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->timeoutis 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 onir_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.Quoted 4 lines
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 =)
Quoted 6 lines
Quoted 2 lines
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
Em Tue, 18 Feb 2014 14:02:37 +0000
Sean Young <[email protected]> escreveu:
Quoted 9 lines · Rune Petersen
Quoted 8 lines
The intent of the timeout member in the
rc_devstruct is a little unclear to me. Inrc-core.hit 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.cwhich again is used by the RC-6 decoder to detect end of RC-6 6A transmissions.
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
Cheers, Mauro