Alt+a does not work in KDE desktop

English Applications
1

Hello,
I am having problem with using Alt+a keys combination in KDE Plasma Desktop in the latest Tumbleweed (but likely would be the same in other OpenSuse with KDE variants/versions). For example in Emacs run in graphical window the combination of keystrokes (should move the cursor to the start of sentence) is not captured and nothing happens. If I switch to virtual console (ctrl-alt-f1) and run Emacs there the Alt+a works without problems.
Looking into the “Shortcuts - System settings” (exporting the Scheme into text file and searching for Alt-a combination) there is no action associated with it that would be interfering with it functioning in Emacs. I am using the default settings for the shortcuts.
This problem is on my desktop and also laptop - so it seems to be general, not associated with some hw configuration.

There is also some strange behavior going on regarding the Shortcuts: sometimes when in the Shortcuts settings I change the settings for KWin - Activate Window Demanding Attention from Ctrl+Alt+A to Alt+a and then revert it back the Alt+a combination starts to work - have no idea why.

Googling this problem I have found practically the same topic here from 2016, but no solution:
https://forum.kde.org/viewtopic.php?f=289&t=131750

So I wonder, where else could the shortcuts be defined in Opensuse/KDE so that I can remove it from “there” and make it work in Emacs?

2

Was also trying to compile the xorg-show-grabs utility that should help to decipher the output of

xdotool key "XF86LogGrabInfo"

written into

/var/log/Xorg.0.log

to see if the Alt+a appears to be used by some application in that log.
But unfortunately it is not possible to create executable in Tumbleweed:

dmd xorg-show-grabs.d 
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: cannot find -lphobos2 
collect2: error: ld returned 1 exit status 
**Error: **linker exited with status 1

But that would be for another thread …

3 
$ cat /etc/os-release  
NAME="openSUSE Tumbleweed" 
# VERSION="20210802"
...

$ plasmashell --version 
plasmashell 5.22.4

For me Alt-a works. In Firefox, all text is selected, with the cursor on the desktop the Widgets menu pops up.

I see here a pretty complete guide on how to figure out what is grabbing the key: https://thesynack.com/posts/hotkeys-grabbed/

4

It seems that, your issue is only within Emacs – it’s possibly not an issue with a KDE Plasma session.

In the special case of Emacs, the issue is usually – “Where is the <Meta> key?” –

In a VT (tty1 … tty6), yes, Emacs called from the command line possibly uses <Alt> as the <Meta> key but, no guarantees …

  • In a KDE Plasma session, the “Windows
    ” key – <Super L> usually maps to <Meta> – despite the Keyboard Map indicating that, the <Alt L> key is (possibly) also the <Meta L> key … - The Emacs bottom line on the <Meta> key is – <https://www.gnu.org/software/emacs/manual/html_node/efaq/No-Meta-key.html&gt;.
  • The O’Reilly book “Learning GNU Emacs
    ” is quite blunt in the text related to the <Meta> key –

On other workstations and terminals, you’ll have to find it yourself, if it exists.

5

In my case it is not just Emacs, it seems to be any application, have tested it in Blender where Alt+a should play an animation. But in my case it does nothing.
I have created short video illustrating the behavior in Emacs and Blender and also showing that simply by doing some “witchcraft” in Shortcuts setting in KDE I am able to make Alt+a work as it should (until the next restart) - it is weird, you need to see it:

[video]https://youtu.be/KZIpQMdEyfA[/video]

  1. At the start you see the Alt+a shortcut is not working in Emacs (should move to the start of sentence) and also in Blender (should start/stop playing animation)
  2. Then I change KDE Shortcuts settings for KWin - “Activate window demanding action” changed from Ctrl+Alt+a to Alt+a
  3. That of course did not help regarding Emacs and Blender
  4. Then I revert the Shortcuts settings back
  5. And now Alt-a works both in Emacs and Blender (and likely in any other application) until next restart

And regarding shortcut for selecting all (like in text editor), for me it was always Ctrl+a, both in Windows and Linux (and I am not altering shortcuts in any way) - strange.

6

My suspicion regarding why that steps in KDE Shortcuts setting fixed the problem (temporarily) was that there might be some action in the Shortcuts setting assigned to Alt+a and that by assigning it to kWin action it gets deleted (so that it is not assigned to two different actions simultaneously), and then when I remove Alt+a assignment from KWin the Alt+a bacame free and available to be captured by Emacs etc. But looking into the Exported Shortcuts schemes before and after shows nothing assigned to Alt+a:

https://susepaste.org/45497316
https://susepaste.org/69480149

So it does not make much sense, unless there is some hidden Alt+a assignment setup in KDE Shortcuts settings not exposed to the user.

I will now look again at the

xdotool key "XF86LogGrabInfo"

command, as also marel has suggested, but have not got much luck with it in the past.

7

I have been trying to get some info using the xdotool already in the past, but for me it seems to give nothing useful. In my case the command should be:

KEY=Alt_L+a
xdotool keydown ${KEY}; xdotool key XF86LogGrabInfo; xdotool keyup ${KEY}

and that writes this output into /var/log/Xorg.0.log:
https://susepaste.org/84580481

for example there is no “activating key” string mentioned in the link you have sent in the log. There is a lot of entries for /usr/bin/kwin_x11, but nothing that would give me any usable info or show any association to Alt+a shortcut.

8

Meaning that, the way KDE Plasma handles the “Windows” key – which is also the <Meta> key for many applications – is influencing the mapping of the <Meta> key to the <Alt> key in some applications, including GNU Emacs …

Please report back if this helps.

9

Not sure if I understand it correctly, but that link seems to discusse how to prescribe what action a modifier (Alt, Meta, Ctrl) only should do. In my case I believe it should do nothing, therefore I have tried the commands:

