Bug 91571 - xkb set via xkbcomp does not seem to apply to -i <device> (or does not stick if used on general device)
Summary: xkb set via xkbcomp does not seem to apply to -i <device> (or does not stick ...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xkbcomp (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-06 03:58 UTC by ngoonee
Modified: 2018-08-10 20:32 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ngoonee 2015-08-06 03:58:34 UTC
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.
Comment 1 Ran Benita 2015-11-21 17:00:06 UTC
xkbcomp and the xserver do not use libxkbcommon, so moving to xorg.
Comment 2 Will DeBerry 2015-12-18 20:13:32 UTC
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
Comment 3 Will DeBerry 2016-01-15 15:42:10 UTC
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.
Comment 4 oc-spam65 2017-02-26 15:02:32 UTC
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)
Comment 5 robsmith11 2017-08-03 20:15:11 UTC
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!
Comment 6 robsmith11 2017-08-26 03:04:06 UTC
Hello? Anyone?  Is this package no longer maintained?  This is a pretty blatant bug..
Comment 7 GitLab Migration User 2018-08-10 20:32:07 UTC
-- 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.