Hacker News Reader

Comment by Umang018 | Hacker News Reader

This is really impressive, especially considering the complexity of designing a wireless split keyboard from scratch! Having built my own mechanical keyboard before (though not wireless), I know how much goes into PCB design, key switch selection, and firmware development.

One challenge I’ve seen with wireless keyboards (especially splits) is managing synchronization lag between halves. Some DIY split builds struggle with Bluetooth interference, while others use NRF-based communication. What approach did you take to keep latency low and ensure reliable keypress synchronization? Also, how does the power efficiency compare to something like a ZMK-powered split?

View on HN

Maybe stupid question, but can split keyboard work as two separate keyboards connecting independently to the operating system? That way you don't have to synchronise anything.

There’s no issue with a computer recognizing two keyboards, but smaller keyboards often lack all the keys found on a standard one. So, you’ll need to use modifiers to create the keystroke and then send it to the computer. If you press a modifier on one half, the other half needs to be aware of it to send the final keystroke. Creating a layout with these modifier-based key combinations is just a small part of the many tricks you can pull off with custom firmware. While the computer thinks it’s connected to a standard keyboard, you can do some really deep customization on the keyboard side.

Wouldn't operating system take care of that?

When you have two halves of a keyboard recognized as separate keyboards by the computer, then just like you said. For example, if you press shift on the left half and u on the right, the computer first sees the shift and then the u. It then types a capital U.

But in my case, let's say I don't have any numbers on the keyboard. Instead, I use modifier keys to create a layer for numeric values. So, when I press a modifier on the left, the computer won't notice. Then, pressing what would normally be the U key on the right sends a 7 instead. The computer just sees a 7 being pressed.

What I am trying to say is that operating system should collate events from all keyboards, so that wouldn't matter which one had modifier pressed on.

First, for an operating system to process input, it must continuously scan the keyboard matrix to detect keypresses. This adds extra load to both the OS and the CPU. Additionally, every OS must implement the same logic with the same parameters. Since there are many types of keyboards, each OS would need to know every keyboard's matrix layout.

However, before addressing that, like keyboards other HID peripherals are not directly part of the hardware. They connect to computers via USB or Bluetooth, and to do so, keyboards must have an internal chip, "a brain" even just for communication, let alone scanning keyboard matrix. This is similar to how a mouse processes sensor data internally rather than relying on the computer to interpret it. As a result, they can be used on almost any smart device with USB or Bluetooth.

Since we already have this extra chip, "brain", we can add personalized custom logic to simplify our lives and give our hands and wrists a break. This is similar to how gaming mice reduce DPI when the aim button is pressed or how old joysticks had an auto-fire button.

Shh! The computer doesn’t need to know ;)

You are overcomplicating this. Keyboards shouldn't have any logic apart from scanning and sending key press and release events to the OS.

I press modifier on keyboard A, keyboard A sends key press event to the OS. I press key on keyboard B, keyboard B sends key press event to the OS. I release key on keyboard B, keyboard B sends key release event to the OS. I release modifier on keyboard A, keyboard A sends key release event to the OS.

From the sequence of events, the OS knows that a key was pressed with the modifier and can act accordingly e.g. emit an event downstream that corresponds to the key that should be generated when pressing a modifier.

Scanning the keyboard matrix is no concern for the OS.

Actually, I’m not overcomplicating things—just overexplaining because you mentioned it might be a stupid question.

Your example is valid, and I acknowledged that it’s correct in my first reply. I also added that, in these types of keyboards, there could be special logic to compensate for missing keys or provide additional features for comfort or ergonomic reasons. This means the keys need to communicate with each other and send the final keystroke afterward.

I also noted that almost all keyboards are not entirely "dumb" and include at least a processing unit to scan the matrix—something you agreed they should have—as well as to handle USB or Bluetooth communication. This processing unit can easily be used for the reasons I mentioned above, without requiring extra hardware or additional software/drivers on the OS side. This approach offers a modular, OS-agnostic way to create a custom solution for comfort or ergonomic needs.

Reply on news.ycombinator.com