libinput drops keys from infrared remotes after changing keymap

[Sean Young]

Hi Hans,

On Mon, Sep 30, 2019 at 01:29:59PM +0200, Hans de Goede wrote:
> 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:
> > > > 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...

You're absolutely right, that is exactly what I'm trying to do.

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

Simply loading a new keymap while logged in, or rather solve the issue of
"my remote doesn't work after loading the correct keymap".

My longer term goal is to provide gnome-control-center plugin for
configuring IR receivers.

So what I'm hearing is that from libinput's perspective, an input device
should not change once created. In order to support this use-case, either
ask the user to logout/login or the kernel should re-create the input
device when the keymap changes.

Thanks,

Sean