Unable to use scancodes with 3x4-2 keypad

[qskwood]

I've tried identifying if there's some kind of LSB/MSB or shifting occurring, but I can't find a pattern in the scancodes I get instead of what I enter in the file. Here are some example file values and output values (from python -m keyboard):

• "<2>" gives me nothing
• "<3>" gives me nothing
• "<4>" gives me scancode 30
• "<5>" gives me scancode 48
• "<10>" gives me scancode 34
• "<11>" gives me scancode 35
• "<31>" gives me scancode 3
• "<32>" gives me scancode 4
• "<33>" gives me scancode 5
• "<64>" gives me scancode 65
• "<65>" gives me scancode 66
• "<66>" gives me scancode 67
• "<100>" gives me scancode 86
• "<101>" gives me scancode 93
• "<102>" gives me scancode 94

I haven't seen any issues using human-readable key names, like "ctrl-f24" in versions 1.2.0 through 1.2.4. I can't test 1.4.0 onward since it doesn't seem to write to my keypad at all (1.4.0 complains, 1.4.1 onward silently fail), but I think that's already discussed in other GitHub records. I'd be open to any feedback to continue troubleshooting this to identify the pattern.

[qskwood]

This should be the device based on vendor ID.

Name                                                          DeviceID
----                                                          --------
USB Composite Device                                          USB\VID_1189&PID_8890\6&976CC38&0&1

[kriomant]

Seems like 8890 support was broken, please try version 1.4.4

[qskwood]

I should have mentioned that I tried #93 which did not affect the behavior. I also tried 1.4.4 which appears to be mostly the same except for one change to whitespace. After getting 1.4.4 I spot checked scancodes 2, 10, and 64 which produced the same results as before.

[kriomant]

Ok, python -m keyboard no longer works (crashes) on my computer.
So check this: scan code of key '2/@' is 31. If you assign '2' to one key and '<31>' to another, will they produce same result — digit '2'? Are displayed scancodes equal for them?

[qskwood]

I gave that a try. In both cases, the Python module shows a scancode of 3.

[...]
      - ["ctrl-f21", "ctrl-f22", "2", "<31>"]
[...]

{"event_type": "down", "scan_code": 3, "name": "2", "time": 1724778708.6141942, "is_keypad": false}
2{"event_type": "up", "scan_code": 3, "name": "2", "time": 1724778708.677778, "is_keypad": false}
{"event_type": "down", "scan_code": 3, "name": "2", "time": 1724778712.166141, "is_keypad": false}
2{"event_type": "up", "scan_code": 3, "name": "2", "time": 1724778712.2309217, "is_keypad": false}

I did want to mention that, as far as I know, the scancode for the number 2 is decimal 3 on an ISO or ANSI US keyboard, not 31. Maybe I'm misreading the following chart, but this seems to be consistent with what the Python module shows when I use the keyboard.

{"event_type": "down", "scan_code": 3, "name": "2", "time": 1724779152.5107791, "is_keypad": false}
2{"event_type": "up", "scan_code": 3, "name": "2", "time": 1724779152.5671463, "is_keypad": false}
{"event_type": "down", "scan_code": 49, "name": "n", "time": 1724779157.3438478, "is_keypad": false}
n{"event_type": "up", "scan_code": 49, "name": "n", "time": 1724779157.408898, "is_keypad": false}

[kriomant]

See https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf, section “10 Keyboard/Keypad Page (0x07)”

[qskwood]

In my opinion, the word scancode shouldn't be used a synonym for an HID usage code in this context. I was referring to what the OS abstracts from the HID-compliant USB device. The Python keyboard module is, as far as I know, completely incapable of knowing what usage code the computer received from that device because it lives after that abstraction has occurred. You'd need a full on USB sniffer to see what usage codes the device is sending.

I think the easiest solution here is to make the documentation more clearly say what goes on the mapping file is the low-level HID usage code. Unfortunately that means people who want to use this feature have to research the HID spec to find the low-level to high-level mappings for their keyboard layout. I can't immediately think of a better way to do the keypad programming than what you're doing, though.

[kriomant]

Fair enough. I'll think about renaming it.