Can confirm on

Can confirm on Arch linux using the latest plasma version.

I can confirm this is still an issue on:

KDE Plasma Version: 5.18.3
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.1
Kernel Version 4.15.0-91-generic
OS Type: 64-bit

Can confirm is still an issue on: 

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-46-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 7.7 GiB of RAM

Hello, still an issue.

Operating System: KDE neon 5.19
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.0
Kernel Version: 5.4.0-48-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.5 Gio of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

Little debug with xev show :

1) When CTRL+< used ( i use it to open/close Yakuake )  CTRL+z don't work :
KeyPress event, serial 38, synthetic NO, window 0x9400001,
    root 0x5e2, subw 0x0, time 12892037, (-764,142), root:(1067,609),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 38, synthetic NO, window 0x9400001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 38, synthetic NO, window 0x9400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 38, synthetic NO, window 0x0,
    keys:  4294967266 0   0   2   32  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   0   0   

KeyRelease event, serial 38, synthetic NO, window 0x9400001,
    root 0x5e2, subw 0x0, time 12893053, (-764,142), root:(1067,609),
    state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) "▒"
    XFilterEvent returns: False


2) When CTRL+< not used, so CTRL+z work 
KeyPress event, serial 38, synthetic NO, window 0xa600001,
    root 0x5e2, subw 0x0, time 12970143, (-248,-17), root:(1583,450),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0xa600001,
    root 0x5e2, subw 0x0, time 12970471, (-248,-17), root:(1583,450),
    state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) "▒"
    XmbLookupString gives 1 bytes: (1a) "▒"
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0xa600001,
    root 0x5e2, subw 0x0, time 12970559, (-248,-17), root:(1583,450),
    state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (1a) "▒"
    XFilterEvent returns: False

Also caused by Ctrl+« and Alt+«, but not Ctrl+» (which is Ctrl+Shift+«) or Alt+» (which is Alt+Shift+«).
Using portuguese (portugal) layout, keyboard model="Generic 105-key PC"

Do any of you have multiple keyboard layouts applied, or just one?

Created attachment 136875 [details]
attachment-32376-0.html

Hi,

Yes, I will have had two keyboard layouts configured to switch between.

On Sat, 20 Mar 2021, 02:41 Nate Graham, <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=402028
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |nate@kde.org
>
> --- Comment #7 from Nate Graham <nate@kde.org> ---
> Do any of you have multiple keyboard layouts applied, or just one?
>
> --
> You are receiving this mail because:
> You reported the bug.

(In reply to Nate Graham from comment #7)
> Do any of you have multiple keyboard layouts applied, or just one?

Hi Nate :) I have just one

Thanks. And which layout do you have? en_us, or different one(s)? If it's not en_us, does the problem reproduce when using en_us?

