As I continue building the code to support all the necessary aspects of the configuration and control protocol for the Keyglove, I am also thinking about the various ways the protocol will be used, and how to keep everything as predictable and flexible as possible. There are both wired and wireless methods of interfacing with this device, but it turns out to be a little more complex than that.
There are two general modes of communication at the physical layer: wired and wireless. This is pretty obvious. For clarity, I am only officially supporting USB (wired) and Bluetooth (wireless) interfaces, but theoretically you can use other types of wired or wireless connections if you’d like. One very smart guy, Mike Cochrane, even hacked a Logitech R400 wireless module into his prototype. But anyway…back to USB and Bluetooth.
Above this physical interface layer, there are a couple of different types of communication that occur between the Keyglove and the host being controlled:
- Configuration commands sent from the host to the Keyglove
These commands are used to define the Keyglove’s behavior, enable or disable features, change options, load and save glove-based touchset definitions, query available features, and more. Anything the host might need to know about or change inside the Keyglove is done with a configuration command. - Behavior events sent from the Keyglove to the host
Events including anything that may be triggered by an internal or user-controlled Keyglove action, such as a touch, gesture, battery notification, mode switch, etc. Anything the Keyglove might need to send to the host without the host asking first is an event. - Direct input signals sent from the Keyglove to the host (keyboard, mouse, joystick, etc.)
These are generated by the internal touchset definition, and sent to the host as standard Human Input Device (HID) signals according to established keyboard, mouse, and even joystick signals.
I’ve been promoting #3 for quite some time now because it doesn’t require any drivers, since it enumerates on the host as a regular keyboard, mouse, and/or joystick. This mode of operation is definitely valuable and convenient, and it will continue to be supported in both wired and wireless capacity. There are some great use cases for this mode, particularly those having to do with mobile computing.
However, if #3 was the only method available, the potential for the Keyglove would be severely limited. First, it would be practically impossible to change its behavior without re-flashing new firmware, or implementing some complicated touch-based method of reprogramming. Second, we wouldn’t be able to automatically swap touchsets on the host when switching different applications into the foreground. You could switch manually using a custom touch, but then literally all behavior would need to be defined on the Keyglove itself, which could get complicated and might even be too restrictive, depending on hardware. Certain devices also only support Bluetooth HID and not SPP without lot of extra licensing, such as the iPhone and iPad.
So, I’ve also been working on the bidirectional serial protocol, which takes care of #1 and #2 above. This protocol, combined with some still-under-development OS-specific “Keyglove Manager” applications, allows for greatly extended functionality. Since the direct input mode (#3) will still be implemented and usable if desired, we end up with an optimal solution: convenience for those who prefer it, and power for those who want more control.
Which Interfaces Support Which Modes?
Now that we know what kinds of signals we need to send and receive, we need to know how we can actually accomplish the goal. Based on what I believe (and am totally guessing) will be normal modes of usage, combined with known limitations of each kind of interface, here is what I came up with.
Configuration commands may be sent from the host to the Keyglove over a serial port or custom HID endpoint (not a standard keyboard/mouse/joystick). We also want to make sure that we parse any and every configuration command sent over any interface, to avoid the possibility of locking ourselves out accidentally. Therefore, configuration commands are always parsed from any interface that is supported in the firmware, namely:
- USB serial (wired)
- USB HID (wired)
- Bluetooth serial (wireless)
- Bluetooth HID (wireless)
Behavior events may be sent from the Keyglove to the host over a serial port or custom HID endpoint (again, not a standard keyboard/mouse/joystick). Unlike configuration commands, however, we might not care to do see these on the host—particularly if we’re using direct input signals from an onboard touchset. So while these are enabled by default on any interface which is connected, they may be selectively disabled at any time. This setting persists across power cycles, since it will be stored in non-volatile memory (internal EEPROM). Supported interfaces are as follows:
- USB serial (wired)
- USB HID (wired)
- Bluetooth serial (wireless)
- Bluetooth HID (wireless)
Events are sent out sequentially in the above order (USB serial, then USB HID, then Bluetooth serial, then Bluetooth HID) for any interface that is supported and enabled in the firmware, and which has an active link in the case of Bluetooth. Thanks to the fantastic Bluegiga WT12’s iWRAP firmware, it is possible to have simultaneous serial (SPP) and HID links going—though support for this hasn’t been fully developed yet.
Direct input (keyboard/mouse/joystick) may be sent out only over HID, unlike the other two. But as before, it is possible to send these out over both physical layers:
- USB (wired)
- Bluetooth (wireless)
Direct input is sent out sequentially in the above order (USB HID, Bluetooth HID) if each interface is supported andenabled in the firmware, and at least one internal touchset is defined in memory, and internal touchset usage is enabled (remember that it may be disabled in favor of OS-based custom touchsets).
So What’s “Normal” Behavior?
Currently, the planned default behavior out of the box is this:
- Parse configuration commands from any interface receiving data. (required)
- Send direct input using default touchset over USB HID if connected. (optional, enabled by default)
- Send direct input using default touchset over BT if active HID link established. (optional, enabled by default)
- Send events over USB serial if connected. (optional, enabled by default)
- Send events over BT if active SPP link established. (optional, enabled by default)
Aside from these things, there is some other optional behavior which is supported but not planned to be enabled out of the box:
- Send events over USB HID if connected, using custom HID descriptor. (optional, disabled by default)
- Send events over BT if active HID link established, using custom HID descriptor. (optional, disabled by default)
There you have it! A basic overview of different methods of Keyglove communication. This allows something for everyone: the ability to plug it in and watch it work without any extra work, as well as the capability for low-level communication and in-depth customization. Now to finish writing the code to support it all…
Leave a Reply