When using konsole or any other terminal emulator, alt-1 should activate "(arg: 1)" in readline handling. This works in all other window managers, but in fresh KDE installs on several different computers and software configurations, the event does nothing. alt-2 and other numbers work normally. The problem is not restricted to console emulators - it is across all applications, for example in emacs, argument passing also does not work. Changes in keymap do not change the behaviour. I use slovene (si) keymap. I have been noticing this problem for more than half a year, so this is not specific to 4.9 version. I checked the global shortcuts, but alt-1 is not bound to anything. I don't run xbindkeys or similar software. I also checked the output of xev, and it reacts differently: alt-2: KeyPress event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235118774, (-790,-290), root:(589,471), state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235122942, (-790,-290), root:(589,471), state 0x18, keycode 11 (keysym 0x32, 2), same_screen YES, XLookupString gives 1 bytes: (32) "2" XmbLookupString gives 1 bytes: (32) "2" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235123030, (-790,-290), root:(589,471), state 0x18, keycode 11 (keysym 0x32, 2), same_screen YES, XLookupString gives 1 bytes: (32) "2" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235123934, (-790,-290), root:(589,471), state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235124622, (-790,-290), root:(589,471), state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False alt-1: KeyPress event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235190662, (-833,52), root:(546,813), state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False FocusOut event, serial 40, synthetic NO, window 0x1a00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 40, synthetic NO, window 0x1a00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 40, synthetic NO, window 0x0, keys: 2 4 0 0 0 0 0 0 1 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 0x1a00001, root 0xf1, subw 0x0, time 235192134, (-833,52), root:(546,813), state 0x18, keycode 10 (keysym 0x31, 1), same_screen YES, XLookupString gives 1 bytes: (31) "1" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x1a00001, root 0xf1, subw 0x0, time 235194494, (-833,52), root:(546,813), state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Notice the extra Focus and KeymapNotify events that should not be there. Is there a KDE component that swallows this event or can this be resolved by changing configuration? Reproducible: Always Steps to Reproduce: 1. launch terminal emulator (konsole) or emacs 2. press alt-1 Actual Results: The shortcut (key press combination) is ignored, nothing happens. Expected Results: In terminal emulators, (arg: 1) should indicate the beginning of the line. In emacs, M-1- should appear in the minibuffer.
Cannot reproduce. When I use "Alt+1" in Konsole, bash displays an "(arg: 1)" prompt.
I did a bit more research. It appears that changing the keymap via setxkbmap si results in this change and when you switch back to "us", it does not go away. I was testing by switching back and forth and thus did not notice the problem. Sorry. The same call does not affect fluxbox. I don't have the KDE's own keyboard layout settings enabled (no layouts added), so in principle there should be no clash with xorg's settings.
I hit the same problem (alt-1 and alt-7 does not work) after an openSUSE 12.2 -> 12.3 upgrade. The workaround is to try to assign that shortcut to something (e.g. system settings -> desktop effects -> all effects -> zoom -> settings -> assign alt-1 to zoom out, click OK; the assign will fail, but alt-1 will start to work), but it has only effect till the next restart. I guess it'll be specific to a non-English default keyboard: $ grep XkbLayout /etc/X11/xorg.conf.d/90-keytable.conf Option "XkbLayout" "hu"
Just a small update: so I had "hu" in xorg.conf.d and also I had "hu" and "us" configured in KDE (with the previous being the default). The problem goes away by setting "us" in xorg.conf.d and setting "us" as default in KDE.
I confirm tha alt-7 is also a problem for me, not just alt-1. Other numbers are ok. This is a strange bug, foreign keyboards somehow map these combinations and they stay mapped when switching from one to the other. Is there any indication that this will get fixed? It is a major setback for international users of emacs and advanced readline features.
If the behavior depends on the selected keymap, I guess the bug is with the X keyboard mappings. Andriy, any idea?
The issue is specific to kde - switching keyboard mappings in other window managers does not create any issues. If Miklos is right and attempting to remap the shortcut restores the balance, the issue seems to be that KDE somehow silently binds these key combinations internally, and thus intercepts the events. The event is generated by X, but it does not reach the applications.
Well I played with it and this is kinda weird: 1) if I do "setxkbmap si" I loose the Alt+1 in konsole right away - even if I don't press this combination and imediately do "setxkbmap us" back it's not working any more 2) if I assign Alt+1 to some global action (e.g. switch keyboard layout), it works as assigned; then if I unassign it, Alt+1 will work in konsole again 3) I shut down keyboard daemon and this was still happening (so it's not related to our keyboard layout code) 4) I see the same problem if I start xterm (!) so it's not pure kconsole problem 5) I looked into the "si" layout file and it includes rs(latin) which in turn includes some more parts, I tried to exclude those parts and the offending line is: include rs(latlevel3) if I comment it out, then Alt+1 works (although only every 2nd time - I think first include - latin(type3) has something to do with it). So my guess is how the keys for alt, 1 and 7 are defined in these latin(type3) and rs(latlevel3) affects kconsole and xterm hanlding of Alt+1. My suspicion is that is has to do some composing keys - that "every 2nd time" part above usually points to composing (which I don't know much about). Unfortunately I don't have much knowledge about those modules or free time to research deeper but I am hoping this will give somebody else good starting point to work with.
Today I accidentally discovered that this bug only manifests if kded is running. I was troubleshooting a different problem (also related to keyboard layouts): layout switching worked on the built-in keyboard of my notebook but whenever I pressed any key on an external USB keyboard the layout would switch back to US; and the label and flag for the alternative layout (Hungarian) wasn't displayed in any case. I discovered that kded wasn't running. When I started kded4, layout switching started working with the external keyboard (and the Hungarian label started being displayed as appropriate), but alt+1 and alt+7 broke.
It is still present in Fedora 22, KDE 5 - Alt-7 does not reach the application at here. US layout set as default and HU as secondary in KDE settings. /etc/xorg.conf.d/00-keyboard.conf file contains 'Option "XkbLayout" "us"'. The workaround introduced by Andriy works: "if I assign Alt+1 to some global action (e.g. switch keyboard layout), it works as assigned; then if I unassign it, Alt+1 will work in konsole again". Killing/restarting kded does not help.
This bug still exist in KDE 5 (KUbuntu 16.04). Very annoying...
The bug is still present with this settings (according to About System): KDE Plasma: 5.13.2 KDE Frameworks: 5.47.0 Qt Version: 5.10.1 Kernel: 4.12.0-1-amd64 This is on Debian Buster. Upon login I can't use "Alt+1" to change to the first tab in Chrome, or in any terminal app (Konsole, Terminator, QTerminal). If I go to System Settings/Custom Shortcuts and I set "Alt+1" as the trigger of any action and then remove it, I can then use it for in the apps mentioned.
The bug is still present with the following settings: KDE Plasma: 5.14.3 KDE Frameworks: 5.52.0 Qt Version: 5.11.1 Kernel: 4.17.18-gentoo This is on Gentoo. Upon login I can't use "Alt+1" to change to the first tab in Chrome, or in any terminal app (Konsole, Terminator, QTerminal). If I open a konsole and press "Alt+1" or "Alt+7" there is no response, whereas other numbers work (printout of text "(arg: 2)" etc.) If I go to System Settings/Custom Shortcuts and I set "Alt+1" as the trigger of any action and then remove it, I can then use it for in the apps mentioned.
Still present in 5.14.5.1 as well. Interestingly, if I workaround it via the global shortcut hack, it breaks again when a new input device is connected (even a mouse). Also, I *think* I didn't have the problem with Debian's 4:5.13.5-1+b1 (but it definitely came back with 5.15.5.1) I'm changing the status to "confirmed" because the bug affects several people.
I also just made another discovery: adding the Spanish layout as a third layout also breaks alt+4 (so this is with us, hu, es). If instead of Spanish I add German (us, hu, de) alt+1 and alt+7 are still broken, but alt+4 works. With "us, es" alt+1 and alt+4 is broken but alt+7 works. FWIW, my XKB settings are: XKBMODEL="pc104" XKBLAYOUT="us" XKBVARIANT="" XKBOPTIONS="lv3:ralt_switch,compose:rwin"
I have the exact same situation as Andy Teijelo "2018-08-01 21:29:23 UTC" described. My-OS = kde-neon-useredition-20190321-0530
Hi All, I've found the conflict on Hungarian layout (hu): a) I use Alt+<numbers> for tab switching on every app that is capable. b) System settings -> shortcuts -> global shortcuts -> kwin -> Walk through windows of current application, defaults to Alt + ` Walk through windows of current application (reverse), defaults to Alt + ~ So a quick workaround is to remove those two system hotkeys. Thus I can understand why Alt+1 and Alt+7 were the two erroneous key combinations: they are the tilde and grave on Hungarian layout. AFAICS the issue has nothing related to "composing keys" or "dead keys". Slovenian layout is similar, and Spanish has asciitilde on Alt+4. Maybe there are other issues with keyboard event handling too. Under the conflicting circumstances, neither the KWin "Walk through windows" function nor the application's user shortcut works, which is strange for me. Though some quick UI refresh can be seen triggered by Alt+1 and Alt+7. Maybe KWin at low levels has been triggered, without knowning much about layouts, intercepting the keystrokes for some reason, even if grave comes from Alt + 7, which does not really mean Alt + grave? And later another component gets only grave, without Alt, so eventually the "Walk through windows" function will not run? Another question: how should we configure default shortcuts and differend keyboard layouts in general? Thoughts: - Modifiers can be used to compose a shortcut, from the system configuration point of view; while they can be used to compose characters, from the layout design point of view. - Logically 2 kinds of shortcuts seems showing up to me: - "movable", e.g. Meta+Q: Activities, no matter where "Q" lays on the current layout. - "positional", e.g. - this case: Alt + "the key under ESC", - this case: Alt + <number> - '[', ']', '<', '>', '+', '-' (or rather '=' instead of '+') "Positional" will often has the "modifier problem". Special fun: the two conflicting shortcuts serve absolutely similar purposes: a) switching between tabs of an application b) switching between windows of an application :) Hi All, I've found the conflict on Hungarian layout (hu): a) I use Alt+<numbers> for tab switching on every app that is capable. b) System settings -> shortcuts -> global shortcuts -> kwin -> Walk through windows of current application, defaults to Alt + ` Walk through windows of current application (reverse), defaults to Alt + ~ So a quick workaround is to remove those two system hotkeys. Thus I can understand why Alt+1 and Alt+7 were the two erroneous key combinations: they are the tilde and grave on Hungarian layout. AFAICS the issue has nothing related to "composing keys" or "dead keys". Slovenian layout is similar, and Spanish has asciitilde on Alt+4. Maybe there are other issues with keyboard event handling too. Under the conflicting circumstances, neither the KWin "Walk through windows" function nor the application's user shortcut works, which is strange for me. Though some quick UI refresh can be seen triggered by Alt+1 and Alt+7. Maybe KWin at low levels has been triggered, without knowning much about layouts, intercepting the keystrokes for some reason, even if grave comes from Alt + 7, which does not really mean Alt + grave? And later another component gets only grave, without Alt, so eventually the "Walk through windows" function will not run? Another question: how should we configure default shortcuts and differend keyboard layouts in general? Thoughts: - Modifiers can be used to compose a shortcut, from the system configuration point of view; while they can be used to compose characters, from the layout design point of view. - Logically 2 kinds of shortcuts seems showing up to me: - "movable", e.g. Meta+Q: Activities, no matter where "Q" lays on the current layout. - "positional", e.g. - this case: Alt + "the key under ESC", - this case: Alt + <number> - '[', ']', '<', '>', '+', '-' (or rather '=' instead of '+') "Positional" will often has the "modifier problem". Special fun: the two conflicting shortcuts serve absolutely similar purposes: a) switching between tabs of an application b) switching between windows of an application :)
(In reply to Kübi from comment #17) Sorry, forgot to mention that my system is Debian 10.0.
@Kübi **Works for me!** also after logging out and back in. Thanks mate!
(In reply to Joakim from comment #19) > @Kübi **Works for me!** also after logging out and back in. > > Thanks mate! and just to clarify, this works for me on Swedish (se) layout, so not specific to Hungarian.
I believe this will wind up as yet another issue fixed with the fix for Bug 423305. *** This bug has been marked as a duplicate of bug 423305 ***