Remapping Windows copilot key...

[baybal]

It seems that windows copilot key does not emit a single keycode, but is hardcoded in laptop EC to emit a key combo in a rapid succession. How do we tackle the task of remapping that?

[nsbgn]

Would something like this work?

[main]
firstkey = timeout(layer(second), 5, firstkey)

[second]
secondkey = timeout(layer(final), 5, secondkey)

#...etcetera

[final]
finalkey = remappedkey

[susnux]

Same question, as pressing the key emits "left meta down"+"left shift down". Best case: Remap to CTRL key

[susnux]

So for me this is somewhat working¹

[ids]

*

[main]

leftmeta = layer(copilot)

[copilot]

leftshift = rightcontrol

The problem here is: Pressing "Copilot"+left shift+T is not opening a tab as the left shift is not recognized as it is part of the copilot key...

[nsbgn]

What is the output of keyd monitor -t (while keyd itself is not running!) when you press the copilot key in isolation, and then later together with leftshift and t?

[susnux]

What is the output of keyd monitor -t (while keyd itself is not running!) when you press the copilot key in isolation,

+2473 ms        AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
+2 ms   AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
+146 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up
+9 ms   AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta up

and then later together with leftshift and t?

Without keyd: copilot + leftshift + t

+1497 ms        AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
+3 ms   AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
+1086 ms        AT Translated Set 2 keyboard    0001:0001:a38e6885      t down
+169 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      t up
+100 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up

copilot + rightshift + t

+3995 ms        AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
+2 ms   AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
+474 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      rightshift down
+476 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      t down
+162 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      t up
+243 ms AT Translated Set 2 keyboard    0001:0001:a38e6885      rightshift up
+45 ms  AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up
+13 ms  AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta up

With the keyd config as mentioned: copilot + left shift + t

+2570 ms        keyd virtual keyboard   0fac:0ade:efba1ddf      rightcontrol down
+1350 ms        keyd virtual keyboard   0fac:0ade:efba1ddf      t down
+305 ms keyd virtual keyboard   0fac:0ade:efba1ddf      t up
+123 ms keyd virtual keyboard   0fac:0ade:efba1ddf      rightcontrol up

[susnux]

But I also noticed: When keyd is enabled, then both the left and the right shift will be listed as "leftshift".

[nsbgn]

Ah, I see, thanks! I'm not sure that the following will solve the shift problem, but it's worth a try:

[ids]
*

[global]
chord_timeout = 10

[main]
leftmeta+leftshift = layer(control)

both the left and the right shift will be listed as "leftshift".

Yes, this a known limitation; see #114 (and subsequent issues) for more information. I do think there is a case to be made for changing this.

[kepiz]

Ah, I see, thanks! I'm not sure that the following will solve the shift problem, but it's worth a try:

[ids]
*

[global]
chord_timeout = 10

[main]
leftmeta+leftshift = layer(control)

both the left and the right shift will be listed as "leftshift".

Yes, this a known limitation; see #114 (and subsequent issues) for more information. I do think there is a case to be made for changing this.

Hey having a similar problem with copilot keyboard here this is my config:

[ids]

*

[main]
leftmeta+leftshift+f23 = layer(control)

leftmeta = layer(copilot)

but when pressing DOWN the copilot key I get a release, but I just want the ctrl to be held down when I press it down, this is my output when monitoring:

+2698 ms        keyd virtual keyboard   0fac:0ade:efba1ddf      leftcontrol down
+16 ms  keyd virtual keyboard   0fac:0ade:efba1ddf      leftcontrol up

[nsbgn]

Are you trying to achieve the same thing as the others? If not, it may merit a separate issue.

But if you are, could you try thr condig I posted earlier, without the +f23? And could you also answer the questions that @susnux answered?

To be clear, I do not have a keyboard with a Copilot key, so I am just guessing.

[kepiz]

Ok will post that later. All I'm trying to do is when I hold copilot key, control key should be held. Currently when I hold copilot, it triggers ctrl down and up as you can see in the monitor log

[JamiKettunen]

On my HP OmniBook X 14 (one of the new Snapdragon X Elite laptops) paying attention to the keyd monitor -t output:

1. when you press the copilot key in my case any other modifiers that may be in progress are immediately reset back to up state and then it performs leftmeta+leftshift+f23

+2220 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      rightalt down
+2089 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta down
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      rightalt up
+54 ms  hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift down
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      f23 down
+4042 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      f23 up
+48 ms  hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift up
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta up

