Question: Would work wit Ergodox mechanical keyboard?

[cocoonkid]

This is an amazing idea. Thanks for this!

Would you say that it would work with https://ergodox-ez.com/ devices?

The keyboard is wired via usb and my mouse is a radio mouse with an usb receiver as well.

Keep up the great job!

[ruundii]

Hi,

thank you very much for your positive feedback.
i don’t own ergodox, but can’t see any reasons why it may not work. if your device works as a HID device for linux (raspbian) - then the hid events will travel via hidraw driver and BT HID hub will be able to pick them up.

same for your mouse - should work. most likely raspberry will see it as usb. there is some little chance your radio mouse is actually a bluetooth mouse and you will have effectively two bluetooth adapters - one built-in in raspberry and one in your dongle. as long as the built-in one remains the first (hci0 interface) it will work as is, otherwise you will need to tweak the code a little bit, so e.g. it works with hci1 instead of hci0.

now - a little bit of boring and comprehensive detail and thinking on what might happen in case of an exotic HID device and what to do in such case (may be not really relevant for you, but just in case, feel free to skip):
currently the hub exposes itself as a pretty standard keyboard, but can be tweaked to behave like something pretty exotic. the way it works with HID - is that a device has a HID descriptor, which declares what predefined standard HID events device can produce and receive. based on such descriptor, your machine OS (host, not Raspberry) understands how to interpret the events.
for devices that stay in standard HID range of events/usages you would need to may be create a custom hid event filter with remapping - translate events which correspond to your device and its descriptor to and from events which correspond to the descriptor of the bt hid hub. in the current implementation this is exactly what is done for the A1314 apple keyboard. you may also want or need to adjust the hid descriptor itself (in the sdp_record.xml file) if you will be producing HID events which are in the HID spec, but not in the current HID descriptor.

some devices also may produce/receive events with vendor-defined event codes, where there is no such event in HID standard list. The standard HID event spec is a 168 page document and covers quite a lot (https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf).
so, if the device uses a vendor defined event, then my understanding the OS will need to use a vendor driver to process these events (other standard events will still work). a1314 actually have couple of events which are vendor defined - e.g. brightness up and down keys. and there is standard HID events for these. here you have few options -

1. map these vendor-specific events to something else instead - eg instead brightness up pick another standard hid event which may be useful for you and remap
2. don’t bother and leave some keys not working at all
3. set vendor id/product id of the BT HID Hub to be the same as you device with vendor specific codes. i don’t know on top of my head how to do it, but i think i seen it being configurable somewhere. in this case the receiving OS should use the same vendor driver to process the vendor specific events.

also one thing to keep in mind is that there are three types of HID reports which host computer exchanges with HID devices:

1. an input report (dev->host) - your normal keypresses, mouse moves etc
2. an output report (host->dev) - e.g. when you press caps lock on one keyboard and host receives it, it then sends an output report to all the keyboards saying that caps lock has to be turned on or off, so the keyboards light their leds on caps lock.
3. a feature reports - getting or setting some configuration params for the HID device, e.g. mouse sensitivity. again, feature reports will only be present if HID descriptor declares which ones of those are supported. as my current HID descriptor does not declare support for feature reports, i did not need to implement logic to handle those. feature reports are sent on control channel, not interrupt channel. this can be supported. i open both sockets for control and interrupt channel facing the input host device. on the input device side you need to utilise the hidraw interface capabilities - get and set feature report functions
   https://www.kernel.org/doc/Documentation/hid/hidraw.txt

but with all that in mind, it all should just work :)

[cocoonkid]

Thank you for your extensive elaboration! I will report when I tried it out in a few weeks.!