libinput drops keys from infrared remotes after changing keymap

[Peter Hutterer]

On Tue, Oct 01, 2019 at 09:39:51AM +0100, Sean Young wrote:
> 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.

just a late addition here: libinput devices are (currently) static too, so
libinput callers don't expect them to change. this may or may not be a
problem, depending on the caller. e.g. the ones calling
libinput_device_keyboard_has_key() wouldn't expect that to change during the
lifetime of the device.

so even if we'd move the key mappings above a few layers, we'd still end up
with the virtual device removal/addition.

Cheers,
   Peter