2. to add insult to injury if you hold the copilot key first and then press something else it just releases leftmeta+leftshift+f23 before the key down event for whatever other key you may have pressed happens

+3262 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta down
+53 ms  hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift down
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      f23 down
+1075 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift up
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta up
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      f23 up
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      m down
+3587 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      m up
+1852 ms        hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift down
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta down
+49 ms  hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftshift up
+0 ms   hid-over-i2c 0416:C300 Keyboard 0416:c300:980fd792      leftmeta up

[kepiz]

Yeah in my case it is the same I don't how to stop the up call that happens after 16ms

[susnux]

but it's worth a try:

Thank you @nsbgn this is almost what I wanted, thank you! So copilot + right shift works perfect, copilot + leftshift does not work as the "second leftshift" is ignored by keyd.

BTW using evtest it looks like this if I press copilot + leftshift, so the second leftshift is registered:

Event: time 1731588591.286355, -------------- SYN_REPORT ------------
Event: time 1731588598.918855, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1731588598.918855, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1731588598.918855, -------------- SYN_REPORT ------------
Event: time 1731588598.923010, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1731588598.923010, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1731588598.923010, -------------- SYN_REPORT ------------
Event: time 1731588598.926031, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1731588598.926031, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1731588598.926031, -------------- SYN_REPORT ------------
Event: time 1731588601.172246, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1731588601.172246, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 2
Event: time 1731588601.172246, -------------- SYN_REPORT ------------
Event: time 1731588610.921930, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1731588610.921930, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1731588610.921930, -------------- SYN_REPORT ------------
Event: time 1731588610.928243, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1731588610.928243, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1731588610.928243, -------------- SYN_REPORT ------------
Event: time 1731588610.936366, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1731588610.936366, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0

[nsbgn]

Thanks for your inputs!

It seems we have at least 2 different variants of Copilot key --- one with the weird f23 and keyup behaviours (@kepiz and @JamiKettunen) and one without (@susnux).

Without f23/keyup

This seems to work with the exception of combinations with leftmeta/leftshift, right? I imagine this could be addressed within keyd: keydown of a keycode that is already in keydown state should nevertheless be registered. @rvaiya might you accept a patch for this if someone writes it?

With f23/keyup

This situation is more unfortunate. It's a hardware issue. I think we can try to work around it as best we can.

to add insult to injury if you hold the copilot key first and then press something else it just releases leftmeta+leftshift+f23 before the key down event for whatever other key you may have pressed happens

We should be able to use a oneshot here to keep the control active for at least the next keypress. I see that the time between leftmeta down and leftshift down can be fairly long, so I set the chord_timeout accordingly. The downside of this method is that you won't be able to perform multiple control-shortcuts while holding the Copilot key --- I don't see a way around that.

[global]
chord_timeout = 65

[copilot:C]

[main]
leftmeta+leftshift+f23 = oneshot(copilot)

when you press the copilot key in my case any other modifiers that may be in progress are immediately reset back to up state and then it performs leftmeta+leftshift+f23

Alright, adding other modifiers gets complicated. Does something like the following work, or would the intermittent keyup of the modifier mess up the chord?

[global]
chord_timeout = 65

[copilotaltgr:C-G]
[copilotalt:C-A]
[copilotmeta:C-M]
[copilotshift:C-S]

[copilot:C]
leftalt = oneshot(copilotalt)
rightalt = oneshot(copilotaltgr)
leftmeta = oneshot(copilotmeta)
rightmeta = oneshot(copilotmeta)

[altgr:G]
leftmeta+leftshift+f23 = oneshot(copilotaltgr)
[meta:M]
leftmeta+leftshift+f23 = oneshot(copilotmeta)
[alt:A]
leftmeta+leftshift+f23 = oneshot(copilotalt)

[main]
leftmeta+leftshift+f23 = oneshot(copilot)

Of course I can't test this --- hopefully it helps.

[iostapyshyn]

On some systems F23 is yet missing and keyd just recognizes leftmeta+leftshift. This is due to the atkbd driver not mapping the 0x6e scancode for F23. On ThinkPad P14s Gen 5, evtest shows:

Event: time 1731707538.266067, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1731707538.266067, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1731707538.266067, -------------- SYN_REPORT ------------
Event: time 1731707538.266103, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1731707538.266103, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1731707538.266103, -------------- SYN_REPORT ------------
Event: time 1731707538.266215, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1731707538.266215, -------------- SYN_REPORT ------------
Event: time 1731707538.337827, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1731707538.337827, -------------- SYN_REPORT ------------
Event: time 1731707538.337862, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1731707538.337862, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1731707538.337862, -------------- SYN_REPORT ------------
Event: time 1731707538.338031, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1731707538.338031, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1731707538.338031, -------------- SYN_REPORT ------------

