Bug 457378 - Invocation of kwin remaps the meta button.
Summary: Invocation of kwin remaps the meta button.
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.3
Platform: Fedora RPMs Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-01 15:20 UTC by Roke Julian Lockhart Beedell
Modified: 2022-11-29 16:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
Depiction of what kwin appears as. (25.61 KB, image/png)
2022-08-01 15:20 UTC, Roke Julian Lockhart Beedell 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Roke Julian Lockhart Beedell 2022-08-01 15:20:31 UTC 
Created attachment 151049 [details]
Depiction of what kwin appears as.

STEPS TO REPRODUCE
1. Invoke kwin.

OBSERVED RESULT
The meta button is remapped. This means that I am unable to snap windows. However, this resets if the computer is reinitialized.

EXPECTED RESULT
kwin should not unexpectedly remap keys.

SOFTWARE/OS VERSIONS
Windows: Unaffected.
macOS: Unaffected.
Linux/KDE Plasma: Affected.
KDE Plasma Version: “5.25.3”.
KDE Frameworks Version: “5.96.0”.
Qt Version: “5.15.5”.

Additional Information:
keyup    keyCode=40  (()   which=40  (()   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=ArrowDown char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined
keydown  keyCode=37  (%)   which=37  (%)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=ArrowLeft char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined
keyup    keyCode=37  (%)   which=37  (%)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=ArrowLeft char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined
keydown  keyCode=39  (')   which=39  (')   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=ArrowRight char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined
keyup    keyCode=39  (')   which=39  (')   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=ArrowRight char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined
keyup    keyCode=91  ([)   which=91  ([)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=OS char=undefined location=1 repeat=false
         keyIdentifier=undefined keyLocation=undefined
Comment 1 Roke Julian Lockhart Beedell 2022-08-01 15:37:57 UTC 
Additionally, it prevents operation of Alt + Tab.
Comment 2 Nate Graham 2022-08-01 16:25:05 UTC 
When you run a nested KWin, it grabs input when it has focus. This is intended, or else you couldn't use those keys within it.
Comment 3 Roke Julian Lockhart Beedell 2022-11-29 14:01:11 UTC 
(In reply to Nate Graham from comment #2)
> When you run a nested KWin, it grabs input when it has focus. This is
> intended, or else you couldn't use those keys within it.

However, it appears to remain even after I have closed the window. Does it continue to operate in the background?
Comment 4 Nate Graham 2022-11-29 16:27:40 UTC 
I don't know, you tell me. :) Does it? What does `ps -e | grep -i kwin_wayand` show?