From: hias@horus.com (Matthias Reichl)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 0/3] Improve latency of IR decoding
Date: Wed, 28 Mar 2018 20:30:29 +0200 [thread overview]
Message-ID: <20180328183028.bqqp55ser24lucf2@camel2.lan> (raw)
In-Reply-To: <cover.1521901953.git.sean@mess.org>
Hi Sean,
On Sat, Mar 24, 2018 at 02:50:42PM +0000, Sean Young wrote:
> The current IR decoding is much too slow. Many IR protocols rely on
> a trailing space for decoding (e.g. rc-6 needs to know when the bits
> end). The trailing space is generated by the IR timeout, and if this
> is longer than required, keys can be perceived as sticky and slugish.
>
> The other issue the keyup timer. IR has no concept of a keyup message,
> this is implied by the absence of IR. So, minimising the timeout for
> this further improves the handling.
>
> With these patches in place, using IR with the builtin decoders is much
> improved and feels very snappy.
thanks a lot for the patches!
I didn't have much time to test yet, but quick checks on
Amlogic/meson-ir (kernel 4.16-rc7 + media tree + your patches)
and Raspberry Pi (RPi foundation kernel 4.14 + my backport of
your patches) look really promising.
I found one issue, though, in ir-sharp-decoder.c max_space must
be set to SHARP_ECHO_SPACE - otherwise we get a timeout between
the normal and inverted message part and decoding fails.
One thing I'm wondering is if the keyup timer marging might
be too tight now. Basically we have just the fixed 10ms marging
from idle timeout. The repeat periods of the protocols are rather
accurate/strict, so (programmable) remotes not sticking to the
official timing might cause repeated keyup/down events if they
are repeating a tad to slow.
I'm not sure if this could be an issue, but maybe we should
add a safety margin to the repeat periods as well? For example
10 or 20 percent of the specced repeat periods. What do you think?
To get some more test coverage I've asked my colleague to
include my backport patch in the LibreELEC testbuilds for
x86 and RPi. We've got some 500 regular users of these so if
something's not working we should find out soon. I just hope I
didn't mess up the backport... Here's the link to my 4.14 patch:
https://github.com/HiassofT/LibreELEC.tv/blob/le9-ir-latency/packages/linux/patches/default/linux-999-improve-ir-timeout-handling.patch
so long & thanks,
Hias
>
> Sean Young (3):
> media: rc: set timeout to smallest value required by enabled protocols
> media: rc: add ioctl to get the current timeout
> media: rc: per-protocol repeat period and minimum keyup timer
>
> Documentation/media/uapi/rc/lirc-func.rst | 1 +
> .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
> drivers/media/cec/cec-core.c | 2 +-
> drivers/media/rc/ir-imon-decoder.c | 1 +
> drivers/media/rc/ir-jvc-decoder.c | 1 +
> drivers/media/rc/ir-mce_kbd-decoder.c | 1 +
> drivers/media/rc/ir-nec-decoder.c | 1 +
> drivers/media/rc/ir-rc5-decoder.c | 1 +
> drivers/media/rc/ir-rc6-decoder.c | 1 +
> drivers/media/rc/ir-sanyo-decoder.c | 1 +
> drivers/media/rc/ir-sharp-decoder.c | 1 +
> drivers/media/rc/ir-sony-decoder.c | 1 +
> drivers/media/rc/ir-xmp-decoder.c | 1 +
> drivers/media/rc/lirc_dev.c | 9 ++-
> drivers/media/rc/rc-core-priv.h | 1 +
> drivers/media/rc/rc-ir-raw.c | 31 +++++++++-
> drivers/media/rc/rc-main.c | 68 +++++++++++-----------
> include/uapi/linux/lirc.h | 6 ++
> 18 files changed, 101 insertions(+), 41 deletions(-)
>
> --
> 2.14.3
>
next prev parent reply other threads:[~2018-03-28 18:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-24 14:50 Sean Young
2018-03-24 14:50 ` [PATCH 1/3] media: rc: set timeout to smallest value required by enabled protocols Sean Young
2018-03-24 14:50 ` [PATCH 2/3] media: rc: add ioctl to get the current timeout Sean Young
2018-03-24 14:50 ` [PATCH 3/3] media: rc: per-protocol repeat period and minimum keyup timer Sean Young
2018-03-28 18:30 ` Matthias Reichl [this message]
2018-04-04 11:44 ` [PATCH 0/3] Improve latency of IR decoding Matthias Reichl
2018-04-04 18:42 ` Sean Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180328183028.bqqp55ser24lucf2@camel2.lan \
--to=hias@horus.com \
--cc=linus-amlogic@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®