Questions about custom keyboard

It's true, the host normally supports multiple HID transparently. So the keyboard halves don't really have to communicate with each other.
Edit - oh wait - shift keys would be a problem...

Only if you press more than one.

Question: What handles the shift? is it the keyboard or the PC?

(I believe it is the PC.)

The single most useless and nuisance key on a keyboard? "Insert"


Correct, in all versions of x86 DOS from MS or IBM as well as all desktop versions of Windows* there is a single keyboard buffer into which all keystrokes go and are evaluated together.

*I know this to be true for Windows on x86, and x64, I have not tested it on ARM based Windows or Windows IoT.

This should hold true for BSD based systems like macOS, but Apple has been slowly departing from its BSD roots so that should not be assumed.

I only know White Box Linux and it works there, but it should be noted that I'm running a Vanilla build and it's pretty dated. No assumptions but it's potentially Linux friendly too.

Well, there's the point - there are keystrokes, not characters, travelling over the USB HID interface. And the codes are for key press and key release, so as long as you do not press the (same) shift key on both keyboard halves at the same time (and I suspect left and right shift are different in any case, so will not be the same), there is no confusion.


That doesn't matter either provided both keyboards send the same value for shift, then there is no conflict using one, the other, or both. A perfect example of why OP shouldn't vary from the USB standard and follow the standard key values as well.

I haven't tried it, but if you send a Left Shift press on one keyboard and hold it down continuous, and send a single Left Shift press (send press -> release) from the other keyboard, probably the first keyboard's Shift key was treated as unpressed even if you hold it down? :thinking:
I am not very familiar with HIDs. :woozy_face:

Nope, it's dumber than that. Just values in a register.

I found Digispark in the corner of drawer, so I made a HID keyboard and just wrote a sketch of pressing and releasing the Left Shift repeated.
And it overwrote the Left Shift hold down on my main USB keyboard.
I can't enter uppercase letters by holding down Left Shift on my keyboard.

If make separated keyboard as two separate USB keyboards, does that mean the shift, control and alt keycode need to be separated left/right correctly?

Hmmmm. I tested it on my end too and did not experience that issue. I used a Logitech K400r and a Steel Series, both HID.

Perhaps I misunderstood the test.

  • KB1, KB2
  1. Press and hold left shift KB1
  2. Press and release left shift KB2
  3. While continuing to hold left shift KB1 test characters on both keyboards
  4. Repeat in reverse order

In my case they were caps.

The test is the same except that we used a cheapest USB keyboard and Digispark, which was programmed as a HID device, as the second keyboard.
In my case, I had already disabled Shift pressing on the main keyboard as of 2. (Provides only the burden of the little finger!)
By the way, I'm using Windows.

Can it behave differently if it's a high-end keyboard that supports N-key rollover, or if it's a special keyboard that's integrated with other HID devices?
I've never written a native device driver for Windows and I'm also not familiar with the HID specifications, so I don't know any more. :woozy_face:

EDIT: Perhaps this is slipped from the OP's subject, so I'll end here. sorry!

Human Interface Devices (HID) Information | USB-IF
I am not as familiar with it as I should be, either.

Ideally the first device in the chain would present itself as a keyboard with an integrated hub. If the 32U4 was presented to the host and the USB hub chip could be connected through it, then all keyboard inputs could be directly filtered and controlled.

This option would also offer great control for extensibility.

I do not know if the 32U4 would support that configuration. If I had the parts I'd be testing it now.

There would be no specific direct interaction between two keyboards.

If the left shift is pressed on one, then we are in shift state. If the left shift is then pressed on the other, we are still in shift state. If one is released, then we are no longer in shift state even though one is still pressed.

Does this matter? Well ... :roll_eyes:

I tested it myself as well, with 2 keyboards, and it behaves as wanted, so no problem there.
However, this is not really what I want, because it adds other limitations.

For example; say that one of the 2 halves has a button that triggers some functionality on both halves, like turning all the backlighting on/off, that would not work. Having both halves controlled by 1 single master controller solves this issue. Sure, you could probably write some windows driver, but I prefer it to just be a HID device without requiring other drivers if possible.

Another example could be to enter some mode where certain keys become function keys on both halves until deactivated.

And regarding the TRRS connection, it's not obvious for a noob like me who hadn't looked in how the connector pins worked. I did now, and it makes sense, so learned something useful today!

A USB C connector has 24 pins, which are a lot more than needed. What other USB connectors can be used? I'm also finding it hard to figure it which pins of the microcontroller (SPI pins) they should be connected to in that case.

Are you building a prototype, or trying to leapfrog to the final product?

Prototyping and figuring out what I'll need for the final product (or at least the first iteration of it).
I.e.: I've been looking into rotary encoders and thumb sticks so that I can order some, in order to test them, as I haven't got any at all and I haven't testing hooking them up to an Arduino.
But at the same time, I want to buy ones that I'll actually use, as I don't have any and shipping costs aren't always that cheap (I'm not living in the States). Likewise, having the components will allow me study them and figure out the dimensions of the holes required in the case of the final product.
I've also been prototyping the layout of the keys at, and printing the SVG to test the layout to see if it feels ergonomic, if I really want everything I initially thought of and experimenting with the positions.
Once the above is complete, I will know exactly how many pins I'll need, and then I'll be able to order the micro controllers and test communication between them.
Likewise, I'll take my time for the case and the PCB.
So, prototyping and looking into the final product, yes. Leapfrogging to it, not in my opinion.

For other people wanting to create their own keyboard (custom case and all), I found this excellent blog post;