I want to announce a small Java library I made for handling multiple keyboard input on a single computer. I’ll start by giving some background knowledge.
Three years ago, at our lab we had the need to write a Single Display Groupware (SDG). Let us temporarily forget about Multitouch tabletop and only focus on traditional mouse and keyboard.
What if multiple mice and keyboard are connected to the same computer. For historical reasons, contemporary operating systems natively support only one mouse and keyboard. I am not saying you cannot connect more mice and keyboard to your computer. Of course you can, but the OS treat them in the same way. For SDG based on mice and keyboards, one problem we are facing is how to discriminate one mouse/keyboard from another.
Let’s talk about mouse and keyboard separately in the following sections.
1. How to handle Multiple mice?
At that time, we did not think of implementing our own solution. We found the “SDG Toolkit” (http://grouplab.cpsc.ucalgary.ca/cookbook/index.php/Toolkits/SDGToolkit) from Saul Greenberg’s lab at the University of Calgary. Saul Greenberg is a big name in HCI. Some years ago in their group they did research in SDG, so they developed the toolkit. The library was quite old and only supports Microsoft .NET 2.0. Later on, I also found the Microsoft Multipoint SDK (http://www.microsoft.com/multipoint/mouse-sdk/) which is also capable of handling multiple-mice. Of course, here I mean handling multiple-mice within the application level, not at the OS level. Both solutions are only for Windows. In order to have it for other platforms, there is another C library called ManyMouse (https://icculus.org/manymouse/) which works on all three major OS’s. There is also a Java port of it. The Java-based Multitouch Framework Mt4j also uses ManyMouse for simulating multiple touch.
Until now, you see that handling multiple mice input seems to have many alternative solutions. Then, how about keyboards?
2. How to handle multiple keyboards
SDG toolkit actually also support multiple keyboard for Windows. In Windows, you can of course make your own library by following the approach described in this article : http://www.codeproject.com/Articles/17123/Using-Raw-Input-from-C-to-handle-multiple-keyboard .
If you are looking for something for another OS, e.g. in Java. Unfortunately I did not find an existing solution. Of course, you are not possible to find a pure Java solution, because this involves handling low-level input.
I was actually inspired by the article I mentioned previously. I think it should not be difficult to make my own library if I am able to get the low level input of the operating system. I discovered HID API (http://www.signal11.us/oss/hidapi/) which allows an application to interface with USB and Bluetooth HID-Class devices on any OS platform. There is also a Java port of this library called javahidapi (https://code.google.com/p/javahidapi/).
I then started building my own library which is named “ManyKeyboard” with this Java api. It is not difficult. I made the source code available in my BitBucket repository (https://bitbucket.org/nanli/manykeyboard/src). If you are interested, you can have a try, there is a TestManyKeyboard.java file. Just run it.
What I actually wrote make this work is the following:
1. Read HID specifications and find the usage page of Keyboard device (usage page = 6)
2. Connect to all detected keyboard (with usage page =6 ).
3. Get the input report from the keyboard. An input report is the binary data of your USB device. For keyboard, you can get which key is pressed and released.
4. Fire the corresponding event.
In order to use this library, you can just create a class which extends ManyKeyEvent Listener, and initlalize the library in the following sequence.
For complete source code, please see my bitbucket link given above. There is an example application in my Bitbucket repository.
I created a Java lib called ManyKeyboard to handle multiple keyboard input. From now on, in order to develop an SDG application, you can do it with Java on any platform. Suppose you have a multitouch tabletop application and you want to use physical keyboard instead of onscreen keyboard, considering its lack of tactile feedback. Here is the solution.