I have two layouts: "us,ir". Here are my root window's XKB_RULES_NAMES: _XKB_RULES_NAMES(STRING) = "evdev", "pc101", "us,ir", "", "" When I plug my mouse's USB dongle in, _XKB_RULES_NAMES changes to: _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "", "" In X log, I find this: [266860.668] (**) Option "xkb_rules" "evdev" [266860.668] (**) Option "xkb_model" "pc104" [266860.668] (**) Option "xkb_layout" "us" Here's full X log when I attach it: [266860.648] (II) config/udev: Adding input device A4TECH USB Device (/dev/input/event1) [266860.648] (**) A4TECH USB Device: Applying InputClass "evdev keyboard catchall" [266860.648] (II) Using input driver 'evdev' for 'A4TECH USB Device' [266860.648] (**) A4TECH USB Device: always reports core events [266860.648] (**) evdev: A4TECH USB Device: Device: "/dev/input/event1" [266860.668] (--) evdev: A4TECH USB Device: Vendor 0x9da Product 0x54f [266860.668] (--) evdev: A4TECH USB Device: Found 1 mouse buttons [266860.668] (--) evdev: A4TECH USB Device: Found scroll wheel(s) [266860.668] (--) evdev: A4TECH USB Device: Found relative axes [266860.668] (--) evdev: A4TECH USB Device: Found absolute axes [266860.668] (--) evdev: A4TECH USB Device: Found x and y absolute axes [266860.668] (--) evdev: A4TECH USB Device: Found keys [266860.668] (II) evdev: A4TECH USB Device: Configuring as mouse [266860.668] (II) evdev: A4TECH USB Device: Configuring as keyboard [266860.668] (II) evdev: A4TECH USB Device: Adding scrollwheel support [266860.668] (**) evdev: A4TECH USB Device: YAxisMapping: buttons 4 and 5 [266860.668] (**) evdev: A4TECH USB Device: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [266860.668] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input580/event1" [266860.668] (II) XINPUT: Adding extended input device "A4TECH USB Device" (type: KEYBOARD, id 9) [266860.668] (**) Option "xkb_rules" "evdev" [266860.668] (**) Option "xkb_model" "pc104" [266860.668] (**) Option "xkb_layout" "us" [266860.668] (II) evdev: A4TECH USB Device: initialized for relative axes. [266860.668] (WW) evdev: A4TECH USB Device: ignoring absolute axes. [266860.669] (**) A4TECH USB Device: (accel) keeping acceleration scheme 1 [266860.669] (**) A4TECH USB Device: (accel) acceleration profile 0 [266860.669] (**) A4TECH USB Device: (accel) acceleration factor: 2.000 [266860.669] (**) A4TECH USB Device: (accel) acceleration threshold: 4 [266860.670] (II) config/udev: Adding input device A4TECH USB Device (/dev/input/event2) [266860.670] (**) A4TECH USB Device: Applying InputClass "evdev pointer catchall" [266860.670] (II) Using input driver 'evdev' for 'A4TECH USB Device' [266860.670] (**) A4TECH USB Device: always reports core events [266860.670] (**) evdev: A4TECH USB Device: Device: "/dev/input/event2" [266860.671] (--) evdev: A4TECH USB Device: Vendor 0x9da Product 0x54f [266860.671] (--) evdev: A4TECH USB Device: Found 20 mouse buttons [266860.671] (--) evdev: A4TECH USB Device: Found scroll wheel(s) [266860.671] (--) evdev: A4TECH USB Device: Found relative axes [266860.671] (--) evdev: A4TECH USB Device: Found x and y relative axes [266860.671] (II) evdev: A4TECH USB Device: Configuring as mouse [266860.671] (II) evdev: A4TECH USB Device: Adding scrollwheel support [266860.671] (**) evdev: A4TECH USB Device: YAxisMapping: buttons 4 and 5 [266860.671] (**) evdev: A4TECH USB Device: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [266860.671] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/input/input581/event2" [266860.671] (II) XINPUT: Adding extended input device "A4TECH USB Device" (type: MOUSE, id 10) [266860.671] (II) evdev: A4TECH USB Device: initialized for relative axes. [266860.671] (**) A4TECH USB Device: (accel) keeping acceleration scheme 1 [266860.671] (**) A4TECH USB Device: (accel) acceleration profile 0 [266860.671] (**) A4TECH USB Device: (accel) acceleration factor: 2.000 [266860.671] (**) A4TECH USB Device: (accel) acceleration threshold: 4 [266860.672] (II) config/udev: Adding input device A4TECH USB Device (/dev/input/mouse0) [266860.672] (II) No input driver specified, ignoring this device. [266860.672] (II) This device may have been added with another device file. [266860.673] (II) config/udev: Adding input device A4TECH USB Device (/dev/input/js0) [266860.673] (II) No input driver specified, ignoring this device. [266860.673] (II) This device may have been added with another device file. Result is that when i plug in my mouse, I cannot change keyboard layout anymore.
See Bug 21669 - "the _XKB_RULES_NAMES property is obsolete" how do you set the layout?
I use kde and therefore kde's keyboard kded module sets the layout. Digging through kde's code, it seems that it sets the layout using XkbLockGroup. It also reads the layout list using XGetWindowProperty with this atom rule: XInternAtom(display, _XKB_RF_NAMES_PROP_ATOM, False); I monitored the root window using xprop -root -spy and was _XKB_RULES_NAMES changing upon mouse plugin there. Im also available on #xorg on freenode if you need more information. Also, here is kde's code responsible for changing the layout: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/kcontrol/keyboard/x11_helper.cpp
Emil and I talked on IRC about this, summary here: - whenever a new device is added, the server changes the rules prop to whatever that device's RMLVO is - KDE appears to look at the rules prop only, not at the layout. if the prop change, KDE updates its shortcuts/UI to reflect that Result: new devices with a default layout disable KDE's switching. XKB-internal group switching still works, and each device does come up with the right keyboard layout. The server doesn't keep the rules prop around other than as write-only property. It's obsolete (see Bug 21669), and while there's room for making the behaviour better than what it is now, it's nowhere near the top of anyone's priority list atm.
Peter, I am the maintainer of the KDE keyboard module, I was reading your comment above but didn't quite understand if there's better way to get current layouts. If yes could you please point me to some code? Also currently KDE listens to xinput events and if new keyboard is plugged in it reapplies the keyboard layout configuration (by calling setxkbmap). This works in many cases but sometimes it fails. I wander if the timing is wrong: e.g. X.org sets rules prop *after* xinput event is generated and thus overrides what kde has just reconfigured. Thanks Andriy
this can indeed happen, but it's unlikely to unless the server is really busy. to avoid that (well, make it even more unlikely), make sure you only apply the layout once the device is _enabled_, not just added. The two usually happen in quick succession and on almost 100% of all setups, but there is a difference. I don't really have a better approach though, the rules prop is simply misbehaving here and getting the RMLVO from XKB isn't possible.
Thanks Peter, I've found the problem I had in KDE code: the code was listening to new device from xinput and reconfigured the layouts if new keyboard device is found. Originally when I implemented this code it was for new usb keyboards to have the layouts configured correctly. But when I was restoring my laptop from sleep I was getting a lot of new keyboard device events: webcams, WMI, Video Bus, Sleep Button etc so I added the code to ignore some of them so that I don't have to reconfigure layouts 10 times. I guess that code was also taking care of prop being reset, but if new device was in my "ignore" list it would skip reconfiguring the layouts.
-- 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/driver/xf86-input-keyboard/issues/10.
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.