Only X11 based linux distro is supported right now, if the X11 is not accessible (though should be in most GUI distros), we can safely fallback to read events from the /dev/uinput or /dev/input/eventX.

This operation is only granted when the root access is given, so we'll always prioritize the X11 way to handle the communication.

To be fixed: DeviceKeyboardHandler.

Need collaborators / contributors for testing and working on extending the library to support Mac OS.

Unfortunately I have zero experience with Apple products and don't have access to a Mac right now, so I couldn't test the library either way.

The codebase is organized to easily integrate the support, one can work on either Java, C++ (JNI side) or Kotlin (K/Native side) whichever is more familiar to him/her. The keyboard-kt/src/jvmMain/jni/{platform}-{arch}/ is where the platform specific JNI code reside, and the Kotlin/Native code is present in keyboard-kt/src/{platform}{arch}Main/ as usual.

To cross-build for the JVM packaging we can use multiarch/crossbuild, and gradle to automate the build process as we've did for Windows and Linux currently.

If somebody has any idea or suggestions drop it below! A small contribution may help the project to pick up the momentum to get ready for the complete implementation.

Current implementation only allows to specify one KeySet when calling some function in the Keyboard.

But that's not really idiomatic, in sense that we may want to do something like (Key.LeftCtrl or Key.RightCtrl) + K combination, in this case we can add two different handler for that (or create a lambda in a variable and call the function twice), but in some parts like suspensive waiting for key combination(s) to be pressed it is quite cumbersome.

Similarly if we want something like (Key.LeftCtrl or Key.RightCtrl) + (Key.LeftShift or Key.RightShift) + G the code becomes multiplicative large (i.e. setting the handler 4 times).

So the issue is clear, to implement a flexible way to pass a generic KeyCombination which is different from KeySet and allows to interact with the high-level api in even more convenient way!

Unexpectedly the X11 events are not able to dispatch properly, the root cause is unknown. I've asked a question on StackOverflow but didn't got a meaningful reply. Maybe we need to dig deeper why doesn't XSendEvent work.

Affected code:

In windows, all the work (from hooking to unhooking) must be done in single thread or else, the system becomes very slow and laggy, and hook doesn't work as expected.

EXCEPTION_ACCESS_VIOLATION is also generated, need to recheck things. This generally occurs when local references of JNI are stored in shared library.

Currently using the XLib and XInput2 requires the overhead of installing the required lib to generate the headers which does not let non-linux host or one without these libs to build the project for those platform.

Second most important thing is that where there is non-X11 desktop environment the library won't work. Which limits it in the amount of targets.

Future plan is to migrate all the c-interop generated stubs into dlopen/dlsym/dlclose Posix API which allows to dynamically fetch the CPointer<CFunction<*>> and invoke it. Which can be done in the runtime (and has pretty less runtime overhead), we may even cache it at the first access.

This will let the library to be build without headers and in Windows/Mac for Linux as well and and can easily test it remotely on a VM. This will also enable to fallback to the Linux device API (/dev/uinput | /dev/input/xxx) if X11 is not present, which will allow the lib to support almost all the linux platforms (though this device API requires superuser).

Getting dockcross images might be a pain, it includes 450mb compressed images for each x86 and x86_64 linux images, and 650mb each of the windows build images (actually are linux, but has build tools).

And the uncompressed size is about twice of each of them, so are not very feasible to pull large amount of data before building things even if they are automated.

Instead we can create a docker image of our own which has all the tools in it, and can be compressed down to as small as possible to make it easy to build the project for jvm and nodejs.

Affected files:

The index number 0 is used twice by mistake, a quick-fix can be added.