All 12 numpad navigation/edit keys report wrong location
Closed this issue · 7 comments
GoogleCodeExporter commented
For all navigation keys except Enter, num-lock needs to be off to receive
navigation keystrokes.
The keys /*-+ are not navigation keys and work fine.
Example, when pressing both insert keys one after another:
Keycode rawCode keyLocation id
009B 002D KEY_LOCATION_STANDARD NATIVE_KEY_PRESSED
009B 002D KEY_LOCATION_STANDARD NATIVE_KEY_RELEASED
009B 002D KEY_LOCATION_STANDARD NATIVE_KEY_PRESSED
009B 002D KEY_LOCATION_STANDARD NATIVE_KEY_RELEASED
Original issue reported on code.google.com by mark.jeronimus@gmail.com
on 22 Jul 2013 at 2:45
GoogleCodeExporter commented
To fix, you could the 1st bit of kbhook->flags left shifted to kbhook->vkCode,
as in
extendedVkCode = kbhook->vkCode | ((kbhook->flags & 1) << 8);
And then define new constants, like:
#define VK_NUMPAD_HOME 0x0124
#define VK_NUMPAD_UP 0x0126
...
#define VK_NUMPAD_RETURN 0x010D
Also, slightly off-topic, I find a mammoth case statement in NativeToJava.c,
which I would solve using look-up tables.
Original comment by mark.jeronimus@gmail.com
on 22 Jul 2013 at 2:57
GoogleCodeExporter commented
Good catch, I will drop in a second patch tonight and attach a new build to
this bug.
I went back and forth on the lookup table. It starts getting complicated
because the native keycodes are not always consecutive and the performance
benefit was negligible when I profiled it. I am open to making adjustments if
you have a compelling reason for the lookup table.
Original comment by a...@1stleg.com
on 22 Jul 2013 at 5:54
- Changed state: Accepted
GoogleCodeExporter commented
This should take care of the problem.
Original comment by a...@1stleg.com
on 23 Jul 2013 at 5:40
- Changed state: Fixed
Attachments:
GoogleCodeExporter commented
Thanks for the quick fix.
One 'compelling reason' might be because you can pass through unknown codes of
media keys etc. to the user instead of labeling them VK_UNKNOWN. I have such
keys on my Japanese keyboard.
The length of the table only needs to be 0x200, the lower half for OS-defined
keys, the upper half for user-defined keys. You might think you need multiple
tables, one for the VK translation, one for location flag, etc., but it's
actually more efficient to encode all those in a single int16 array.
And now, because of the numpad key hack, you use TWO translations in
succession, which could still be solved with a single translations if you'd
utilize the flag bit as described above.
I'm a bit of a performance guru, even as far as making java code faster than
equivalent c code. I'm a great proponent of look-up tables because they scale,
and case statements obviously don't.
Original comment by mark.jeronimus@gmail.com
on 23 Jul 2013 at 10:26
GoogleCodeExporter commented
How would you handle the 3 different scan code maps and the possibility of user
defined maps?
Original comment by a...@1stleg.com
on 23 Jul 2013 at 11:48
GoogleCodeExporter commented
Keyboards use all three scancode sets, but software always uses set 1. The
south bridge does the translation for you.
Original comment by mark.jeronimus@gmail.com
on 24 Jul 2013 at 12:59
GoogleCodeExporter commented
Issue 49 has been merged into this issue.
Original comment by a...@1stleg.com
on 8 Aug 2013 at 9:15