[PATCH] media: rc: ir-rc6-decoder: enable toggle bit for Kathrein RCU-676 remote

The Kathrein RCU-676 remote uses the 32-bit rc6 protocol and toggles bit 15 (0x8000) on repeated button presses, like MCE remotes. Add it's customer code 0x8046 to the 32-bit rc6 toggle handling code to get proper scancodes and toggle reports. Signed-off-by: Matthias Reichl --- Here's

Re: [PATCH v3 0/5] Add BPF decoders to ir-keytable

Hi Sean, On Sat, Jul 28, 2018 at 10:29:31AM +0100, Sean Young wrote: > Hi Hias, > > On Sat, Jul 21, 2018 at 08:13:27PM +0200, Matthias Reichl wrote: > > Hi Sean, > > > > thanks a lot, this is a really nice new feature! > > Thank you for testing it and findin

Re: [PATCH] media: rc: read out of bounds if bpf reports high protocol number

Hi Sean, On Sat, Jul 28, 2018 at 10:11:15AM +0100, Sean Young wrote: > The repeat period is read from a static array. If a keydown event is > reported from bpf with a high protocol number, we read out of bounds. This > is unlikely to end up with a reasonable repeat period at the best of times, >

Re: Logspam with "two consecutive events of type space" on gpio-ir-recv and meson-ir

Hi Sean, On Wed, Jul 25, 2018 at 09:21:00PM +0100, Sean Young wrote: > Hi Hias, > > On Sat, Jul 21, 2018 at 09:04:21PM +0200, Matthias Reichl wrote: > > Hi Sean, > > > > I noticed that on 4.18-rc5 I get dmesg logspam with > > "rc rc0: two consecutive

Logspam with "two consecutive events of type space" on gpio-ir-recv and meson-ir

