libinput drops keys from infrared remotes after changing keymap

[Peter Hutterer]

On Sun, Sep 29, 2019 at 08:17:38PM +0100, Sean Young wrote:
> Hi,
> 
> 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.

> 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.
> 
> 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

I think this is your best bet right now, but obviously the best approach
would be to set up the keymap that it can get loaded as part of the udev
rules loaded during initial device plug.

Cheers,
   Peter