Remap So-Called "Copilot Key"?

I recently threw down for a new laptop, a Lenovo Yoga 7 2-in-1. The thing came with a subject Copilot key located where the Right-Cntl key should be. I’d like to remap this key back to Right-Cntl.

I don’t recall seeing anything about this in the machine’s BIOS setup, and I’ve done a bit of searching on the Web, but I’ve found nothing that I consider preferable as a means for doing this remapping.

It made me wonder if anyone in Fedora land has also encountered this, and has, perhaps, been thinking about the best way to handle this situation.

Thanks!

If you’re using GNOME, a setting in dconf database might be what you’re looking for. The setting only has effect on user level though. For that you can go to GNOME Tweaks → Keyboard → Additional Layout Options → Ctrl Position and identify one setting that might swap the function of the Copilot Key (Maybe Menu to Right Ctrl, depending on how the Copilot Key is recognized by Fedora).

Should be supported as kernel 6.14 added support for the copilot key. https://www.phoronix.com/news/Linux-6.14-Input

1 Like

Thanks to both of you for the info!

I’m running a fresh installation of f42 Plasma Edition, which in itself is a bit disorienting for me as I’ve never used the KDE DE in a dedicated way prior to now. I went into the Keyboard Settings and selected for the Model, “Generic | Generic 104-Key PC”. I didn’t think to look at what was prior to that, and the Anaconda install log isn’t much help to me in that regard.

At any rate, when I did that, I think I may have lost whatever the Copilot key was sending originally. I have no idea what I started out with at install time, but it was kicking me into some max zoom mode; it’s no longer doing that.

So far, I think I’m a bit stumped. I’d like to make that key the “Right Ctrl” key, if possible. Since the Keyboard Bindings settings doesn’t list the Copilot key, there’s no generic way to ask that this happen that is obvious to me. It’s all super vexing. :frowning:

Edit to add: I did a bit more Web searching while looking for something equivalent to xev for Wayland. I found something called evtest. When I fire that up and pick the event class for the keyboard I get this sequence when I press the Copilot key down:

Event: time 1755476674.827726, -------------- SYN_REPORT ------------
Event: time 1755476679.918740, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1755476679.918740, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1755476679.918740, -------------- SYN_REPORT ------------
Event: time 1755476679.920109, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1755476679.920109, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1755476679.920109, -------------- SYN_REPORT ------------
Event: time 1755476679.921293, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1755476679.921293, type 1 (EV_KEY), code 193 (KEY_F23), value 1

The sequence unwinds when I lift up and release the key.

All of that agrees with everything I’ve been reading on what the key sends, including that referred to in the comment:

So, I’m closer, but still not at the finish line. There is nothing in the default key binding set that I can find that allows this key to be pressed and send a key_rightctrl event.

I’m in the odd situation of being half-way there, but it not quite working properly yet.

On my Lenovo Thinkpad e16 gen2 AMD
sudo showkey spits out

keycode 125 press
keycode  42 press
keycode 193 press

(And then their subsequent release)
which indicates meta, lshift, and f23 respectively. So clearly the f23 part is being recognized at some level.

HOWEVER
KDE’s settings does not appear to recognize the f23 still, and only recognizes the meta+lshift portion of the copilot keypress. Even more humorously, when I bind something to the “copilot key”, it actually does not trigger with the copilot key, but does with normal meta+lshift. Truly, some interesting disconnect is happening here.

You could ask the KDE folks if that is supposed to work over at https://discuss.kde.org/

2 Likes

You can flip a setting for this (it’s accessed from the System Settings app >> Keyboard >> Key Bindings (at the top right of the window))

Checking that option does not actually fix the issue, unfortunately. The shortcuts section of System Settings still only claims to receive the meta+shift part.


image

Good point, I’ll ask over there.

Ah, there’s something weird here.

I’ve mapped my QMK keyboard so it can emit F13 through F24.

