linux-amlogic.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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
> > 

  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).