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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
