Bug 402913

So this worked in 5.14.2? Can you verify that it didn't break with Frameworks 5.52?

I have tried to check which versions of plasma shell, frameworks and Qt I was running before. I could find the following version numbers in my distro's package manager log:

Uninstalled:
- kde-plasma/plasma-pa-5.13.5
- kde-frameworks/krunner-5.50.0
- dev-qt/qtquickcontrols2-5.11.1

Installed
- kde-plasma/breeze-5.14.3
- kde-frameworks/krunner-5.52.0
- dev-qt/qttranslations-5.11.1

So my last update took me to different versions of the plasma shell and frameworks.

Perhaps also of relevance:

Another shortcut, Alt+R (resets rotation) is still working. Not all Alt+* are affected.

Please include your ~/.config/kglobalshortcutsrc at a time when it is not working.

Please also install xev and include the output of pressing the gloal shortcut above that window

Created attachment 117313 [details]
kglobalshortcutsrc at a time when Alt+H is not working

The contents of this file do not change when I apply the workaround (even after clicking 'apply' and quitting the System Settings application).

This is the output of 'xev' while Alt+H is NOT working:

---------------------------------------------------------------------------

KeyPress event, serial 40, synthetic NO, window 0x3e00001,
    root 0x1e6, subw 0x0, time 61349601, (64,-26), root:(2370,709),
    state 0x0, 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 0x3e00001,
    mode NotifyGrab, detail NotifyAncestor

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

KeymapNotify event, serial 40, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   8   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 0x3e00001,
    root 0x1e6, subw 0x0, time 61349913, (64,-26), root:(2370,709),
    state 0x8, keycode 43 (keysym 0x68, h), same_screen YES,
    XLookupString gives 1 bytes: (68) "h"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x3e00001,
    root 0x1e6, subw 0x0, time 61350225, (64,-26), root:(2370,709),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

This is the output of 'xev' when it IS working after doing the bind-then-unbding workaround:

---------------------------------------------------------------------------

KeyPress event, serial 40, synthetic NO, window 0x3e00001,
    root 0x1e6, subw 0x0, time 61602401, (60,-19), root:(2359,702),
    state 0x0, 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 0x3e00001,
    root 0x1e6, subw 0x0, time 61602681, (60,-19), root:(2359,702),
    state 0x8, keycode 43 (keysym 0x68, h), same_screen YES,
    XLookupString gives 1 bytes: (68) "h"
    XmbLookupString gives 1 bytes: (68) "h"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x3e00001,
    root 0x1e6, subw 0x0, time 61602729, (60,-19), root:(2359,702),
    state 0x8, keycode 43 (keysym 0x68, h), same_screen YES,
    XLookupString gives 1 bytes: (68) "h"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x3e00001,
    root 0x1e6, subw 0x0, time 61603145, (60,-19), root:(2359,702),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Retested with KDE Plasma 5.14.5, KDE Frameworks 5.52.0, Qt 5.11.3.

Issue unchanged.

Now running KDE Plasma 5.14.5, KDE Frameworks 5.54.0, Qt 5.11.3.

My shortcuts are still broken. I can 'killall kglobalaccel5' to make them work.

I'm running Ubuntu 19.04, and I have this problem also. It seems to be linked to the 'Alt+~' keyboard shortcut to 'Walk Through Windows of Current Application (Reverse)'

Here are my system details:
~> inxi -S
System:    Host: jay-alien-ubu Kernel: 5.0.0-16-generic x86_64 bits: 64 Desktop: KDE Plasma 5.15.4 
           Distro: Ubuntu 19.04 (Disco Dingo) 
~> inxi
CPU: Dual Core Intel Core i3-4130T (-MT MCP-) speed/min/max: 798/800/2900 MHz Kernel: 5.0.0-16-generic x86_64 
Up: 22h 53m Mem: 2119.8/11951.3 MiB (17.7%) Storage: 931.51 GiB (23.2% used) Procs: 255 Shell: fish 3.0.2 
inxi: 3.0.33 


Steps to reproduce:
1. Open Global Shortcuts -> KWin -> Walk Through Windows of Current Application (Reverse)
2. Map it to 'Alt+Shift+`' (Which becomes represented as 'Alt+~')
3. Go to another application, like the terminal, and try to use 'Alt+H' to execute a shortcut. In the fish shell this will open a man page, for example.
  -- Outcome: Cursor flashes, but shortcut doesn't work.

Workaround:
1. Open Global Shortcuts -> KWin -> Walk Through Windows of Current Application (Reverse)
2. Unmap it, and apply.
3. Go to another application, like the terminal, and try to use 'Alt+H' to execute a shortcut.
  -- Outcome: Shortcut works correctly.

Not sure what is going on here, but I'm happy to help investigate further if needed.

any update? 

I have the same issue as Markus. Alt+h is not working for me. I can fix it by assigning and unassigning key in settings->shortcuts, but it lasts only to the last reboot.

