libinput drops keys from infrared remotes after changing keymap

[Hans de Goede]

Hi,

On 01-10-2019 10:39, 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.

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?

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. Or does the
g-c-c plugin register an autostart user service which does this once
the user logs in?

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?

Regards,

Hans