[zxter]

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.

[varispeed]

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.

[zxter]

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 ;)

[varispeed]

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.

[zxter]

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.