Hi Sean, I noticed that on 4.18-rc5 I get dmesg logspam with "rc rc0: two consecutive events of type space" on gpio-ir-recv and meson-ir - mceusb seems to be fine (haven't tested with other IR receivers yet). With the default, short IR timeout I get these messages on each IR message, which is

Re: [PATCH v3 0/5] Add BPF decoders to ir-keytable

Hi Sean, thanks a lot, this is a really nice new feature! On Fri, Jul 13, 2018 at 03:30:06PM +0100, Sean Young wrote: > Once kernel v4.18 is released with IR BPF decoding, this can be merged > to v4l-utils. > > The idea is that IR decoders can be written in C, compiled to BPF relocatable >

Re: [RFC PATCH v1 0/4] Add BPF decoders to ir-keytable

Hi Sean, On Sat, Jun 02, 2018 at 01:37:54PM +0100, Sean Young wrote: > This is not ready for merging yet, however while I finish this work I would > like some feedback and ideas. > > The idea is that IR decoders can be written in C, compiled to BPF relocatable > object file. Any global variables

Re: [PATCH v4 0/3] IR decoding using BPF

Hi Sean, On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote: > The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most > widely used IR protocols, but there are many protocols which are not > supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, >

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean, On Thu, May 10, 2018 at 01:01:34PM +0200, Matthias Reichl wrote: > On Wed, May 09, 2018 at 10:44:42PM +0100, Sean Young wrote: > > On Mon, May 07, 2018 at 05:54:55PM +0200, Matthias Reichl wrote: > > > The original reporter gave up before I could get enough info &

Re: [PATCH 1/3] media: mceusb: filter out bogus timing irdata of duration 0

reELEC testbuilds, so far we got not complaints. so long, Hias > > Suggested-by: Matthias Reichl <h...@horus.com> > Signed-off-by: Sean Young <s...@mess.org> > --- > drivers/media/rc/mceusb.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/dr

[PATCH] media: rc: ite-cir: lower timeout and extend allowed timeout range

in line with the settings of many other receivers. Signed-off-by: Matthias Reichl <h...@horus.com> --- drivers/media/rc/ite-cir.c | 8 +--- drivers/media/rc/ite-cir.h | 7 --- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean! On Wed, May 09, 2018 at 10:44:42PM +0100, Sean Young wrote: > Hi Hias, > > On Mon, May 07, 2018 at 05:54:55PM +0200, Matthias Reichl wrote: > > Hi Sean! > > > > [ I trimmed the Cc list, as this is mceusb specific ] > > > > On Sat, Apr 21, 20

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean! [ I trimmed the Cc list, as this is mceusb specific ] On Sat, Apr 21, 2018 at 07:41:21PM +0200, Matthias Reichl wrote: > On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote: > > Another bug report came in, button press results in multiple > > key down/up e

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote: > Hi Sean, > > On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote: > > One of the affected users reported back that the fix worked fine! > > > > I'm keeping an eye on further reports but

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean, On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote: > One of the affected users reported back that the fix worked fine! > > I'm keeping an eye on further reports but so far I'd say everything's > working really well. Another bug report came in, button p

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean, On Wed, Apr 18, 2018 at 07:42:29PM +0200, Matthias Reichl wrote: > Hi Sean, > > On Wed, Apr 18, 2018 at 12:24:29PM +0100, Sean Young wrote: > > Hello Hias, > > > > On Tue, Apr 17, 2018 at 09:14:57PM +0200, Matthias Reichl wrote: > > > On Sun, Ap

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean, On Wed, Apr 18, 2018 at 12:24:29PM +0100, Sean Young wrote: > Hello Hias, > > On Tue, Apr 17, 2018 at 09:14:57PM +0200, Matthias Reichl wrote: > > On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote: > > > mceusb devices have a default timeout of 100ms,

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

Hi Sean! On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote: > mceusb devices have a default timeout of 100ms, but this can be changed. We finally added a backport of the v2 series (and also the mce_kbd series) to LibreELEC yesterday and ratcher quickly received 2 bugreports from users

Re: [PATCH v2 0/7] Improve latency of IR decoding

On Tue, Apr 10, 2018 at 07:39:43PM +0100, Sean Young wrote: > On Tue, Apr 10, 2018 at 07:53:43PM +0200, Matthias Reichl wrote: > > Hi Sean, > > > > On Sun, Apr 08, 2018 at 10:19:35PM +0100, Sean Young wrote: > > > The current IR decoding is much to

Re: [PATCH v2 0/7] Improve latency of IR decoding

Hi Sean, On Sun, Apr 08, 2018 at 10:19:35PM +0100, 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

Re: [PATCH 0/3] Improve latency of IR decoding

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 +, 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

Re: [PATCH 0/3] Improve latency of IR decoding

Hi Sean, On Sat, Mar 24, 2018 at 02:50:42PM +, 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

Issue with sharp protocol on ite-cir due to high idle timeout

Hi Sean, yesterday we received an interesting bug report that might help to motivate using a lower idle timeout on ite-cir: https://forum.libreelec.tv/thread/11951-sharp-ir-remote-on-intel-nuc-2820-double-presses/ The rather long message time of the sharp protocol (about 86ms) in combination

Re: [PATCH] media: rc: meson-ir: add timeout on idle

Hi Sean, On Mon, Mar 12, 2018 at 01:58:11PM +, Sean Young wrote: > On Mon, Mar 12, 2018 at 02:20:00PM +0100, Matthias Reichl wrote: > > On Sun, Mar 11, 2018 at 12:55:19PM +, Sean Young wrote: > > > That makes complete sense. I'm actually keen to get this lowered, sinc

Re: [PATCH] media: rc: meson-ir: lower timeout and make configurable

and max_timeout values are set, the timeout is > configurable via the LIRC_SET_REC_TIMEOUT ioctl. > > Signed-off-by: Sean Young <s...@mess.org> Tested-by: Matthias Reichl <h...@horus.com> Thanks a lot, this is working fine! so long, Hias > --- > drivers/media/r

Re: [PATCH] media: rc: meson-ir: add timeout on idle

Hi Sean, On Sun, Mar 11, 2018 at 12:55:19PM +, Sean Young wrote: > Hi Matthias, > > On Sat, Mar 10, 2018 at 06:38:28PM +0100, Matthias Reichl wrote: > > On Sat, Mar 10, 2018 at 11:27:45AM +, Sean Young wrote: > > > So if the timeout is below N then you wil

Re: [PATCH] media: rc: meson-ir: add timeout on idle

Hi Sean, On Sat, Mar 10, 2018 at 11:27:45AM +, Sean Young wrote: > Hi Matthias, > > On Fri, Mar 09, 2018 at 04:54:51PM +0100, Matthias Reichl wrote: > > On Thu, Mar 08, 2018 at 04:43:27PM +, Sean Young wrote: > > > On Tue, Mar 06, 2018 at 06:41:22PM +010

Re: [PATCH] media: rc: meson-ir: add timeout on idle

Hi Sean, On Thu, Mar 08, 2018 at 04:43:27PM +, Sean Young wrote: > On Tue, Mar 06, 2018 at 06:41:22PM +0100, Matthias Reichl wrote: > > Meson doesn't seem to be able to generate timeout events > > in hardware. So install a software timer to generate the > > ti

[PATCH] media: rc: meson-ir: add timeout on idle

Meson doesn't seem to be able to generate timeout events in hardware. So install a software timer to generate the timeout events required by the decoders to prevent "ghost keypresses". Signed-off-by: Matthias Reichl <h...@horus.com> --- drivers/media/rc/meson-ir.c | 22 +

Re: [BUG] ir-ctl: error sending file with multiple scancodes

Hi Sean, On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote: > On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote: > > The goal I'm trying to achieve is to send a repeated signal with ir-ctl > > (a user reported his sony receiver needs this to actually power u

[BUG] ir-ctl: error sending file with multiple scancodes

Hi Sean! According to the ir-ctl manpage it should be possible to send a file containing multiple scancodes, but when trying to do this I get a warning and an error message. I initially noticed that on version 1.12.3 but 1.12.5 and master (rev 85f8e5a99) give the same error. Sending a file with

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

gt; Fixes: d57ea877af38 ("media: rc: per-protocol repeat period") > Cc: <sta...@vger.kernel.org> # 4.14 > Signed-off-by: Sean Young <s...@mess.org> Tested-by: Matthias Reichl <h...@horus.com> I tested this locally with gpio-ir configured to 200ms timeout and we also

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

On Fri, Nov 17, 2017 at 03:52:50PM +0100, Matthias Reichl wrote: > Hi Sean! > > On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote: > > Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), > > double keypresses are reported on the ite-

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

