Hi Marko, 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. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text > > 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? Sean
