[PATCH] media: rc: meson-ir: add timeout on idle
sean at mess.org
Mon Mar 12 06:58:11 PDT 2018
On Mon, Mar 12, 2018 at 02:20:00PM +0100, Matthias Reichl wrote:
> On Sun, Mar 11, 2018 at 12:55:19PM +0000, Sean Young wrote:
> > That makes complete sense. I'm actually keen to get this lowered, since
> > this makes it possible to lower the repeat period per-protocol, see
> > commit d57ea877af38 which had to be reverted (the ite driver will
> > need fixing up as well before this can happen).
> I remember the commit, this issue hit us in LibreELEC testbuilds
> as well :-)
> > Lowering to below 125ms does increase the risk of regressions, so I
> > am weary of that. Do you think there is benefit in doing this?
> I'd also say stick to the 125ms default. The default settings
> should always be safe ones IMO.
Well, yes. I just wanted to explore the ideal situation before making
up our minds.
> People who want to optimize for the last bit of performance can
> easily do that on their own, at their own risk.
> Personally I've been using gpio-ir-recv on RPi with the default 125ms
> timeout and a Hauppauge rc-5 remote for about 2 years now and I've
> always been happy with that.
Ok. We should try to get this change for meson-ir ready for v4.17. I can
write a patch later.
> I have to acknowledge though that the responsiveness of a remote
> with short messages, like rc-5, in combination with a low timeout
> (I tested down to 10ms) is pretty impressive.
I've been thinking about this problem. What we could do is have a
per-protocol maximum space length, and repeat period. The timeout
can then be set to a maximum space length (+safety margin), and the
keyup timer can be set to timeout + repeat period (+safety margin).
If memory serves, the lirc daemon always sets the timeout with
LIRC_SET_REC_TIMEOUT, so it would not affect lirc daemon decoding.
Anyway, just an idea. Not something for v4.17.
More information about the linux-amlogic