Plasma 5.4 - Changing keyboard layout disables a key
Tags:
None
Registered Member 
|
Hi, I found a really annoying behavior, I have a spanish keyboard, if I set the Yakuake shorcut to be the "ª" key then the "m" key gets disabled!
I'm using the normal spanish layout (which is the ones that matches my keyboard). Watching the layout preview from the KDE settings I noticed that the "m" key has the "ª" symbol as an alternative, could this be the problem?
Last edited by itaranto on Tue Dec 22, 2015 11:40 pm, edited 1 time in total.
|
|
There's no "normal" spanish layout. There are eu, es and lat; es and lat provide 7, resp. 5 variants, but none seems to have "ª" on the 3rd level of m/M?
"ª" is usually Shift+° ? Doe pressing m show yakuake instead? Does it generate output in "xev"? Does M (in contrast to m) work? The KF5 version will be more relevant than the Plasma version, because the important bit is kglobalaccel5 |
|
Registered Member
|
I have Layout=Spanish Variant=Default Label=es. Here's a picture of my actual keyboard: http://i.imgur.com/cwrFM6v.jpg Here's a picture of the layout displayed in the settings: http://i.imgur.com/N0QSIJA.png Whenever I set the key "º" my "m" gets disabled ( I made a mistake is º instead of ª). |
|
Might relate to https://git.reviewboard.kde.org/r/124710/ - what version is your frameworks/kglobalaccel? (as mentioned, the plasma desktop version is irrelevant)
However, "m" should then rather trigger yakuake, not be "disabled". Also please confirm that it's "disabled" by running "xev -event keyboard" and pressing "m" (check whether there's a reaction) and report whether "M" (Shift+m) still works as expected. |
|
Registered Member
|
I Have: Qt: 5.5.0 KDE Frameworks: 5.16.0 kf5-config: 1.0 Here's the xev's output:
I pressed the m key follwed by the º key, I see the keycodes 36 and 58, so it's seem to be detected. Shift+m (M) does work.
Last edited by itaranto on Tue Dec 15, 2015 10:25 pm, edited 1 time in total.
|
|
How do you determine that "m" doesn't work? The event is generated and (unlike °, which should be the KeymapNotify event) not grabbed by anything (or, if it's passively grabbed, forwarded)
=> Does "m" stop working everywhere? Tried eg. xterm? |
|
Registered Member
|
The "m" does not work on any "text box", tried: Konsole, Kate, Firefox... even xterm |
|
There's indeed some oddity I missed - there's only a KeyRelease event, ie. the key is release, but apparently not pressed.
That *should* not be caused by the keyboard grabs in kglobalaccel - do you use evdev or libinput as xf86-input driver? (or maybe even the keyboard driver? - in doubt, paste /var/log/Xorg.0.log) |
|
Registered Member
|
Sorry I don't know which driver is used, here's my /var/log/Xorg.0.log output:
Last edited by itaranto on Tue Dec 22, 2015 1:59 am, edited 2 times in total.
|
|
evdev.
No idea what configures this: > [ 7.352] (**) evdev: Razer Razer Abyssus: YAxisMapping: buttons 4 and 5 > [ 7.352] (**) evdev: Razer Razer Abyssus: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 But it means that the upward wheel also triggers the wheel emulation (in general a very cool feature - you can hold a button and move the mouse to cause wheel events) If it's enabled, that might explain weird behavior on scrolling. I hope "Razer Razer Abyssus" remains the name, try "xinput --list" otherwise, then
|
|
Registered Member
|
Thanks about the feedback about my mouse (Razer Abyssus) it works really good, you know this post was about keyboard layout, right?
 (In case you confused posts hahaha) |
|
*LOL*
There was a bugreport against KWin about "weird" scrolling behavior (which ultimately turned out to be a bug in libinput) and when I saw the emu-button assigned to one of the wheelbuttons, my brains somehow took a detour-shortcut there  The evdev driver is used for the keyboard. Let's take a wild guess: do you have a numlock key? Does toggling numlock have any impact on the matter? |
|
Registered Member
|
LOL
I tried pressing the num lock but it doesn't work, I also have like a rollable keyboard, I tried with that with the same result. I also tried with my laptop, which has also a Spanish keyboard. Same effect. I could try with a English keyboard but I don't have any around. The problem seems to be in the Spanish layout, that associates "º" with "m" somehow. Justin case, this is my xinput output
|
|
Sorry for the delay.
What's really odd is that ° would rather match M than m. Also ° is AltGr+Shift+0 - and now here it is: I've both 3rd level assignments (AltGr+Shift+m, AltGr+Shift+0), but while "m" works as expected, "0" fails. There's (afaics) no problem assigning Ctrl+° - but at least I can now check what's going on there =) |
|
|
Bookmarks
Who is online
Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]
