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