Re: [PATCH 2/2] media: rtl28xxu: improve IR receiver

["Marko Mäkelä" <marko.makela@iki.fi>]

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