Is there any command using which I can assign/deassign shortcut so I can create some workaround script?

Thanks
Jano

Any ideas, David?

Does alt+h (or other affected shortcuts) work in other applications as accelerator for example? 

Like alt+h for the "Help" menu?

This is probably linked to Bug 405616 et. al. (FocusOut is a good keyword) and happens based on keyboard layout configuration. It is *very* easy to reproduce.

thanks for looking into this.

adding/removing another layout(`sk` in my case) creates/removes the issue.

when only us layout is present everything is working fine, after adding `sk` layout, but still `us` active some combination stops to work.

eg.

ALT+H, CTRL+H
probably everywhere - tested in chrome, pycharm, gimp.

*** Bug 405616 has been marked as a duplicate of this bug. ***

*** Bug 410806 has been marked as a duplicate of this bug. ***

I can't reproduce this on 5.22.

Layouts:
  - English (US)
  - English (India, with rupee)
  - Hindi (Bolnagri)

Tested:
  - xev
  - Firefox alt shortcuts
  - Dolphin alt shortcuts
  - Alt accelerator keys

All work. xev shows no incorrect FocusIn/Out events.

Is there anything else I need to do to reproduce this?

Can you check out Neon Unstable to see if it still happens? Thanks.

>Any ideas, David?

Not with what's given. xev didnt' show anything.

`xkbcli interactive-x11`

might hopefully say something useful

(In reply to Bharadwaj Raju from comment #18)
> I can't reproduce this on 5.22.
> 
> Layouts:
>   - English (US)
>   - English (India, with rupee)
>   - Hindi (Bolnagri)
> […]
> All work. xev shows no incorrect FocusIn/Out events.
> 
> Is there anything else I need to do to reproduce this?
> 
> Can you check out Neon Unstable to see if it still happens? Thanks.

It still happens on KDE Neon Unstable I downloaded today. It is heavily dependent on keyboard layout, which key combinations doesn't work. You can download a vdi image from the virtual machine I confirmed the bug with. The only custom thing I did aside from setting up the user on the installation was adding a layout. With the English(US) layout ctrl + z doesn't work anymore, with the other layout (de(bone)) ctrl+z (which translates to ctrl+f) doesn't work anymore. Killing kglobalaccl restores the shortcuts. I forwarded my usb keyboard to the virtualbox vm, so there is no interference with something from virtualbox.

https://mega.nz/file/bAxClbha#RGR9-fIV7THeUYP3oEkvr9bfksf7eLnhoJBd7Tr16Po

If you have problems with mega.nz I am willing to upload the file to another hoster.

This happens for me on Archlinux with plasma-desktop 5.26.4

$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us,ir
variant:    ,pes_keypad
options:    grp:shift_caps_toggle,caps:swapescape

$xev -event keyboard # and the press Alt+1
KeymapNotify event, serial 28, synthetic NO, window 0x0,
    keys:  79  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 28, synthetic NO, window 0x6200001,
    root 0x94f, subw 0x0, time 14062597, (-510,-104), root:(241,358),
    state 0x8, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

If it's known to be X11 only issue let's mark it as such, or provide more info

(In reply to Andrey from comment #22)
> If it's known to be X11 only issue let's mark it as such, or provide more
> info

The bug is also present on wayland.

What additional info do you need, I am very willing to provide needed information (i mean i even uploaded a vm image). There is lots of information on the two duplicate bugs 405616 and 410806. It also happens on 5.26.4 on tumbleweed.

It there any information on how global shortcuts gets registered and where? And do you have a clue on where and how the FocusOut events are generated? Some links or google keywords would be fine for me.

(In reply to Mohammad Hossein Sekhavat from comment #21)
> This happens for me on Archlinux with plasma-desktop 5.26.4
> 
> $ setxkbmap -query
> […]
> options:    grp:shift_caps_toggle,caps:swapescape
> […]

Out of curiosity, does this happen without grp:shift_caps_toggle and caps:swapescape? It might point us in the right direction.

(sorry for the two replies in rapid succession)

AFAIK Wayland has no kglobalaccel5 to kill, does the workaround with bind/unbind work there?

(In reply to Henning from comment #23)
> And do you have a clue on where and how the FocusOut events are generated?
That happens when shortcut get intercepted by system as Global shortcut, so the app has no chance to get it

(In reply to Andrey from comment #25)
> AFAIK Wayland has no kglobalaccel5 to kill, does the workaround with
> bind/unbind work there?

I just tried to reproduce it again to get some insight and I did not manage to reproduce it under wayland this time. I am very sure mid year this was still a bug on wayland. I tried it with setting Meta+Space as a keyboard layout switch, as well as Ctrl+Esc for "Show System Activity"[1]. So either I am totally wrong on the wayland side or there was a fix present. I'll check out an kubuntu 22.04. system in the comming days. Sorry about the confusion here.


[1] in ~/.config/kglobalshortcutsrc
"[kded5]
Show System Activity=Ctrl+Esc,[…]"