On Tue, Mar 26, 2019 at 12:07:04AM +0100, Benjamin Valentin wrote:
> Nice! With this applied the remote feels a lot more snugly.
>
> In the forum thread you talked about a toggle bit to distiguish new
> button presses from held down buttons.
> The packet send by the Xbox Remote includes how much t
(0x01) key_up: KEY_1(0x0002)
267.570015: event type EV_SYN(0x00).
Add a protocol with the repeat value and set the timeout in the
driver to 10ms (to have a bit of headroom for delays) so the Xbox
DVD remote performs more responsive.
Signed-off-by: Matthias Reichl
---
Bug report about sluggish respon
The Zotac RC2604323/01G and RC2604329/02BG remotes use the 32-bit
rc6 protocol and toggle bit 15 (0x8000) on repeated button presses,
like MCE remotes.
Add the customer code 0x8034 to the 32-bit rc6 toggle
handling code to get proper scancodes and toggle reports.
Signed-off-by: Matthias
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&
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
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,
> i
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
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 rat
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
> objec
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
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,
> man
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
&
n LibreELEC testbuilds, so far we got
not complaints.
so long,
Hias
>
> Suggested-by: Matthias Reichl
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/mceusb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/rc/mceusb.c b/drivers/med
timeout in line with the settings
of many other receivers.
Signed-off-by: Matthias Reichl
---
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-c
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
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
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
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
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
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,
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 us
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 too slow. Man
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
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
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
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 wit
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, si
and max_timeout values are set, the timeout is
> configurable via the LIRC_SET_REC_TIMEOUT ioctl.
>
> Signed-off-by: Sean Young
Tested-by: Matthias Reichl
Thanks a lot, this is working fine!
so long,
Hias
> ---
> drivers/media/rc/meson-ir.c | 4 +++-
> 1 file cha
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 will n
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
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
> > time
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
---
drivers/media/rc/meson-ir.c | 22 ++
1 f
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 po
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
7af38 ("media: rc: per-protocol repeat period")
> Cc: # 4.14
> Signed-off-by: Sean Young
Tested-by: Matthias Reichl
I tested this locally with gpio-ir configured to 200ms timeout and
we also received feedback from 2 users that this change fixed the
issue with the ite-cir receiver.
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-
scancodes generated 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,
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. Also fill in kno
d
> by another match in another rule. The argument to $env{key} is expanded
> immediately.
>
> Signed-off-by: Sean Young
Tested-by: Matthias Reichl
so long & thanks for the fix,
Hias
> ---
> utils/keytable/70-infrared.rules | 2 +-
> 1 file changed, 1 insertion(
that this also prevents udev from starting ir-keytable on an
> transmit only device, which has no input device.
>
> Signed-off-by: Sean Young
Signed-off-by: Matthias Reichl
One comment though, see below
> ---
> utils/keytable/70-infrared.rules | 10 +-
> 1
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
---
This patch is against [PATCH v2 3/6] [media] rc: gpio-ir-tx
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 /s
Hi Sean,
sorry for double-post, forgot to CC the list and others.
On Fri, Jul 07, 2017 at 10:52:02AM +0100, Sean Young wrote:
> This is new driver which uses pwm, so it is more power-efficient
> than the bit banging gpio-ir-tx driver.
>
> Signed-off-by: Sean Young
Tested-by: Mat
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!
>
> I
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 g
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
er modules on-demand")
>
> Signed-off-by: Sean Young
Tested-by: Matthias Reichl
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.526404] Registered IR keymap rc-hauppa
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
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
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/strea
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
---
> Signed-off-by: Ole Ernst
Tested-by: Matthias Reichl
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
> ---
> drivers/media/rc/rc-main.c | 9 --
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 c
53 matches
Mail list logo