Environment

Windows build number: Microsoft Windows [Version 10.0.18363.778] 
PowerToys version: 0.18.1
PowerToy module for which you are reporting the bug (if applicable): Keyboard Manager

Steps to reproduce

Actual behavior

Non standard 3 bytes scan codes keys are note detected correctly. In my case, special keys on HP EliteBook keyboard key "Present", "Call" and "Hang up".

Key	Detected key in "Remap a key"	Detected shortcut in "Remap a shortcut"	SharpKeys ScanCode
"Present"	F22	Ctrl (Left)", "Alt (Left)", "F22"	E0_1F6F
"Call"	Win (Left)	"Win (left)", "Alt (Left)", "F15"	not detected
"Hang up"	F14"	"Ctrl (Left)", "Alt (Left)", "F14"	E0_1F65

Expected behavior

Detect custom keys with 3 bytes scan codes. Enable me to map them (eg. "Call" key I never use to "Insert" key that is missing on HP EliteBook Keyboard).

May 28 '20 13:05 tarosk

@Arjunbalgovind is this the virtual key code vs scan code issue that's been brought up?

May 29 '20 15:05 saahmedm

Similar. In this case as well we should be able to support this with Shortcut to Key Remap since for example the Call key seems to be equivalent to Win+Alt+F15. But here as well similar to Alt Gr if a user remaps Alt(Left) to something else this would break. I think if we are introducing Shortcut to key and vice versa we might have to think about combing everything into one UI, which means shortcut remaps having priority over key remaps

May 29 '20 16:05 arjunbalgovind

@arjunbalgovind how did you determine what is a 3 byte scan code

Jun 22 '21 20:06 crutkas

@crutkas The 3 byte scan code only applies if we use the registry approach (or possibly some driver method). Since the low level hook method only uses virtual code, most of the keys listed above like "Present", "Call" and "Hang Up" are actually detected by Windows as shortcuts and not keys. To remap these keys the user would have to enter them as Shortcut to Key and not Key to Key. We might be able to write some code to make this cleaner by detecting that something like Ctrl+Alt+F22 is actually the "Present" key, but these shortcuts are undocumented, and we will probably need to get information on it from the Input team.

Jun 24 '21 02:06 arjunbalgovind

I assume this is the same behavor from my HP Elitebook 840 G8 that has a "programmable key" on F12 that you cant program!

Shows up as "undefined". It does let you re-map it once you disalble the HP service that throws up a popup for it to install their software, but it does 2-3 presses each time you press it!

Feb 04 '23 12:02 TomLewis

I don't have a keyboard with these exotic buttons, but looking into sharpkeys code, this is the code that prints E0_1F6F. To get the original nCode value, we do 0x0100 + 0x1F6F = 0x206F. Its binary form is 0010 0000 0110 1111.

We can see that it's not actually an extended key, because the 9th bit after >> 16 is zero. What's not zero is the 29th bit that indicates that the Alt was down. We can also see from the docs that the scan code part only takes 8 bits. This is likely to the fact that Windows sends a key combination in response to pressing the "Present" key. However, that bit also made if (nCode > 0x0100) check pass, subsequently printing it as extended (E0_ prefix), even though it's not.

The scan code part of 0x206F is 0x6F = 111. Looking at the scan code table's Key Location column, we don't see it. That means it's a non-standard location for 102-key keyboards.

To summarize:

There's no such thing as 3 bytes scan codes, it's an artifact of how sharpkeys display lParam of WM_KEYDOWN messages.
Windows transforms those exotic button presses to a combination of key presses, as seen in the Detected shortcut in "Remap a shortcut" column.
We cannot use "Remap a key" dialog for those keys, because they're not actually keys
However, we support remapping shortcuts to a single key via "Remap shortcuts" dialog:
We won't be able to discriminate between an exotic key and its shortcut that Windows sends to us