As there is no key event for the unmapped scancode, it is not picked up by keyd. At the same time, in the kernel log:

[ 5590.779099] atkbd serio0: Unknown key pressed (translated set 2, code 0x6e on isa0060/serio0).
[ 5590.779116] atkbd serio0: Use 'setkeycodes 6e <keycode>' to make it known.

setkeycodes 6e 193 maps the key to F23, but in the long run the missing mapping should probably be added to the udev hardware database.

[nsbgn]

Thanks @iostapyshyn, that makes a lot of sense! Though there is another (more consequential) disparity --- in @susnux's case, leftshift+leftmeta seems to be held until the key is released, whereas for @JamiKettunen leftshift+leftmeta+f23 is released as soon as another key is pressed (which I assume is an artefact of rollover).

[susnux]

@iostapyshyn yes I had to add it to the hwdb config file, then it is also shift+meta+f23 in my case.

[mishoo]

In my case (ASUS Vivobook S), without keyd running, keyd monitor reports the following:

1. Press and then release Copilot key:

AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta up

2. Press and hold Copilot, press left Shift, release left Shift, release Copilot:

AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up

This is weird.. There is no leftshift down event when I press left Shift (presumably since it was already "down" by holding Copilot). But there is a leftshift up when I release left Shift, and then there is no leftmeta up event when I finally release Copilot. This effectively locks leftmeta as being down, and I can now use various key bindings that involve meta without holding it. To unlock it I have to press/release Copilot once more.

Using leftshift+leftmeta = layer(control) in keyd config for now, it's almost bearable, but I can't use any bindings that involve Copilot (rightcontrol, really) and leftshift, which kinda sucks.. How could hardware companies uniformly screw up so bad is beyond me. They just hate people, I guess.

[baybal]

In my case (ASUS Vivobook S), without keyd running, keyd monitor reports the following:

1. Press and then release Copilot key:

AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta up

2. Press and hold Copilot, press left Shift, release left Shift, release Copilot:

AT Translated Set 2 keyboard    0001:0001:a38e6885      leftmeta down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift down
AT Translated Set 2 keyboard    0001:0001:a38e6885      leftshift up

This is weird.. There is no leftshift down event when I press left Shift (presumably since it was already "down" by holding Copilot). But there is a leftshift up when I release left Shift, and then there is no leftmeta up event when I finally release Copilot. This effectively locks leftmeta as being down, and I can now use various key bindings that involve meta without holding it. To unlock it I have to press/release Copilot once more.

Using leftshift+leftmeta = layer(control) in keyd config for now, it's almost bearable, but I can't use any bindings that involve Copilot (rightcontrol, really) and leftshift, which kinda sucks.. How could hardware companies uniformly screw up so bad is beyond me. They just hate people, I guess.

I have a fleeing suspicion that Microsoft made this to make getting rid of copilot as hard as possible.

[mishoo]

On further digging, seems my laptop too emits a scancode for F23, but it's just ignored. To make it trigger the correct key code I need to run setkeycodes 6e 193 first (from reddit). The good news is that now I do get an F23 up event if I happen to use LeftShift while the cursed key is held. Without any keyboard remappers running, here is the output of evtest when I press Copilot, press LeftShift, then depress LeftShift then depress Copilot:

*** Press Copilot
Event: time 1732351589.165922, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1732351589.165922, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1732351589.165922, -------------- SYN_REPORT ------------
Event: time 1732351589.167291, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1732351589.167291, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1732351589.167291, -------------- SYN_REPORT ------------
Event: time 1732351589.168745, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1732351589.168745, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1732351589.168745, -------------- SYN_REPORT ------------

*** Press LeftShift
Event: time 1732351593.485597, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1732351593.485597, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 2    *** VALUE: 2 ***
Event: time 1732351593.485597, -------------- SYN_REPORT ------------

*** Depress LeftShift
Event: time 1732351597.762200, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1732351597.762200, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1732351597.762200, -------------- SYN_REPORT ------------

*** Depress Copilot
Event: time 1732351601.733048, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1732351601.733048, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1732351601.733048, -------------- SYN_REPORT ------------

