Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago These were not originally supported in 1.1 due to the lack of Java support. I
am currently working on providing support in 1.2. Please build the trunk from
source and test. Instructions for compiling are attached to bug 67.Original comment by a...@1stleg.com on 4 Sep 2013 at 4:51
GoogleCodeExporter
commented
9 years ago Original comment by a...@1stleg.com on 9 Sep 2013 at 10:37
GoogleCodeExporter
commented
9 years ago Original comment by a...@1stleg.com on 9 Sep 2013 at 10:38
GoogleCodeExporter
commented
9 years ago Can you let me know what device you are create these even codes with? Is it a
laptop or keyboard? Model #?Original comment by a...@1stleg.com on 30 Aug 2014 at 12:43
GoogleCodeExporter
commented
9 years ago Laptop.
Also look at the sheet I linked in issue 60 at scancode 112/117 (extended keys
with scancode 12 and 17)
Meanwhile I've been working on an all-JNA implementation for both keyboard &
mouse (extensible to more via a common interface). I've got event pulling
working now; Working on pushing (listeners). After that come the look-up tables
for texts and exceptional scancodes/VKcodes.
In your source I also noticed you do a lot of pre-processing in the callback
functions. This is discouraged because of performance. I just store the literal
wParam, lParan, and nanotime in an object that I push onto a
LinkedBlockingQueue and process later.Original comment by mark.jeronimus@gmail.com on 1 Sep 2014 at 5:42
GoogleCodeExporter
commented
9 years ago Yah, there is a small amount of prepossessing happening on the callback to
normalize the events in a cross platform way; It comes down to a few compares,
assignments and bit shifting and runs very quickly in 1.2. I should mention
that 1.2 has offload the Java processing to a ExecutorService (defaults to
newSingleThreadExecutor) that probably operates similarly to the
LinkedBlockingQueue you are using. If I was to post-process on a different
thread like the ExecutorService, you would not be able to consume events on
Windows and OS X. See
https://github.com/kwhat/jnativehook/wiki/Examples#consuming-events-unsupported
A lot of work was put into speeding up the callback in repose to issue 43
because I initially thought the response time was causing the hook to
registered, however, after countless hours of testing and experimentation, it
looks like it is probably related to the automatic unpacking creating multiple
library names that leads to the library being loaded too many times.
Now on to the key codes. In the current trunk (github) I have implemented all
keys that currently have scancode set 1 codes and sun keyboard extras. The
rest of the keys, including lcd controls, do not have predefined scan codes.
What I will need to do is collect scan codes for each os, figure out where they
will fit in the look up table, and probably add some more "keycode
normalization" to two of the three platforms that return a different code for
those keys. The laptop I currently have does not produce a hardware scancode
for the lcd controls and because I don't have a keyboard to produce these
codes, someone will need to grab the codes (0x112, 0x117) on OS X and Linux
before I can implement them. If you run 1.2 against OS X or Linux, the rawCode
should be all I need. On Windows that code will be something like code_needed
= kbhook->scanCode | ((unsigned char) ((kbhook->flags ^ 0x0F) & 0x0F) << 8);
which I *think* is what 0x112 and 0x117 are for Windows. On OS X this will be
a unsigned char 0-255 and on X11 its going to be some KeySym, in both cases the
rawcode produced by JNativeHook 1.2 should be sufficient.
Original comment by a...@1stleg.com on 1 Sep 2014 at 3:44
Original issue reported on code.google.com by
mark.jeronimus@gmail.comon 23 Jul 2013 at 5:41