libinput drops keys from infrared remotes after changing keymap

[Sean Young]

Hi,

On Tue, Oct 01, 2019 at 03:32:52PM +0200, Hans de Goede wrote:
> On 01-10-2019 10:39, Sean Young wrote:
> > On Mon, Sep 30, 2019 at 01:29:59PM +0200, Hans de Goede wrote:
> > > 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.
> 
> Right, so if this is for a gnome-control-center plugin then I guess
> the idea is the user sets things up once and then they never change, right?

Yes, that's the idea. It might need an interface for testing keymaps
and/or adding custom keymaps. That depends on the community, really.

> So how does the keymap stay set / gets stored ? Do you write it out
> globally so that udev will do the right thing next boot.

So ir-keytable comes with a udev rule which automagically load the keymap
based on what's in /etc/rc_maps.cfg. I'm not sure how this should be
written from g-c-c or whether this is right thing to do.

See:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules

> Or does the
> g-c-c plugin register an autostart user service which does this once
> the user logs in?

I'm not convinced that's the right approach.

> Assuming you set the mapping globally, then you need some DBUS activated
> helper daemon running as root, or some such, right (hopefully with
> access managed by polkit)?   Then it wouldn't be too hard to do the:
> 
>     sudo udevadm trigger --action=remove /sys/class/input/event5
>     sudo udevadm trigger --action=add /sys/class/input/event5
> 
> Peter suggested from that daemon, and if this is only done on
> keymap changes, then this seems like a reasonable solution?

It does seem reasonable. It seemed a bit strange at first.

I've been maintaining rc-core (IR) kernel side for some time, I'm trying
to move up the stack. Your help is very much appreciated!

Many thanks,

Sean