Given this, I think it should be possible to exorcise this key and make it a proper Control, although not doable from the config alone. First, in order to get LeftShift down event while Copilot is being held, I had to change these lines:

if (ev.value == 2) {
	if (ev.code == KEYD_LEFTSHIFT || ev.code == KEYD_LEFTMETA)
		ev.value = 1;
	else
		return NULL;
}

(because when pressing LeftShift or LeftMeta while copilot is held, we receive an event with value = 2).

After this change, for the sequence ↓Copilot, ↓LeftShift, ↑LeftShift, ↑Copilot I get the following from keyd monitor:

AT Translated Set 2 keyboard    0001:0001:70533846      leftmeta down
AT Translated Set 2 keyboard    0001:0001:70533846      leftshift down
AT Translated Set 2 keyboard    0001:0001:70533846      f23 down
AT Translated Set 2 keyboard    0001:0001:70533846      leftshift down
AT Translated Set 2 keyboard    0001:0001:70533846      leftshift up
AT Translated Set 2 keyboard    0001:0001:70533846      f23 up

[!NOTE] It's worth repeating that there is no leftmeta up event above; without any key remappers active, pressing LeftShift while holding Copilot will lock LeftMeta as being down. This seems a hardware bug and I'd be interested to know how it behaves in Windows (I wish I had Windows just for testing this!)

Something similar happens when I use LeftMeta instead of LeftShift:

AT Translated Set 2 keyboard    0001:0001:70533846      leftmeta down
AT Translated Set 2 keyboard    0001:0001:70533846      leftshift down
AT Translated Set 2 keyboard    0001:0001:70533846      f23 down
AT Translated Set 2 keyboard    0001:0001:70533846      leftmeta down
AT Translated Set 2 keyboard    0001:0001:70533846      leftmeta down
[... unlike Shift, this one repeats ...]
AT Translated Set 2 keyboard    0001:0001:70533846      leftmeta up
AT Translated Set 2 keyboard    0001:0001:70533846      f23 up
AT Translated Set 2 keyboard    0001:0001:70533846      leftshift up

The problem I don't know how to solve is the discrepancy between the activation and deactivation events. We'd need to turn leftmeta down + leftshift down + f23 down into control down - that's easy, but then we need to turn f23 up or f23 up + leftshift up into control up.

Seems to be such a contrived mess that instead of adding support for up/down hooks in the configuration, perhaps a better way would be to just have a global "kill_copilot" option...

[mishoo]

Should anyone care, I wrote my own little tool; I couldn't get combinations (involving left shift or left meta) working otherwise: https://github.com/mishoo/exorcise-copilot

It would be nice to have it as an option built into keyd.

[rvaiya]

Apologies for the slow response, I have been dealing with a few personal issues.

@nsbgn

As usual, thank you for neatly distilling the issue :).

This seems to work with the exception of combinations with leftmeta/leftshift, right? I imagine this could be addressed within keyd: keydown of a keycode that is already in keydown state should nevertheless be registered. @rvaiya might you accept a patch for this if someone writes it?

The problem is that there is no way to distinguish between leftshift emitted by the left shift key and the one emitted by the copilot key. A release of the former will count towards a partial release of the chord (which under normal circumstances makes sense). Most sane keyboards associate a single physical key with each keycode, so this is a fairly niche case.

It looks like there is some discussion of fixing this at the kernel level (which feels like the correct place to fix it), so you may want to keep an eye on that. It is possible that updating your system at some point might make this mess go away, though I doubt there is any hope for the f23 gymnastics microsoft does in the second case.

With f23/keyup This situation is more unfortunate. It's a hardware issue. I think we can try to work around it as best we can.

I agree that this is mostly hopeless :P. You have probably outlined the best mitigations currently possible with keyd, but I personally wouldn't even bother given the number of edge cases.

---

@mishoo

Excellent work. Your logs provide valuable insight into microsoft's depravity.

First, in order to get LeftShift down event while Copilot is being held, I had to change these lines:

The problem here is that repeat events generated by the kernel also set the value to 2. It is not actually an indication of how many times the key has been pressed (if you hold any key it will continually emit evdev events with a value of 2). Changing this potentially has a number of unwanted side effects and can't reliably be used to establish whether or not multiple physical keys have actually been pressed.

It's worth repeating that there is no leftmeta up event above; without any key remappers active, pressing LeftShift while holding Copilot will lock LeftMeta as being down. This seems a hardware bug and I'd be interested to know how it behaves in Windows (I wish I had Windows just for testing this!)

