The new Micro~~soft~~slop copilot key always sends the following key-sequence when pressed:
copilot key down: left-shift-down left-meta-down f23-down f23-up left-meta-up left-shift-up
copilot key up: <null>
This means there's no real key-up event when you release the key --> it can't be used (properly) as a modifier like ctrl or alt.
The workaround is to send a pretend key-up event after a time delay, but then you mustn't be too slow / fast when pressing a shortcut.
- Linux workaround: https://github.com/m-bartlett/remap-copilot?tab=readme-ov-file
- Windows workaround https://github.com/randyrants/sharpkeys/issues/560
- https://xcancel.com/dcolascione/status/2019936377408811319
tldr: AI took a perfectly working modifier key from you.
--- edit ---
Some keyboards apparently do the "right" thing and don't send the whole sequence at once, you can remap those properly with keyd, see: https://github.com/rvaiya/keyd/issues/1025#issuecomment-2971556563 / https://github.com/rvaiya/keyd/issues/825
copilot key down: left-shift-down left-meta-down f23-down
copilot key up: f23-up left-meta-up left-shift-up
this will still break left-shift + remapped copilot and left-meta + remapped copilot, but RCtrl remaps should work as expected
Did Microsoft demand vendors include such a button with those specs? If not, that sounds like a vendor issue, and I'd be looking at other vendors. Either way I'm happy to use keyboards/OSs without that "feature."
It is/was required for vendors to use the AI PC / Copilot+ label and Microsoft "invented" the key-sequence.
src: https://www.theverge.com/2024/3/26/24112500/microsoft-ai-pc-intel-windows-copilot-key-requirements
So to be clear, this key sequence is just how windows interpret the key, the hardware is exactly the same and any other OS can still use it as the context menu key?
Edit : oh, just saw the thing about the linux workaround. So no, they actually fucked it up on hardware level. Wow.
*on the firmware level, to be precise: keyboard polling is commonly done by the Embedded Controller, which is flashable (not by users, generally, tho, but during the uefi update, for example). Sometimes there are separate keyboard controllers, but those are not really common.
So, if vendors want to fix this garbage, they can. Smth tells me, they don't care, tho
nope, the hardware / keyboard controller sends a complete key sequence instead of a distinguishable key-up and key-down event. The OS can interpret that sequence as it sees fit, but you loose the physical key-up signal when you release the key with your finger.
That's insane. Even if they did this intentionally to be as difficult as possible, they locked themselves out of being able to detect long presses?
I've made an update edit: Some hardware vendors fucked up when to send the key-up-sequence apparently so now every keyboard can behave differently. I don't know if this makes the situation better or worse.
Though any competent manufacturer, especially when talking about laptops, would still have the application key under FN (as is shown in that example image), and give the ability for users to select which one is the default function in the BIOS.
Okay that sounds solvable, at least. I mean, I hate it, but it seems that a person is getting what they pay for here. Thanks for the heads up. Hopefully there will be plenty of non-AI PC / Copilot+ computers and keyboards.