libinput drops keys from infrared remotes after changing keymap

[Sean Young]

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.

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

Usually this is the case if a user has /etc/rc_maps.cfg set up.


Sean