Re: X11 and hot-plugged keyboards and multiple layouts
Nicolas George writes: > Nicolas George (12020-02-19): >> 8<8<8<8< xi2watch.c >8>8>8>8 > > Hi. > > I am replying to my own mail of three years ago where I explained how to > configure X11 to set different layouts on different keyboards and handle > hot-plugging without root privileges. Since a standard tool did not > exist yet, I had attached a small program of mine to do it. > > I have seen this code reproduced on the web, so at least somebody is > using it. Good. > > Then it might interest you that I have made an extended version of it > and published it: > > https://gitlab.com/Cigaes/xi2bind I finally gave xi2bind a try, using the hierarchy option to do something (run xmodmap) when a keyboard is plugged in. Or in my case, I have a USB switch which connects or disconnects a USB hub with my mouse and keyboard connected to the hub. It works fine but usage was a little baffling and it doesn't help the example on how to use the hierarchy command doesn't work due to wrong quoting. With some work I think I've worked out which event when the keyboard is plugged in I should use to run xmodmap, out of the six that happen when my keyboard is plugged in. With the mouse and hub the total number of events is actually 16! For sure it doesn't really matter if xmodmap runs sixteen or six times or only once but it feels right. So for adding my extra keys to my quite normal US layout keyboard this works fine. Unfortunately something weird happens with the modifier keys and my extra keys working depend on setting Alt_R to mode_switch and that's not something I can automate currently. Nothing to do with xi2bind though.
Re: X11 and hot-plugged keyboards and multiple layouts
Nicolas George writes: > Does the xmodmap effect stay if you run it manually after the keyboard > is hot-plugged? Yes. I don't have a desktop environment in use on my desktop computer either so this should work for me.
Re: X11 and hot-plugged keyboards and multiple layouts
Anssi Saari (12023-01-09): > Wow. It's exactly what I need since I've started to use a USB switch in > my home office. Assuming it works for me of course. I've thought about > writing a udev rule but haven't gotten around to it. I hope the program I wrote can help you. > I've tried to run xmodmap after the keyboard is hot plugged (via telling > the USB switch to switch) but it's like the xmodmap doesn't take even > after I added a delay. Although it seems it worked sometimes. Maybe the > issue is I've tried to run xmodmap from the other computer over ssh, I > don't know. Does the xmodmap effect stay if you run it manually after the keyboard is hot-plugged? If so, then you probably already something watching for new devices and applying a layout. Maybe your desktop manager, they have a habit of ruining simple things. If not, then you need to get it to work reliably before you can consider automating it. Regards, -- Nicolas George
Re: X11 and hot-plugged keyboards and multiple layouts
Nicolas George writes: > Nicolas George (12020-02-19): >> 8<8<8<8< xi2watch.c >8>8>8>8 > > Hi. > > I am replying to my own mail of three years ago where I explained how to > configure X11 to set different layouts on different keyboards and handle > hot-plugging without root privileges. Since a standard tool did not > exist yet, I had attached a small program of mine to do it. Wow. It's exactly what I need since I've started to use a USB switch in my home office. Assuming it works for me of course. I've thought about writing a udev rule but haven't gotten around to it. I've tried to run xmodmap after the keyboard is hot plugged (via telling the USB switch to switch) but it's like the xmodmap doesn't take even after I added a delay. Although it seems it worked sometimes. Maybe the issue is I've tried to run xmodmap from the other computer over ssh, I don't know.
Re: X11 and hot-plugged keyboards and multiple layouts
Nicolas George (12020-02-19): > 8<8<8<8< xi2watch.c >8>8>8>8 Hi. I am replying to my own mail of three years ago where I explained how to configure X11 to set different layouts on different keyboards and handle hot-plugging without root privileges. Since a standard tool did not exist yet, I had attached a small program of mine to do it. I have seen this code reproduced on the web, so at least somebody is using it. Good. Then it might interest you that I have made an extended version of it and published it: https://gitlab.com/Cigaes/xi2bind It has the ability to run a command when a device is plugged or unplugged, and now it allows to define keyboard shortcuts attached to only a specific keyboard. (By the way, do you know a mailing list or website dedicated to announcing initial releases of small projects like that?) Regards, -- Nicolas George signature.asc Description: PGP signature
X11 and hot-plugged keyboards and multiple layouts
Hi.
A few weeks back, I asked about standard tools to handle hot-plugged
keyboards with different layouts under X11 without root privileges,
hinting that I know how to do it with non-standard tools or with root
privileges.
Here is a concentrate of what I know about the issue, for Debian testing
as of 2020-02-19.
Most of it is already documented on the web, but not all, and not all in
one place. If you find this interesting, feel free to dump it in a wiki
somewhere. And please let me know if there are inaccuracies.
The default keyboard layout on Debian is configured in
/etc/default/keyboard. This file is created and edited by the package
keyboard-configuration, whose bulk is in the debconf configure script,
not the actual contents.
/etc/default/keyboard can be queried and carelessly overwritten by a
DBus service provided by systemd-localed in the systemd package. It can
be queried by the client localectl or with a generic DBus client:
dbus-send --system --print-reply \
--dest=org.freedesktop.locale1 /org/freedesktop/locale1 \
org.freedesktop.DBus.Properties.Get \
string:org.freedesktop.locale1 string:X11Layout
But X.org does not use this.
The udev rule /lib/udev/rules.d/64-xorg-xkb.rules provided by the
xserver-xorg-core package causes /etc/default/keyboard to be imported
into the environment of udev events detected to be associated with
keyboards. The environment can be overridden by a later rule, something
like:
ACTION=="add|change", \
SUBSYSTEM=="input", KERNEL=="event[0-9]*", \
ENV{ID_INPUT_KEY}=="?*", \
ATTRS{idVendor}=="1997", ATTRS{idProduct}=="2433", \
ENV{XKBLAYOUT}="fr"
udev stores the final environment in /run/udev/data/c${major}:${minor}.
When a new input device is detected, X.org applies the configuration
files. If nothing is specified, /usr/share/X11/xorg.conf.d/10-evdev.conf
from xserver-xorg-input-evdev tells to use the evdev driver but is soon
overridden by /usr/share/X11/xorg.conf.d/40-libinput.conf from
xserver-xorg-input-libinput that tells to use the libinput driver.
The configuration snippets can define several InputClass sections that
can use match criteria to selectively apply options. See INPUTCLASS in
xorg.conf(5) and the examples of the two files above.
If the configuration does not set the layout, the options from the udev
environment are used. I have not found where this fact is documented, I
suspect it is a very generic mechanism in X.org that can apply to any
options, for example touchpad fancy stuff.
All this allows to set different layouts for hot-plugged keyboards using
either snippets of configuration for the X11 server or udev rules.
All this is more or less explained there:
https://wiki.debian.org/XStrikeForce/InputHotplugGuide
It all requires root privileges. Let's see what we can do without.
Handling the layout of hot-plugged keyboards involves two X11
extensions, XKEYBOARD aka XKB and XInputExtension aka XI2.
Configuring a keyboard layout is done with XKB.
The high-level configuration of XKB involves a few settings: layout,
variant and options, as set in /etc/default/keyboard. They are mapped to
snippets of detailed configuration using the contents of
/usr/share/X11/xkb/rules/. It produce a skeleton description that looks
like:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(azerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_geometry { include "pc(pc105)" };
xkb_symbols { include "pc+fr+compose(menu)+terminate(ctrl_alt_bksp)" };
};
The high-level tool to set the layout is setxkbmap.
The description, either generated by rules or written by hand, is
handled by xkbcomp, a tool to convert a textual description into a
compiled description and back. It can operate with files, with standard
extension .xkb for text and .xkm for compiled, and directly with the
tables in the X11 server, only in compiled form obviously.
The current complete description can be obtained with:
xkbcomp $DISPLAY output.xkb
A description ca be loaded to the keyboard with:
xkbcomp input.xkb $DISPLAY
We can display the complete current layout with:
xkbcomp :0 - | xkbcomp - - | xkbprint - - | display -
Hot-plugged input devices are handled by the XI2 extension. The standard
tool xinput from the package with the same name can be used to control
it.
Keyboards are grouped in a shallow hierarchy, with the "Virtual core
keyboard" as the root and master and the actual keyboards under it. I
know it is possible to have several master pointers, which correspond to
several actual pointers on the screen moving independently. I have not
checked what happens if we try to create a second master keyboard.
The xinput command without arguments print the current hierarchy.
xinput can be used to change options on individual devices. That's how
we set the speed on a specific mouse for example:
xinput set-prop "Logitech USB Optical Mouse" "libinput Accel Speed" -0.4
For keyboard layouts, xinput is not smart enough. We need to use