via timeout (sth like timestamp - last_timestamp > protocol_repeat_period) and in that case immediately signalling keyup could help? Could well be that I'm missing somehting important and this is a bad idea. I guess I'd better let you figure something out :) so long, Hias > > Cc: <sta...@vger.kern

4.14 regression from commit d57ea877af38 media: rc: per-protocol repeat period

The following commit introduced a regression commit d57ea877af38057b0ef31758cf3b99765dc33695 Author: Sean Young Date: Wed Aug 9 13:19:16 2017 -0400 media: rc: per-protocol repeat period CEC needs a keypress timeout of 550ms, which is too high for the IR protocols.

Re: [PATCH] keytable: ensure udev rule fires on rc input device

> by another match in another rule. The argument to $env{key} is expanded > immediately. > > Signed-off-by: Sean Young <s...@mess.org> Tested-by: Matthias Reichl <h...@horus.com> so long & thanks for the fix, Hias > --- > utils/keytable/70-infrared.rules

Re: [PATCH] keytable: ensure udev rule fires on rc input device

this also prevents udev from starting ir-keytable on an > transmit only device, which has no input device. > > Signed-off-by: Sean Young <s...@mess.org> Signed-off-by: Matthias Reichl <h...@horus.com> One comment though, see below > --- > utils/keytable/70-infrar

[PATCH] [media] rc: gpio-ir-tx: switch to gpiod, fix inverted polarity

Manual handling of gpio output polarity was inverted. Switch to using gpiod, this allows us to simplify the code, delegate polarity handling to gpiod and remove the buggy local polarity handling code. Signed-off-by: Matthias Reichl <h...@horus.com> --- This patch is against [PATCH v2 3/6]

Re: ir-keytable question [Ubuntu 17.04]

On Sat, Jul 29, 2017 at 11:23:22AM +0100, Sean Young wrote: > Hi, > > On Sun, Jul 16, 2017 at 10:26:14PM -0700, Szabolcs Andrasi wrote: > > Hi, > > > > I'm using Ubuntu 17.04 and I installed the ir-keytable tool. The > > output of the ir-keytable command is as follows: > > > > > > > > Found

Re: [PATCH v2 4/6] [media] rc: pwm-ir-tx: add new driver

