| Summary: | When a wireless mouse is attached, keyboard layouts are forgotten | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Emil Sedgh <emilsedgh> |
| Component: | Input/Keyboard | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | arysin, daniel, peter.hutterer |
| Version: | 7.7 (2012.06) | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Emil Sedgh
2012-11-29 21:23:46 UTC
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.