Bug 424000 - Plasma(?) eats my "c" key
Summary: Plasma(?) eats my "c" key
Status: RESOLVED DUPLICATE of bug 423084
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_keyboard_layout (show other bugs)
Version: 5.19.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-08 15:11 UTC by Gerion
Modified: 2020-07-13 15:39 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerion 2020-07-08 15:11:55 UTC
SUMMARY
When starting Plasma my "c" key (German qwertz layout) does not trigger any action anymore. Typing `setxkbmap de nodeadkeys` in the console reenable it. 

STEPS TO REPRODUCE
1. Start Plasma or switching the keyboard layout to "Deutsch (Nur Acute(´)-Akzentzeichen)".
2. Press the "c" key (e.g. in an editor).

OBSERVED RESULT
Nothing happens.

EXPECTED RESULT
A "c" is printed.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux 5.4.28
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
X-Server version: 1.20.8

ADDITIONAL INFORMATION
- I have the problem a very long time (1-2 years). Since the workaround is pretty easy, I have not investigated in reporting or fixing it before.

- I'm not sure what system component is responsible. Please reassign, if you have a better idea. I have tried `xev`. Here is the output with a working "c" key:
```
KeyPress event, serial 40, synthetic NO, window 0xa400001,
    root 0x1a2, subw 0x0, time 200291144, (1263,927), root:(1263,947),
    state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (63) "c"
    XmbLookupString gives 1 bytes: (63) "c"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0xa400001,
    root 0x1a2, subw 0x0, time 200291232, (1263,927), root:(1263,947),
    state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (63) "c"
    XFilterEvent returns: False
```
Here is the output with a not working "c" key:
```
FocusOut event, serial 40, synthetic NO, window 0xa400001,
    mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 40, synthetic NO, window 0xa400001,
    mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 40, synthetic NO, window 0xa400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 40, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   64  0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 40, synthetic NO, window 0xa400001,
    root 0x1a2, subw 0x0, time 200396769, (1265,1085), root:(1265,1105),
    state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (63) "c"
    XFilterEvent returns: False
```

- Typing `setxkbmap de nodeadkeys` always fixes the problem. Switching the layout with Plasma (per GUI) always triggers the problem.

- I recently experimented with the Neo layout. On the Neo layout the "c" keyboard key is mapped to the letter "ä". When switching to Neo, my "ä" is not working (and "c" is working). That means that the same keyboard key triggers the false behaviour (at least within the same Plasma session). I also discovered that, when I switch to Neo and type multiple times "ä" immediately after the switch, the first "ä"s arrives in my terminal. Then some mechanism triggers and all following "ä"s are eaten by some component.

- Typing `setxkbmap de neo` does _not_ fix the Neo layout.

- I have controlled my hotkeys. I have not found a global hotkey that begins with "c".

If you have any suggestions how to debug or fix this, please say so. I will see to collect the data.
Comment 1 David Edmundson 2020-07-09 22:09:48 UTC
Can I have setxkbmap -print output for the working and not working case.

From what you've said either we're not switching to the right layout, or there's a bug lower in the stack in the xkb code.
Comment 2 David Edmundson 2020-07-09 22:10:05 UTC
Marking as needsinfo, please reset the status when you report back
Comment 3 Gerion 2020-07-09 22:57:18 UTC
I have changed my layout in the GUI to "Deutsch (ohne Akzepttasten)" to make it more consistent with the command line command. This has not changed the problem.

So here are my outputs:

Working case (triggered per "setxkbmap de nodeadkeys"):
```
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwertz)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+de(nodeadkeys)+inet(evdev)"	};
	xkb_geometry  { include "pc(pc101)"	};
};
```
Not working case (triggered per GUI setting):
```
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwertz)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete+caps(caps_lock):2+misc(assign_shift_left_action):2+level5(level5_lock):2+caps(caps_lock):3+misc(assign_shift_left_action):3+level5(level5_lock):3"	};
	xkb_symbols   { include "pc+de(nodeadkeys)+de(neo):2+de(neo):3+inet(evdev)"	};
	xkb_geometry  { include "pc(pc101)"	};
};
```
Comment 4 David Edmundson 2020-07-10 11:26:31 UTC
Is this the same thing: 423084

If so killing kglobalaccel5 should temporarily restore that key working
Comment 5 Gerion 2020-07-13 15:11:07 UTC
Yes, this has worked: Killing kglobalaccel5 reactivates both "c" and "ä" within the normal qwertz and neo layout.

BTW: It's really hard to type `killall kglobalaccel5` without a "c" key ;).
Comment 6 David Edmundson 2020-07-13 15:39:36 UTC
ok, lets follow up on that duplicate report

*** This bug has been marked as a duplicate of bug 423084 ***