| Summary: | xkb set via xkbcomp does not seem to apply to -i <device> (or does not stick if used on general device) | ||
|---|---|---|---|
| Product: | xorg | Reporter: | ngoonee |
| Component: | App/xkbcomp | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | daniel, freedesktop, robsmith11 |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
xkbcomp and the xserver do not use libxkbcommon, so moving to xorg. I can confirm that using -i for a specific ID that it acts as a 'flip of a coin' if it actually takes affect. I have tested this across 3 different input devices with the following steps: * xkbcomp -I$HOME/.xkb ~/.xkb/keymap/skylight -i 12 $DISPLAY # To Apply the change * xkbcomp -I$HOME/.xkb ~/.xkb/keymap/default -i 12 $DISPLAY # To fall back to default symbols/layout There are no errors on output, only some minor warnings. On any given run of the command, it could work or not have any affect on the output of keybindings. OS: Gentoo 32bit xkbcomp Version: 1.2.4 and 1.3.0 X Version: 1.15.0 To add more detail to this issue, I have found an interesting experiment that allows the new mapping to always be applied, but with a crazy workaround. Find device ID for device in question > ~# xinput >? Virtual core pointer id=2 [master pointer (3)] >? ? Virtual core XTEST pointer id=4 [slave pointer (2)] >? ? Heng Yu Technology DONGLE id=9 [slave pointer (2)] >? ? Logitech USB Optical Mouse id=10 [slave pointer (2)] >? ? Sugar Creek Solutions LLC IMX101-01 v20.31 id=12 [slave pointer (2)] >? ? Sugar Creek Solutions LLC IMX101-01 v20.31 id=13 [slave pointer (2)] >? Virtual core keyboard id=3 [master keyboard (2)] > ? Virtual core XTEST keyboard id=5 [slave keyboard (3)] > ? Power Button id=6 [slave keyboard (3)] > ? Power Button id=7 [slave keyboard (3)] > ? Heng Yu Technology DONGLE id=8 [slave keyboard (3)] > ? Sugar Creek Solutions LLC IMX101-01 v20.31 id=11 [slave keyboard (3)] # Apply mapping to the device in question > xkbcomp -I$HOME/.xkb ~/.xkb/keymap/custom.xkb -i 11 -synch $DISPLAY Press a key on an input device that is *not* the targeted device Press a key on the target device and see that it is remapped successfully This can be shorted even more with a simple one liner: > xkbcomp -I$HOME/.xkb ~/.xkb/keymap/custom.xkb -i 11 -synch $DISPLAY && xdotool key Ctrl Seems really odd that you would need to activate a key on something that isn't the target device before the mapping takes affect. Any additional insight would be appreciated. I want to confirm that the "crazy workaround" works... and this looks like a bug.
In may case :
$ xinput --list # (summary)
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Lenovo ThinkPad Compact USB Keyboard with TrackPoint id=10 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Lenovo ThinkPad Compact USB Keyboard with TrackPoint id=15 [slave keyboard (3)]
↳ Lenovo ThinkPad Compact USB Keyboard with TrackPoint id=11 [slave keyboard (3)]
$ xkbcomp -i 15 thinkpad_usb_layout.xkb $DISPLAY # change external keyboard map
The last line has no effect by itself (whereas it should). It only has effect after pressing a key of the built-in laptop keyboard (this step should not be necessary!)
Olivier (on Debian with xorg 1:7.7+16, x11-xkb-utils 7.7+3)
I needed to use the "crazy workaround" on a fresh install of Arch linux to get a custom keyboard mapping to work with my 2nd keyboard. Please fix! Hello? Anyone? Is this package no longer maintained? This is a pretty blatant bug.. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/app/xkbcomp/issues/9. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I have a Lenovo N700, which appears as both a mouse and keyboard (connected via bluetooth or wireless, all details here are while its connected as bluetooth). Currently it has id 14 as seen below. ⎜ ↳ Lenovo Mice N700 id=14 [slave pointer (2)] Reporting 8 classes: Class originated from: 14. Type: XIButtonClass Buttons supported: 13 Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" Button state: Class originated from: 14. Type: XIKeyClass Keycodes supported: 248 I wanted to remap one of the letters (the letter c) to some other key (in testing, I just use 'q'). The reason being a side-swipe on the touch-sensitive pad on this mouse would produce c-down, Super-down, c-up, Super-up (I have evemu-record output if that would be useful). Which would basically type the letter c wherever my cursor happened to be, which is annoying (for example in gmail's web interface I'd get a compose window). When I get the current keyboard map using xkbcomp -i 14 :0 map.xkb, I can edit it to change the output. I then try to apply this output using xkbcomp -i 14 synch map.xkb :0 This does not change what the key does on my mouse, even though re-running xkbcomp -i 14 :0 map.xkb shows the change did 'take'. So I tried various inputs out of the below:- ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)] ⎜ ↳ Lenovo Mice N700 id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ ASUS USB2.0 Webcam id=10 [slave keyboard (3)] ↳ Asus WMI hotkeys id=11 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)] A summary of what I've found:- Using input 14 does not change anything Using input 12 has two different results:- If I start typing c on my keyboard the letter c comes out. However if I side-swipe on my mouse, the letter c comes out, if I then switch back to keyboard, thereafter the letter q comes out if I use mouse or keyboard If I start by sideswiping with my mouse the letter q comes out, then the letter q will always come out whether using mouse or keyboard My conclusion from using input 12 is that using the mouse somehow 'activates' the xkb change for both mouse and keyboard Using input 5 does not change anything Using input 3 has two different results:- If I start typing c on my keyboard, the letter q comes out. Side-swiping then gives q, but switching back to the keyboard gives c from then on If I start sideswiping on my mouse, the letter c comes out, and the same from the keyboard thereafter My summary so far has been that the usage of this mouse somehow resets input 3 and/or 12. This may have something to do with udev etc., I am not familiar enough to know. I'm pretty sure I've found a bug, but have no idea what the bug actually is. For reference, I'm running Arch Linux 64-bit, so pretty much the latest release of everything.