(In reply to Nate Graham from comment #10)
> Thanks. And which layout do you have? en_us, or different one(s)? If it's
> not en_us, does the problem reproduce when using en_us?

Interesting: I'm using pt_pt, when switching to en_us I can assign the Ctrl+< shortcut to something, though when I press it, nothing happens; but Ctrl+Z and Ctrl+X remain functional.
However, Ctrl+> does function, and still Ctrl+Z and Ctrl+X work normally.
Very strange indeed...

Seems like the shortcuts are using the keys for an en_us layout even when the layout is changed to something else.

Created attachment 136892 [details]
attachment-22305-0.html

Hi Nate,

I only have one layout now (will have had en_gb and en_gb colemak when I
originally opened this issue) and the issue still persists. I only have
en_gb at the moment.

Ashley Summers


On Sat, Mar 20, 2021 at 4:31 PM Nate Graham <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=402028
>
> --- Comment #10 from Nate Graham <nate@kde.org> ---
> Thanks. And which layout do you have? en_us, or different one(s)? If it's
> not
> en_us, does the problem reproduce when using en_us?
>
> --
> You are receiving this mail because:
> You reported the bug.

Also,

I've just tested using "English (US)" and the issue persists for me using that layout too.

Ash

Well that's strange. Hard to find a pattern. :/

Created attachment 136907 [details]
attachment-16953-0.html

Hi Nate,

Are you not able to reproduce the issue? There's actually two of us in the
same office which have experienced this issue, using different brands of
laptop. I believe we will both have keyboards which are British QWERTY, if
that perhaps makes the difference? Anything I can do to help please let me
know.

On Sun, 21 Mar 2021, 03:33 Nate Graham, <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=402028
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>             Summary|Setting shortcut keys to    |Setting shortcut keys to
>                    |Ctrl+< or Ctrl+> breaks     |Ctrl+< or Ctrl+> breaks
>                    |shortcuts for Ctrl+Z &      |shortcuts for Ctrl+Z &
>                    |Ctrl+X when using a         |Ctrl+X
>                    |keyboard layout that's not  |
>                    |en_us                       |
>
> --- Comment #15 from Nate Graham <nate@kde.org> ---
> Well that's strange. Hard to find a pattern. :/
>
> --
> You are receiving this mail because:
> You reported the bug.

No, I cannot reproduce.

(In reply to yannux from comment #5)
> Hello, still an issue.
> 
> Operating System: KDE neon 5.19
> KDE Plasma Version: 5.19.5
> KDE Frameworks Version: 5.74.0
> Qt Version: 5.15.0
> Kernel Version: 5.4.0-48-generic
> OS Type: 64-bit
> Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
> Memory: 15.5 Gio of RAM
> Graphics Processor: Mesa Intel® UHD Graphics 620
> 
> Little debug with xev show :
> 
> 1) When CTRL+< used ( i use it to open/close Yakuake )  CTRL+z don't work :
> KeyPress event, serial 38, synthetic NO, window 0x9400001,
>     root 0x5e2, subw 0x0, time 12892037, (-764,142), root:(1067,609),
>     state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> FocusOut event, serial 38, synthetic NO, window 0x9400001,
>     mode NotifyGrab, detail NotifyAncestor
> 
> FocusIn event, serial 38, synthetic NO, window 0x9400001,
>     mode NotifyUngrab, detail NotifyAncestor
> 
> KeymapNotify event, serial 38, synthetic NO, window 0x0,
>     keys:  4294967266 0   0   2   32  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   0   0   
> 
> KeyRelease event, serial 38, synthetic NO, window 0x9400001,
>     root 0x5e2, subw 0x0, time 12893053, (-764,142), root:(1067,609),
>     state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
>     XLookupString gives 1 bytes: (1a) "▒"
>     XFilterEvent returns: False
> 
> 
> 2) When CTRL+< not used, so CTRL+z work 
> KeyPress event, serial 38, synthetic NO, window 0xa600001,
>     root 0x5e2, subw 0x0, time 12970143, (-248,-17), root:(1583,450),
>     state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> KeyPress event, serial 38, synthetic NO, window 0xa600001,
>     root 0x5e2, subw 0x0, time 12970471, (-248,-17), root:(1583,450),
>     state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
>     XLookupString gives 1 bytes: (1a) "▒"
>     XmbLookupString gives 1 bytes: (1a) "▒"
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 38, synthetic NO, window 0xa600001,
>     root 0x5e2, subw 0x0, time 12970559, (-248,-17), root:(1583,450),
>     state 0x14, keycode 25 (keysym 0x7a, z), same_screen YES,
>     XLookupString gives 1 bytes: (1a) "▒"
>     XFilterEvent returns: False

(In reply to Nate Graham from comment #7)
> Do any of you have multiple keyboard layouts applied, or just one?


I was able to make it work good by choosing "French (alt., with Sund dead keys)" as variant, maybe it was not a bug for me, just bad configuration.

Here is my conf working  :
- Hardware -> Keyboard Model : Generic | Generic 105-key PC(intl.)
- Dispositon : french with wariant French (alt., with Sund dead keys)

Hmm I wonder if everyone else is having the same issue...

(In reply to Nate Graham from comment #19)
> Hmm I wonder if everyone else is having the same issue...

I confirm the same issue on Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-73-generic

Steps to reproduce for me:
1. I had "pl" and "gr" layouts and custom shortcuts Ctrl+> and Ctrl+<. No problems in this config.
2. Installed italian "it" layout. Now Ctrl+z and Ctrl+x are dead regardless of which layout is selected.

Notes:
1) after removing the shortcuts Ctrl+> and Ctrl+< the Ctrl+z and Ctrl+x are functional again
2) while in the °it° layout, pressing keyboard keys Shift+> yields ":" as it should. However, pressing Ctrl+Shift+> activates the action assigned to the shortcut Ctrl+>, which it should not.
3) when previewing the "it" layout, I see the arrows < > appearing in the top-right corner of the keyboard keys for the letters "z" and "x" respectively. Not directly connected to the issue, but this is the only way I can link "z" and "x" to the arrows "<" and ">".
4) All layouts in default variant.

I can confirm this is annoying since a while already.
I thought it was fixed 2 months ago but then it came back after update.

My setup:
  kde-frameworks/plasma-5.92.0-r2
  kde-frameworks/frameworkintegration-5.92.0
  dev-qt/qtcore-5.15.3
  kernel-5.15.11

I was about to go crazy about this one.
I was searching all over the internet of a way to fix my CTRL+Z shortcut and i just couldn't... tried everything.
I just stumble on this bug by chance and give it a try and it turns out it was my calculator shortcut - CTRL+< - that was causing the trouble.

Please fix this!

DE: KDE Plasma 5.27.3
WM: KWin (X11)
Kernel: 6.2.8-zen1-1-zen
Keyboard layout: Turkish QWERTY (Standard)


Can confirm the bug still exist  in latest KDE version and Turkish QWERTY layout. it is extra annoying because "<" is the closest letter/button to the left control so it is a very convenient shortcut.

Experiencing the same issue with ctrl+shift for language switching, on latest neon. However, this ppa fixes it if you are using x11: https://launchpad.net/%7Enrbrtx/+archive/ubuntu/xorg-hotkeys

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

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