From: hias@horus.com (Matthias Reichl)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 0/3] Improve latency of IR decoding
Date: Wed, 4 Apr 2018 13:44:01 +0200 [thread overview]
Message-ID: <20180404114401.llnimwz2wqwxpkhw@camel2.lan> (raw)
In-Reply-To: <20180328183028.bqqp55ser24lucf2@camel2.lan>
Hi Sean,
On Wed, Mar 28, 2018 at 08:30:29PM +0200, Matthias Reichl wrote:
> 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.
Quick update: testing so far went really smooth, no issues reported
since we included the backport patch in LibreELEC testbuilds.
Quote from https://github.com/LibreELEC/LibreELEC.tv/pull/2623#issuecomment-377897518
> This is in my nightly test builds since 28 March, and no problems reported so far.
>
> On my NUC with Harmony One/RC6 remote these commits are working just fine.
I've been using LibreELEC on RPi with the patch (using a gpio ir
receiver and a Hauppauge RC-5 remote) since then and everything
was fine as well.
so long,
Hias
> 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-04-04 11:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-24 14:50 [PATCH 0/3] Improve latency of IR decoding 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 ` [PATCH 0/3] Improve latency of IR decoding Matthias Reichl
2018-04-04 11:44 ` Matthias Reichl [this message]
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=20180404114401.llnimwz2wqwxpkhw@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;
as well as URLs for NNTP newsgroup(s).