what Key code system does this library use?

[Mikeyzy]

I'm trying to detect NumPad keys only, and "NUM_1" detect both NumPad 1 and normal 1, which is not going to work at all. if I want to use Scan code, there is no information or a function to return key code but key name. ( "KeyboardEvent(1 down)" etc.) according to the example in readme, space = 57, which makes no sense for MS VK code, or the key code used in pyglet and other libraries. (usually they use ascii code for character keys)
is there a list somewhere to fine the key code?

[Mikeyzy]

never mind, did a for loop with all the keys, and looks like it is based on LWJGL key code set. maybe should add this on top of readme, so people know.

[boppreh]

Please note that the library reports scan codes (with minor exceptions), and not key codes. The former corresponds to physical keys on the current keyboard, such as "third key on the fourth row", while key codes corresponds to conceptual key such as "F1" or "letter b".

Because not every key code is mapped to a hardware key, and not every hardware key is mapped to a key code, the library strongly prefers scan codes whenever possible. Otherwise recording and replaying events would not be possible, for example.

If you want to react to key functions (e.g. do something when the user presses "letter b"), use the .name attribute on the events. This respects the user's keyboard layout choice.

The list of hardcoded values you see are either mapping key aliases (e.g. "spacebar" -> "space"), or key codes to be used if the OS fails to report a scan code (media keys on Windows usually report a scan code of "0", for example).

This is why the example mentions space = 57. I'm not sure where you saw the LWJGL key code set being used.

Detecting numpad events is harder than it sounds, and has been a source of bugs in the past. A workaround is to rely on the is_numpad property of events instead of looking into the key names.

If you tell me what OS you are on, I can take a look into the NUM_1 bug.

[Mikeyzy]

I pulled all the scan code with

for i in listKeyName: #listKeyName contain a list of key name on microsoft documentation for VK code
-try:
--print(i, keyboard.key_to_scan_codes(i), sep="\t")
-except:
--print(i,"error", sep="\t")

and i compared all the scan code returned with different key code layout, and it match the LWJGL key code set. which is 1=2, 2=3...(I worte minecraft mod before and minecraft is using LWJGL layout)
the num 1 wasn't a bug, that was my mistake.
I was testing if I can differenciate the num key by using
keyboard.add_hotkey("NUM_1",print,"p")
and I forgot to change it back after I pulled the key code.

anyways, the scan code is returned in LWJGL code for sure,
I tested it with:
keyboard.add_hotkey(2,print,"p")
it will trigger with normal "1", but not "NUM_1"
havn't tested it with linux yet, might test it later.

[boppreh]

Sounds like LWJGL is also using scan codes then. For Windows, you can check the code that maps scan codes (and key codes) to names here. It's unfortunately very hacky, and brute forces the space of possible scan/key codes, but is the only way I found given the APIs given by the OS.

Note this mapping is done at runtime, so there are no hardcoded keys. This ensures that any keyboard layout is supported.

The Linux side should report the same numbers, which is the whole point of using scan codes instead of key codes: ensuring the references are stable and consistent among different OS's.

[Mikeyzy]

I was trying to get rid of scan loop from my code to a better optimized way of doing it
def isKeyPressed(vCode):
-return (win32api.GetKeyState(vCode) & (128)) != 0
and put it into a while loop in a separate thread.
this is not as good as event based callback when the number of keys I need to scan.
great library, great work.