libinput drops keys from infrared remotes after changing keymap

[Hans de Goede]

Hi Sean,

On 02-10-2019 11:33, Sean Young wrote:
> 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

Ok.

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

Right, I agree.

I think i would be best for the g-c-c plugin to set the rcmap globally which
would mean writing out /etc/rc_maps.cfg.

The normal way to do this is a small dbus activated daemon (so that it is
not running all the time and is not started unnecessarily at boot) which
can write out /etc/rc_maps.cfg for us.

Such a daemon would then normally use polkit to check if the process making
dbus calls to change the config is allowed to do so (reading it can be
allowed to the world I think).

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

You're welcome. As mentioned above I believe a dbus activated daemon
to do the actual config changes (with polkit as authorization mechanism)
would be best here. That is more or less the standard design pattern
for cases like this. See e.g. also systemd-localed for writing
/etc/vconsole.conf, etc.

Regards,

Hans