Bug 502639 - Ability to rep-map Copilot key to something useful
Summary: Ability to rep-map Copilot key to something useful
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: input (other bugs)
Version First Reported In: 6.3.4
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-10 10:54 UTC by rapteon
Modified: 2025-09-22 14:24 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rapteon 2025-04-10 10:54:10 UTC
Mapping Microsoft Copilot key to Control key

The copilot key on Windows laptops has replaced the right control key on most laptops as of 2025.
However, the right control key still has its uses, especially in applications such as Virtualbox.
It would be nice to have the possibility of remapping the copilot key as the right control key using
the keybindings settings.
There are already quite a few remappings available for under the `Ctrl position`  dropdown in the keybindings
section.

SOFTWARE/OS VERSIONS
Gentoo: 2.17
KDE Plasma: 6.2.5
KDE Frameworks: 6.10.0
Qt: 6.8.2
Kernel version: 6.12.21 
macOS:
Comment 1 Nate Graham 2025-04-10 14:08:17 UTC
It's terrible, yes. I keep hoping the industry will come to its senses and reinstate the proper Control key.

It would be ideal if we could offer a way to re-map this key, yes — either by doing it ourselves, or by hooking into (presumably new) XKB functionality to do it.
Comment 2 rapteon 2025-04-11 09:17:37 UTC
Thanks for the quick reply Nathan.
How can I contribute a fix for this?
I can probably take a look at this if there are some docs for reference.
Comment 3 Wismill 2025-04-11 09:49:25 UTC
I think it is better tackled in xkeyboard-config. Please open a ticket at https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues with some  laptop pictures as evidence. 

Once we have a fix, anybody should be able to use it without waiting for the xkeyboard-config release, using a user configuration. Further info at: https://xkbcommon.org/doc/current/user-configuration.html.
Comment 4 Wismill 2025-04-11 09:54:47 UTC
Oh my, I now remember that the Copilot key sends in fact `Win + Shift + F23`, so it may not be that easy to remap using only XKB, because not all applications handle *consumed* modifiers correctly (e.g. they will still see Win+Shift in addition to the expected Control).

So either Plasma handles it, or you may be better served with remapping tools, e.g. keyd, KMonad or Kanata.
Comment 5 Ali 2025-05-19 07:25:57 UTC
+1, Might not be the most useful but I think the F23 bit of what the copilot key sends is what blocks it from being easily remappable, the keyboard preview in settings correctly sees the copilot key as being Meta+Shift, but it seemingly isn't aware of F23, and nor is Kwin when mapping to the key, as it sees it as meta+shift, but then pressing the copilot key doesn't active the shortcut, while manually pressing meta+shift does.

Now I can't actually verify the F23 thing as online keyboard testers nor does KDE's own keyboard preview see the key (and I bought my machine with no OS), but I assume the kernel being able to recognize it (AFAIK it's a part of 6.14, https://www.theregister.com/2025/01/24/copilot_key_linux/) is why KWin can partially recognise it but can't activate any shortcut due to F23 being pressed, thus making it a different key combination from Meta+Shift.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Manufacturer: LENOVO
System Version: ThinkPad E14 Gen 6
Comment 6 Wismill 2025-05-19 07:48:04 UTC
(In reply to Ali from comment #5)
> +1, Might not be the most useful but I think the F23 bit of what the copilot
> key sends is what blocks it from being easily remappable, the keyboard
> preview in settings correctly sees the copilot key as being Meta+Shift, but
> it seemingly isn't aware of F23, and nor is Kwin when mapping to the key, as
> it sees it as meta+shift, but then pressing the copilot key doesn't active
> the shortcut, while manually pressing meta+shift does.

It sounds like this issue: https://bugs.kde.org/show_bug.cgi?id=461207#c6.
Comment 7 Ali 2025-06-12 09:37:29 UTC
After testing out a live image of Fedora Workstation aka GNOME, GNOME seems to see the copilot key as "Meta+Shift+Touchpad Disable" (assuming F23 is seen as "Touchpad Disable"), which while being awkwardly named, does fully function! and is indeed fully remappable. (and obvs it doesn't seem to disable the touchpad, lol)

Maybe the key is to see whatever GNOME / Mutter is doing ?
Comment 8 Ali 2025-09-22 14:24:39 UTC
Still occurs with KF6.18, on Plasma 6.4.5 on Fedora 42, despite https://invent.kde.org/frameworks/kguiaddons/-/commit/7766cb763162acf7622712bb6b99795335bfdd09 being shipped in KF6.18.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.7-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × Intel® Core™ Ultra 7 155H
Memory: 32 GiB of RAM (30.8 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: LENOVO
Product Name: 21M70024GR
System Version: ThinkPad E14 Gen 6