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@xxxxxxxx> 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
