Hi,
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:
When using IR receivers using libinput, key events get dropped if a new
rc keymap is loaded and the key was not in the old keymap.
The input device keybit changes and libevdev does not notice this. Then
here we end up returning false:
https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/libinput.c#L3100
The event is reported via evtest but not via libinput debug-events.
basic problem here: evdev isn't really designed for run-time changes of
devices, so both libevdev and libinput expect the device to be static.
There's SYN_CONFIG which **may** be usable for this but it's unused in the
kernel and thus nothing in userspace handles it either. A discussion years
ago about defining SYN_CONFIG for devices that change at runtime was put
into the too-hard basket, in most cases creating a new device is more
sensible.
That's a shame.
So, for example, mceusb IR devices register with a keymap for MCE remotes.
If later a keymap for a different remote is loaded, e.g.:
$ ir-keytable -w /lib/udev/rc_keymaps/imon_rsc.toml
If I press any button which does not exist in the MCE remote keymap
(for example space or backspace), libinput does not report these events.
I've tried fixing this by making the kernel input device have all the keybit
fields set, but this had to be reverted since it overflowed the size of
uevents.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=05f0edadcc5fccdfc0676825b3e70e75dc0a8a84
If libinput receives an EV_KEY event which is unexpected, we could go
and check if the input device and see if keybit has added.
yeah, well... none of the libinput clients would know how to handle this
either, so libinput would have to emulate removal and plug-in of a new
device. Which of course is doable but quite a bit of work to get right.
However in a diferent sense ir-keytable changed the input device underneath
libinput; another way to fix this to add support for loading IR keymaps
to libinput and all the way up the stack. I've been wanting to do this
anyway but I have no idea if there is any interest in this.
So how about libinput handling IR keymap changes? Would patches for that be
accepted? libinput would need to load BPF IR decoders for this to work,
amongst other things. This would would mostly mean porting it from
ir-keytable.
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...
So can you please explain your specific use-case here?
Regards,
Hans
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
