libinput drops keys from infrared remotes after changing keymap

[Hans de Goede]

Hi,

On 30-09-2019 10:33, Sean Young wrote:
> On Mon, Sep 30, 2019 at 11:34:04AM +1000, Peter Hutterer wrote:
>> On Sun, Sep 29, 2019 at 08:17:38PM +0100, Sean Young wrote:
>>> When using IR receivers using libinput, key events get dropped if a new
>>> rc keymap is loaded and the key was not in the old keymap.
>>>
>>> The input device keybit changes and libevdev does not notice this. Then
>>> here we end up returning false:
>>>
>>> https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/libinput.c#L3100
>>>
>>> The event is reported via evtest but not via libinput debug-events.
>>
>> basic problem here: evdev isn't really designed for run-time changes of
>> devices, so both libevdev and libinput expect the device to be static.
>> There's SYN_CONFIG which **may** be usable for this but it's unused in the
>> kernel and thus nothing in userspace handles it either. A discussion years
>> ago about defining SYN_CONFIG for devices that change at runtime was put
>> into the too-hard basket, in most cases creating a new device is more
>> sensible.
> 
> That's a shame.
> 
>>> So, for example, mceusb IR devices register with a keymap for MCE remotes.
>>> If later a keymap for a different remote is loaded, e.g.:
>>>
>>> $ ir-keytable -w /lib/udev/rc_keymaps/imon_rsc.toml
>>>
>>> If I press any button which does not exist in the MCE remote keymap
>>> (for example space or backspace), libinput does not report these events.
>>>
>>> I've tried fixing this by making the kernel input device have all the keybit
>>> fields set, but this had to be reverted since it overflowed the size of
>>> uevents.
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=05f0edadcc5fccdfc0676825b3e70e75dc0a8a84
>>>
>>> If libinput receives an EV_KEY event which is unexpected, we could go
>>> and check if the input device and see if keybit has added.
>>
>> yeah, well... none of the libinput clients would know how to handle this
>> either, so libinput would have to emulate removal and plug-in of a new
>> device. Which of course is doable but quite a bit of work to get right.
>>   
>>> However in a diferent sense ir-keytable changed the input device underneath
>>> libinput; another way to fix this to add support for loading IR keymaps
>>> to libinput and all the way up the stack. I've been wanting to do this
>>> anyway but I have no idea if there is any interest in this.
> 
> So how about libinput handling IR keymap changes? Would patches for that be
> accepted? libinput would need to load BPF IR decoders for this to work,
> amongst other things. This would would mostly mean porting it from
> ir-keytable.
> 
>>> Any thoughts on this would be appreciated!
>>
>> libinput relies on udev, either directly or through the X server. So if you
>> trigger your device to get removed and re-added through udev, libinput will
>> add it and re-initialize it with whatever current bits it has.
>>
>>   sudo udevadm trigger --action=remove /sys/class/input/event5
>>   sudo udevadm trigger --action=add /sys/class/input/event5
> 
> Hmm, this is bit of an ugly workaround, even if generated them from
> ir-keytable.
> 
> We could change the kernel to re-create the input device when the keymap
> changes, but this does not fit the current model very well.
> 
> Not quite sure how to solve this yet.

Just reading along here as an ex libinput contributor. I have the feeling
that it will help if you can explain your specific use-case, because it
sounds like you really want to change the keymap on the fly, while normally
the keymap is something which gets setup once and the loaded by udev add
device init time...

So can you please explain your specific use-case here?

Regards,

Hans