How to get System Settings to recognize the f23 part of copilot key(combo)

Help
,
1

Hi!

I have a Lenovo E16 Gen 2 AMD, which comes with the infamous “copilot key”.

While the kernel has evidently moved to correctly bind the full key combo it produces (meta + lshift + f23, and I have verified via sudo showkey that the correct key codes are being emitted: 125, 42, 193 ), the KDE system settings don’t seem to recognize the last part of it, only recognizing it as meta + shift. (Humorously enough, though, evidently the more underlying systems recognize that it isn’t just meta + shift because when I try to make a shortcut using the key, pressing meta and shift does trigger the shortcut but pressing the copilot key does not.)

I’ve already enabled “use F13-F24 as usual function keys” in keyboard>KeyBindings upon the advice of someone on the Fedora Discourse, but that doesn’t seem to have helped either as the shortcuts section still only recognizes the meta + lshift of it.

I just want to have the option to map the key to a useful shortcut, rather than having it be wasted space, and I’m hoping I won’t have to get into keyd or similar more advanced remapping daemons/software first.

I’m on Fedora KDE 42, Kernel 6.15.9, and Plasma version 6.4.4 (and KDE Frameworks version 6.17.0)

1 Like
2

(As discussed on the Fedora Discourse): I can replicate this behaviour using a QMK keyboard with individual keys mapped to Meta, Shift and F23. (i.e. no Copilot key, three individual keys emitting the relevant scancodes).

If I try to create a shortcut with Meta+Shift+F23, Plasma instead creates it as Meta+Shift.

But Meta+Shift+F13, Meta+Shift+F14, [etc], Meta+Shift+F22 and Meta+Shift+F24 are all accepted as valid shortcuts. It’s uniquely F23 that displays this behaviour.

Edit: Meta+F23 and Shift+F23 also work fine.

1 Like
3

Requires Frameworks 6.18, see Week in KDE Plasma from last week

2 Likes
4

Thanks!

On Frameworks 6.17, do you know why I can use Shift+F23 as a shortcut?

The code change in the linked article modifies the behaviour of “IsShiftAsModifierAllowed()”.

But it can’t be that Shift is currently unrecognised as a modifier in combination with F23, because Shift+F23 is an allowed shortcut. So is Meta+F23, so it’s somehow the three-way combination Meta+Shift+F23 that’s problematic on Frameworks 6.17.

(I should have mentioned that I’ve already enabled the option “Use F13-F24 as usual function keys".)

5

No idea, sorry.

I just remembered reading about the CoPilot key in a blog recently and then went looking for it :slight_smile:

6

Ah, I see! Unfortunately, looks like Fedora doesn’t ship 6.18 yet, so I shall have to wait until whenever that next shows up in an update to be able to finally use the copilot key as a shortcut.

7

Just to be precise, we need the code 125 (KEY_LEFTMETA)→code 42 (KEY_LEFTSHIFT)→code 193 (KEY_F23)to map to some other keycode. As you know from the Fedora Discussion thread, for me this would be code 97 (KEY_RIGHTCTRL). I would just like the right-ctrl key that was taken away and replaced by the Copilot key back. Just like any long time Emacs user would. :slight_smile:

8

I would just like the right-ctrl key that was taken away and replaced by the Copilot key back. Just like any long time Emacs user would.

I don’t know the thread but if you want to turn that Copilot key into Ctrl I suggest using any key remapper (xremap, inputmangler, input-remapper, evsieve, etc.) or perhaps modifiyng the scancode as described here: Map scancodes to keycodes - ArchWiki

9

What makes it awkward is that the Copilot key doesn’t have a dedicated scancode - it emits the chord Meta+Shift+F23.

So if you want to map it to Ctrl, you have problems like how to distinguish Copilot+C from Copilot+Shift+C. Both of those present themselves as Meta+Shift+F23+C, so how does the machine know whether it should output Ctrl+C or Ctrl+Shift+C?

I found this feature request for InputRemapper: [Feature Request] Sticky modifier (Hold modifier after press until next (non-modifier) key is pressed) · Issue #1127 · sezanzeb/input-remapper · GitHub

The issue author suggests some workarounds for this problem, which involve Copilot behaving not exactly like a normal Ctrl key.

For example, Copilot could be treated as “Sticky Control”, where to get Ctrl+C you hit Copilot followed by C; to get Ctrl+Shift+C you hit Copilot followed by Shift+C.

10

Hopefully a workaround solution will arrive that helps you, but I would still suggest contacting Lenovo and asking for a BIOS option that remaps the Copilot key.

I know one voice is just one voice, but Lenovo has been relatively Linux-friendly by the standards of laptop manufacturers. If they don’t get feedback that points out the issues caused on this occasion by implementing a hack that Microsoft dictated, they’ll think it’s OK to keep on doing so.

11

This is a good idea. I’ll see what it takes to follow up with them on it. Thanks!

1 Like
12

Done! Thanks again for that suggestion.

2 Likes
13

Update:
I just updated my laptop to KDE Frameworks 6.18.0 (Since Fedora recently released that update), and the f23 part of the key combo still does not appear to register in the keybinding part of the settings. It still only shows up as Meta+Shift

2 Likes
14

Thanks for posting this update on the situation! I continue to wish us luck getting this sorted out.

15

Yes, same for me - it’s the same in Frameworks 6.18.0 as it was in 6.17.0.

1 Like
16

No change between 6.17 to 6.18 for me either. Running wev |grep sym or xev |grep keysym in Wayland reports the Copilot key as Super_L + Shift_L + XF86Assistant, not XF86TouchpadOff.

1 Like
17

Update: after checking the xkeyboard-config release notes, I found they changed the default mapping for Super + Shift + F23 to XF86Assistant in version 2.44.

1 Like
18

For keys to be recognized properly handled in Qt/KDE applications, they need to be present in:

And Qt::Key_F23is already known.

And this is not simple to get, because Qt support oldish platforms, Redhat 8.6 released 3 years ago. Qt for Linux/X11 | Qt 6.10 .

So this XF86Assistant will take years to be there. Unless we go through some hoops.

You can see my attempts at adding other keys in Draft: input: add support for Pickup and Hangup keys (!7892) · Merge requests · Plasma / KWin · GitLab that have been stalled due to this.

There could be a workaround since the key here is a mixture Meta+Shift+F23, two modifiers plus a key.

1 Like
19

Can confirm after installing and using wev that my copilot key also shows up as having XF86Assistant, rather than F23 or the touchpad off. Which definitely explains why Frameworks 6.18 didn’t do anything for my issue… but based on meven’s response, seems like we’ll be waiting a good bit before the issue can actually be resolved

2 Likes
20

Ah yes - original RFE

The issue starts:

I can’t find the official specs for it but MS has decreed that the copilot key needs to send Win + Shift + F23 when the physical key is pressed down.

Saddening that a FOSS project feels like it has to accommodate the decree of a techcorp instead of following open standards.

1 Like