MJ1
April 25, 2026, 11:09am
35
Howard:
Effectively, yes. They’re connected to the mainboard over USB as two separate keyboards. The only option besides making a pair which link and then present themselves as one USB keyboard and are managed by a single firmware, like a two piece keyboard (Such as https://keeb.io/collections/iris-split-ergonomic-keyboard ), is to have software running on the computer which controls the backlight settings instead of the keyboard’s firmware.
Arbitrary keyboard to keyboard communication is actually possible with a little trick. I use it with a qmk mouse. And a community member used it for a FWL16 keyboard firmware called altsync.
more details (click to show)
Keyboard to keyboard communication is possible with a little trick using the indicators. I use it on my mouse, learned of it from an old alternative firmware I found created by Ploopy Co. There is also an example of it from a community member here. I could find links when at my PC.
~edit~
The one I’ve used is based on Ploopyco’s LED-Key BitMasks (lkbm).
keyboards/ploopyco/trackball_nano/keymaps/lkbm/readme.md
# The keymap that takes commands as LED-Key BitMasks (lkbm)
Based on [maddie](../maddie), this keymap lets you send a 2-bit command by having a macro on your keyboard tap `KC_NUM_LOCK` and `KC_CAPS_LOCK` on and off within a very short window (25ms by default) to represent bits 1 and 2 respectively. The keymap uses this to allow toggling between sending mouse-movement events and scrolling events; cycling DPI presets, and resetting to the bootloader, so you can reflash without having to unscrew your Ploopy Nano.
Here’s another implementation based on lkbm.
github.com/nicknimchuk/qmk_nano_dualhand
# qmk_nano_dualhand: a keymap designed for two Ploopy Nano trackballs
This keymap configures two Ploopy Nano trackballs, one for each hand. At any given time, one will be for mouse movement, while the other is used for scrolling. This can be swapped dynamically using commands from a QMK keyboard, potentially reducing injury or strain by not restricting mouse movement to a single hand.

## Inter-QMK communication
The primary feature this code provides is a num/caps lock communication feature based on the [lkbm](../lkbm) Nano keymap, which was itself based on [maddie](../maddie). It provides code for sending and receiving commands between QMK devices by toggling the caps lock and num lock keys for "bits" of the commands. The main advantages over the previous versions of this feature are:
* The feature is mostly broken out into separate files, so it's easier to apply to other devices and keymaps.
* The command length is an arbitrary (pre-defined) number of bits, so any number of commands can be created at the cost of slower commands.
* There are many timings that can be easily tweaked to try to find the right balance of speed and command reliability. These timings do not have to influence any other settings in QMK.
* The commands are sent asynchronously, so even if a command takes a full second to send, you can use the device while it is sent.
There's also some disadvantages:
* Commands will likely take longer to allow for two-way communication if desired.
* Bits are only processed if the given lock is toggled twice without the other lock toggling. This reduces misinterpreted commands, but also means that some commands that [lkbm](../lkbm) would handle due to interleaved lock commands will be ignored.
* The asynchronous nature means that typing could happen while caps lock or num lock is temporarily enabled (or temporarily disabled). This can be slightly mitigated by the fact that one command will only use caps lock, and another command will only use num lock (but the rest will use both).
* This feature is not written to minimize flash space. This is not a problem with the Nano, which has plenty of free space by default, but may cause problems with some keyboards. The older options do not require any additional code space to send commands.
And the FWL16 altsync firmware by a community member, which looked to be based on nano_dualhand.
github.com/ionitor/qmk_firmware/tree/ionitor-altsync/keyboards/framework/ansi/keymaps/altsync
Using scroll-lock is also possible, as I do that on my mouse. There is also a kana indicator which should be a possibility but I had trouble getting that to work & I didn’t really have a need for it so I didn’t bother.
1 Like