Hi Sean,
Tue, Jul 05, 2022 at 08:25:48AM +0100, Sean Young wrote:
On Mon, Jul 04, 2022 at 10:04:38PM +0300, Marko Mäkelä wrote:
Mon, Jul 04, 2022 at 11:00:38AM +0100, Sean Young wrote:
> On Mon, Jul 04, 2022 at 12:20:01PM +0300, Marko Mäkelä wrote:
> > Mon, Jul 04, 2022 at 08:21:39AM +0100, Sean Young wrote:
> > > On Sun, Jul 03, 2022 at 08:02:14PM +0300, Marko Mäkelä wrote:
> > I tested the attached patch (which was created on 5.19-rc5, which
> > failed to boot on my system for unrelated reasons) on Linux 5.17, on
> > top of your fixes to rtl28xxu and rc-core.
>
> You'll need to fix this.
The 5.19-rc5 boot failure could have been related to LUKS setup on that
machine, because a kernel panic message was displayed before I was being
prompted for an encryption key. The modules would not have been loaded at
that point, so I do not think that it is related to my modifications.
When compiled for the v5.17 kernel release tag on another computer, the
patch that implements rc_keydown_or_repeat() worked for me.
It does not look like there are many changes in drivers/media/rc between
5.17 and 5.19.
Your patch needs a `Signed-off-by` and it should not be attached, it should
be inline in your email.
Thank you for your patience. I hope that I got it right. It would be my
very first patch submission to the Linux kernel. I did not see it appear
on this list archive yet. You are Cc'd.
> See https://github.com/seanyoung/cir/
This could open up many possibilities. Would the decoded events also be
available via some low-level interface to user-space programs, in addition
to the input event driver?
The plan was for it to run once, generate an eBPF program, attach that an
exit. The eBPF program sends the decoded stuff to the lirc chardev in
this struct:
https://www.kernel.org/doc/html/latest/userspace-api/media/rc/lirc-dev-intro.html#data-types-used-by-lirc-mode-scancode
This is the struct you're amending with LIRC_SCANCODE_FLAG_REPEAT.
Will that be sufficient for your needs?
I think that it should cover the most common types of remote control
units.
I can name an example of a complex IR remote control, which I think
would be challenging to repurpose for controlling anything else than the
original type of device. But, I would think that something Bluetooth or
WLAN based on a touchscreen device will replace IR in such applications.
The remote control of my air conditioner presents all settings on a
local LCD. On every change, maybe after a short timeout of inactivity,
it will send a long IR message with all the settings. The 32 bits of
keycode or 64 bits of scancode would not be sufficient for that.
Marko