I can create shortcuts with Meta+Shift+F13, Meta+Shift+F14, … Meta+Shift+F24… except that F23, and F23 alone, does not work in such a shortcut. If I try to create it, it falls back to Meta+Shift like what you’re seeing.

It will be interesting to see what the KDE folks say about this.

Ooh, very interesting indeed. At least it’s not just me, and that meta+shift+f23 fails for people in general haha.

1 Like

Yes, and I (fortunately) don’t even have a Copilot key! I’m hitting actual Meta and Shift and F23 and I can reproduce the behaviour.

Relaying what was said over at KDE (at least for my issue):

Should be fixed in KDE Frameworks 6.18, but fedora only ships 6.17 atm.

2 Likes

I wonder if it could be forced as a bind on Xfce?

Iirc it can have more than one key specified, but I do something like this for a few keys:

xfconf-query --channel 'xfce4-keyboard-shortcuts' --property '/commands/custom/Super_L' --type 'string' --set 'xfce4-popup-whiskermenu' --create
xfconf-query --channel 'xfce4-keyboard-shortcuts' --property '/commands/custom/MonBrightnessDown' --type 'string' --set "backlight decr '10'" --create

It seems like /commands/custom/ could be the Copilot key or however Meta/Shift/F23 appears?

This sequence coincides exactly to what my mini-experiment with evtest yields. See the output I included in my previous post, and look the code given on each event line in the sequence shown.

I think the problem with this key is that it doesn’t have an associated keycode. Instead, vendors have tied it to the sequence that we’ve been discussing here.

The only thing that the kernel patch “solved” is overcoming the underlying issue that the "default keymap table in atkbd does not map scancode 0x6e (F23) ". Having the Copilot sequence sent at all was what this accomplished. Now it’s up to “userspace” to handle it from there. (Quotes from the web link given by @barryascott earlier in this thread.)

Right now, as far as I can tell there is no Copilot key recognized in the Fedora userspace. This is at a lower level than a DE, imo.

Edit to add: Okay, I’m revisiting that last statement as incorrect. So long as a DE makes it possible to bind multi-keycode sequences to a different keycode, and since F23 is now recognized with a keycode, then, yes, this would be easy to overcome in a DE and wouldn’t need to be defined at a more basic level. I was wrong on that one.

The key combination is already available (on up-to-date F42) to applications that can make use of it.

For example, here’s RSSGuardLite (a Flatpak app) allowing me to set it as a shortcut:
Screenshot_20250818_192809

I don’t think that could be possible if there was outstanding work needed in some Fedora component below the level of the DE.

Now, the version of Plasma currently in Fedora doesn’t let you use it for any of the shortcuts controlled by Plasma, but the fix has already been released by KDE upstream and should be available to us in the next update of Plasma in Fedora.

I don’t know what the corresponding situation is in GNOME.

At the individual app level, it depends. Many apps seem to ignore the existence of F13-F24, so they may not be able to use it without work (I had to try several before I found the one in the screenshot that did.)

1 Like

I should say that mapping it to Right Ctrl is likely to be more difficult than using it as a shortcut (or mapping it to some non-modifier key).

I don’t know all the detail, but as an example it seems awkward to make Copilot+Shift+C map to Ctrl+Shift+C.

The “underlying” chord that the computer sees there is Meta+Shift+F23+C, and it can’t tell that it should interpret that in this instance as Ctrl+Shift+C rather than Ctrl+C.

I guess the full circumstances for how this will play out are still to be determined. What I’m hoping for is to be able to map the three keycode sequence to a single one, keycode, evtest reports this as Event code 97 (KEY_RIGHTCTRL). Time will tell…

Thanks to everyone for their thoughts on this!

1 Like

keyd and other such tools can in theory accomplish what you’re looking for, although not sure how it’ll interact with trying to do rctrl + shift or rctrl + meta still.

Fortunately for me, all I’m really looking for is being able to map the copilot key to a shortcut for some application. Best of luck with your goals, though!

1 Like