kwriteconfig5 --file ~/.config/kwinrc --group ModifierOnlyShortcuts --key Alt ""
[FONT=monospace]kwriteconfig5 --file ~/.config/kwinrc --group ModifierOnlyShortcuts --key Meta ""[/FONT]
qdbus org.kde.KWin /KWin reconfigure

but that had no effect, Alt alone do nothing and Alt+a does not work.

10

One funny fact that is bordering with a form of national discrimination :

When one of the keyboard layout is Czech the Alt+a is not working.

(I am using English (US) and Czech (QWERTY) - but seems to be the same with any Czech layout)

I have tested to add German layout (to the standard English) - and that works. But when I add the Czech layout it stops working! And it does not matter which particular layout is currently activated. That seems to explain why other people have not experienced this problem.(because not that much people use Czech layout outside Czech Republic)

Could someone please try to add a Czech layout and test that Alt+a stops working ? (in Emacs or elsewhere)

11

Well, as weird as it is - it’s true. I was about to reply “what’s the problem, alt+a is working here - even in emacs.” After changing to czech-qwerty - it actually stopped working. Going back to German - all good… :question:

For sure that’s not done deliberately as in “discrimination” - but I can’t tell what it is indeed.

Here: Leap 15.2, Plasma 5.18.6, KDE Frameworks 5.71.0, QT-version 5.12.7

12

Good finding that the problem is linked to using a Czech keyboard layout.

Thanks for clearly documenting what you did.

I checked what xev showed using xev:

KeyPress event, serial 36, synthetic NO, window 0x7c00001, 
    root 0x142, subw 0x0, time 22880013, (-244,153), root:(2138,1379), 
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, 
    XLookupString gives 0 bytes:  
    XFilterEvent returns: False 

KeyPress event, serial 36, synthetic NO, window 0x7c00001, 
    root 0x142, subw 0x0, time 22880733, (-244,153), root:(2138,1379), 
    state 0x8, keycode 38 (keysym 0x61, a), same_screen YES, 
    XLookupString gives 1 bytes: (61) "a" 
    XFilterEvent returns: False 

KeyRelease event, serial 36, synthetic NO, window 0x7c00001, 
    root 0x142, subw 0x0, time 22880861, (-244,153), root:(2138,1379), 
    state 0x8, keycode 38 (keysym 0x61, a), same_screen YES, 
    XLookupString gives 1 bytes: (61) "a" 
    XFilterEvent returns: False 

KeyRelease event, serial 36, synthetic NO, window 0x7c00001, 
    root 0x142, subw 0x0, time 22880877, (-244,153), root:(2138,1379), 
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, 
    XLookupString gives 0 bytes:  
    XFilterEvent returns: False

So the Alt key and a key are separate events, so could it be that somehow they are not combined to Alt+a?

I found “setxkbmap -print” gives you the keymap setting and “xkbcomp -xkb $DISPLAY xkbmap” creates a xkbmap file with I think all mapping.
Maybe diffing these for a working versus the not workling keyboard config gives some clues.

13

[QUOTE=marel;
So the Alt key and a key are separate events, so could it be that somehow they are not combined to Alt+a?

I found “setxkbmap -print” gives you the keymap setting and “xkbcomp -xkb $DISPLAY xkbmap” creates a xkbmap file with I think all mapping.
Maybe diffing these for a working versus the not workling keyboard config gives some clues.[/QUOTE]

Seems the keys are not registered by the xev command as being pressed, just when it is released.

When there is Czech layout defined (not even active) and I press Alt+a the keys are registered only during release:

FocusOut event, serial 40, synthetic NO, window 0x5c00001, 
    mode NotifyGrab, detail NotifyAncestor 

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

KeymapNotify event, serial 40, synthetic NO, window 0x0, 
    keys:  2   0   0   0   64  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 0x5c00001, 
    root 0x28f, subw 0x0, time 1622647, (796,460), root:(796,489), 
    state 0x18, keycode 64 (keysym 0xffe9, **Alt_L**), same_screen YES, 
    XLookupString gives 0 bytes:  
    XFilterEvent returns: False 

**KeyRelease** event, serial 40, synthetic NO, window 0x5c00001, 
    root 0x28f, subw 0x0, time 1622695, (796,460), root:(796,489), 
    state 0x10, keycode 38 (keysym 0x61, **a**), same_screen YES, 
    XLookupString gives 1 bytes: (61) "a" 
    XFilterEvent returns: False

and when there is not Czech layout it (xev) registers both Press and Release:

**KeyPress** event, serial 40, synthetic NO, window 0x5200001,
    root 0x28f, subw 0x0, time 20752996, (88,-29), root:(88,0),
    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 0x5200001,
    root 0x28f, subw 0x0, time 20754196, (88,-29), root:(88,0),
    state 0x18, keycode 38 (keysym 0x61, **a**), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

**KeyRelease** event, serial 40, synthetic NO, window 0x5200001,
    root 0x28f, subw 0x0, time 20754364, (88,-29), root:(88,0),
    state 0x18, keycode 38 (keysym 0x61, **a**), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

**KeyRelease** event, serial 40, synthetic NO, window 0x5200001,
    root 0x28f, subw 0x0, time 20756420, (88,-29), root:(88,0),
    state 0x18, keycode 64 (keysym 0xffe9, **Alt_L**), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

What is really puzzling is that even if the Czech layout is not selected as active it is somehow affecting the behavior.
It seems I have reached the limits of how deep I am capable to debug this problem, so will try to report it as a bug.

14

Thanks for confirming the nasty behavior on another system. I have reported a bug and I am really looking forward to see how it is going to be explained.
https://bugzilla.opensuse.org/show_bug.cgi?id=1189180