Pure evil!

Should anyone care, I wrote my own little tool It would be nice to have it as an option built into keyd.

Nice work. I've only skimmed it, but from what I can tell it doesn't (/can't) solve the fundamental hardware limitation you described earlier.

Unfortunately, I am not inclined to add similar logic to keyd given the number of potentially pathological outcomes when combined with other features. Please correct me if I have misunderstood something, and I will happily take another look.

I am going to close this for now, as I am currently trying to work through the issue backlog.

[mishoo]

@rvaiya Indeed, the best place to fix it would be in the kernel (though I'm not sure the hardware idiosyncrasy can be worked around, even at that level). Nice to know it's got some attention.

Unfortunately, I am not inclined to add similar logic to keyd given the number of potentially pathological outcomes when combined with other features.

That's understandable, it's too contrived. I can live with my little hack until the kernel does something about it.

[temach]

Just wanted to add that on Lenovo Yoga Pro 7i (14'', Gen 9) the copilot key emits leftmeta + leftshift + f23 however using the following config it emits control (and allows for multiple keypresses with control pressed)

[ids]
*

[main]
capslock = layer(control)
leftmeta+leftshift+f23 = layer(control)

For me this works well enough! I can do multiple CTRL-key keypresses while holding down copilot key (I do not have the problem of immediate key release).

But there is also weird behavior when pressing shiftkey while holding down copilot - I press shift once and it does not show up, but when pressing it twice or more shift key shows up (as if the control layer does not get cleared after key up of copilot key).

In this log I press the following keys in order (I separate the steps with ORBIT BT5.0 MOUSE clicks for readability):

1. copilot key
2. hold copilot key + press shift, release everything
3. repeat step 2
4. and repeat step 2 again

~$ sudo keyd monitor
keyd virtual keyboard	0fac:0ade:efba1ddf	enter up
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse up
keyd virtual keyboard	0fac:0ade:efba1ddf	leftcontrol down
keyd virtual keyboard	0fac:0ade:efba1ddf	leftcontrol up
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse up
keyd virtual keyboard	0fac:0ade:efba1ddf	leftcontrol down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse up
keyd virtual keyboard	0fac:0ade:efba1ddf	leftshift down
keyd virtual keyboard	0fac:0ade:efba1ddf	f23 down
keyd virtual keyboard	0fac:0ade:efba1ddf	leftshift up
keyd virtual keyboard	0fac:0ade:efba1ddf	f23 up
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse up
keyd virtual keyboard	0fac:0ade:efba1ddf	leftshift down
keyd virtual keyboard	0fac:0ade:efba1ddf	f23 down
keyd virtual keyboard	0fac:0ade:efba1ddf	leftshift up
keyd virtual keyboard	0fac:0ade:efba1ddf	f23 up
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse up
ORBIT BT5.0 Mouse	047d:80a8:dd1bc6b9	leftmouse down

~$ sudo keyd listen
+main
+control
-control
+control
+shift
-shift
+shift
-shift

~$ keyd --version
keyd v2.5.0 ()

[JamiKettunen]

This reminded me of https://github.com/torvalds/linux/commit/907bc9268a5a9f823ffa751957a5c1dd59f83f42 which was also backported to v6.13, v6.12.12 and maybe others too, not sure if it helps here at all though

[Heavygrass]

Hi! Could smbd please advise the best keyd config for this evtest output (when Copilot key pressed & released)?

type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1757646438.743616, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1757646438.743616, -------------- SYN_REPORT ------------
Event: time 1757646438.747052, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1757646438.747052, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1757646438.747052, -------------- SYN_REPORT ------------
Event: time 1757646438.750642, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1757646438.750642, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1757646438.750642, -------------- SYN_REPORT ------------
Event: time 1757646443.232875, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1757646443.232875, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1757646443.232875, -------------- SYN_REPORT ------------
Event: time 1757646443.238765, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1757646443.238765, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1757646443.238765, -------------- SYN_REPORT ------------
Event: time 1757646443.247962, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1757646443.247962, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1757646443.247962, -------------- SYN_REPORT ------------

Also an explanation of what happens in the output above would be very helpful. Currently use this config:

[ids]
*
[main]
leftshift+leftmeta+f23 = rightcontrol

It mostly works, but sometimes there's no input at all from most keys into the current window, no sure how to troubleshoot. Have to do ALT+TAB and back.

Kernel 6.14.0-29. Thanks.

[Heavygrass]

@temach What capslock = layer(control) line does in your config?