Re: [PATCH v2] media: rc: make scancodes 64 bit

[Sean Young <sean@mess.org>]

Hi Mauro,

On Mon, Mar 02, 2020 at 10:31:27AM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Jan 2020 11:54:16 +0000
> Sean Young <sean@mess.org> escreveu:
> 
> > There are many protocols that encode more than 32 bit. We want 64 bit
> > support so that BPF IR decoders can decode more than 32 bit. None of
> > the existing kernel IR decoders/encoders support 64 bit, for now.
> 
> The reason why we don't properly support 64 bits yet [2] is that it requires 
> some changes in order to provide a backward-compatible set of functions.

This should be supported.

> [2] Actually, I guess we have one driver with has 64 bits scancodes.

Which one is that?

> > The MSC_SCAN event can only contain 32 bit scancodes, so we no longer
> > generate these input events. The full 64 bit scancode can be read from
> > the lirc chardev.
> 
> For example, if all possible scancodes are <= 32 bit, it should still
> generate MSC_SCAN, as otherwise existing tools that rely on it will 
> break.

The scancodes are generated from the driver, and even if there is no
keymap loaded, scancodes are still generated. Therefore I don't think it
makes sense to switch on whether there are any 64 bit scancodes in the
current keymap.

We don't know if a driver will produce 64 bit scancodes right now. Although
BPF is the only route (currently) which can produce 64 bit scancodes,
there is no way to see if a BPF program will generate 64 bit scancodes
in advance.

So, I've changed the code to generate MSC_SCANCODE if the scancode fits
into 32 bits, reluctantly. However, I think this is the best we can do
for compatibility. I will post a v2 shortly.

Thanks
Sean