ss.org> Tested-by: Matthias Reichl <h...@horus.com> Tested on RPi2, with downstream RPi kernel 4.13-rc1, using ir-ctl to send RC-5 codes, against another RPi with gpio-ir-recv. Also verified signal polarity and frequency on scope. so long & thanks a lot, Hias > --- > MAINTAINERS

Re: [PATCH v2 3/6] [media] rc: gpio-ir-tx: add new driver

Hi Sean, On Fri, Jul 21, 2017 at 04:12:45PM +0200, Matthias Reichl wrote: > Hi Sean, > > On Fri, Jul 07, 2017 at 10:51:59AM +0100, Sean Young wrote: > > This is a simple bit-banging GPIO IR TX driver. > > thanks a lot for the driver, this is highly appreciated! > >

Re: [PATCH v2 3/6] [media] rc: gpio-ir-tx: add new driver

Hi Sean, On Fri, Jul 07, 2017 at 10:51:59AM +0100, Sean Young wrote: > This is a simple bit-banging GPIO IR TX driver. thanks a lot for the driver, this is highly appreciated! I tested the patch series on a RPi2, against RPi downstream kernel 4.13-rc1, and noticed an issue: the polarity of the

[v4l-utils] 70-infrared.rules starts ir-keytable too early

While testing serial_ir on kernel 4.11.8 with ir-keytable 1.12.3 I noticed that my /etc/rc_maps.cfg configuration wasn't applied. Manually running "ir-keytable -a /etc/rc_maps.cfg -s rc0" always worked fine, though. Digging further into this I tracked it down to the udev rule being racy. The udev

Re: [PATCH] [media] rc: raw decoder for keymap protocol is not loaded on register

er modules on-demand") > > Signed-off-by: Sean Young <s...@mess.org> Tested-by: Matthias Reichl <h...@horus.com> I've tested the backported patch below successfully on RPi3 with kernel 4.10 and decoder modules are loading fine again: # dmesg | grep "IR " [3.52

Re: Bug: decoders referenced in kernel rc-keymaps not loaded on boot

On Tue, Feb 21, 2017 at 07:34:39PM +, Sean Young wrote: > On Tue, Feb 21, 2017 at 07:49:29PM +0100, Matthias Reichl wrote: > > There seems to be a bug in on-demand loading of IR protocol decoders. > > > > After bootup the protocol referenced in the in-kernel rc keymap sh

Bug: decoders referenced in kernel rc-keymaps not loaded on boot

There seems to be a bug in on-demand loading of IR protocol decoders. After bootup the protocol referenced in the in-kernel rc keymap shows up as enabled (in sysfs and ir-keytable) but the protocol decoder is not loaded and thus no rc input events will be generated. For example, RPi3 with kernel

Re: [PATCH] v4l-utils: fix invalid protocol in streamzap keymap

On Sat, Feb 18, 2017 at 07:24:43PM +, Sean Young wrote: > On Fri, Feb 17, 2017 at 10:19:16AM +0100, Matthias Reichl wrote: > > ir-keytable can't load the streamzap keymap because the > > protocol type RC5_SZ is invalid: > > > > ./ir-keytable -w rc_keymaps/streamzap

[PATCH] v4l-utils: fix invalid protocol in streamzap keymap

ir-keytable can't load the streamzap keymap because the protocol type RC5_SZ is invalid: ./ir-keytable -w rc_keymaps/streamzap Protocol RC5_SZ invalid ... Fix this by changing the protocol type to RC-5-SZ which matches the kernel protocol rc-5-sz Signed-off-by: Matthias Reichl <h...@horus.

Re: [PATCH] Partly revert "[media] rc-core: allow calling rc_open with device not initialized"

; > Signed-off-by: Ole Ernst <olebo...@gmx.com> Tested-by: Matthias Reichl <h...@horus.com> I tested on Raspberry Pi model B with kernel 4.7.0, gpio-rc-recv, rc-hauppauge keymap and with this patch key repeat is working fine again. Thanks a lot for the quick fix! Hias > ---

IR button repeat not working in kernel 4.6 and 4.7

In kernel 4.6 and 4.7 holding down a button on an IR remote no longer results in repeated key down events. I've reproduced that issue on a Raspberry Pi B using a GPIO IR receiver. Other systems seem to be affected as well, for example Intel NUC with an ITE CIR receiver. Bisecting points to this