search

zmkfirmware / zmk

ZMK Firmware Repository
https://zmk.dev/
MIT License
2.78k stars 2.81k forks source link

can ZMK make Bluetooth keyboard enter BIOS? #1265

Open fkpwolf opened 2 years ago

fkpwolf commented 2 years ago

Device is nRF52840. I checked Zephyr and didn't find releated topic.

is any info about that?

If I want to add support for it, where can I start from?

joelspadin commented 2 years ago

ZMK supports BLE, which is 2.4 GHz. Is there a specific protocol that you mean instead?

fkpwolf commented 2 years ago

@joelspadin some keyboards support 3 models: wired, BLE & 2.4G.

So for nRF52840, "It has protocol support for Bluetooth LE, Bluetooth mesh, Thread, Zigbee, 802.15.4, ANT and 2.4 GHz proprietary stacks.". I am not sure if ZMK supports the 2.4G protocal.

petejohanson commented 2 years ago

There are a few other protocols on top of 802.15.4 that exist, in particular Nordic has the Gazelle protocol they support, but it is only available in the Nordic Connect SDK (NCS), which has a license that is not conducive to us using it (it requires if you use NCS to only use it on their hardware, so is not open source friendly).

So, yes, theoretically possible, no, not likely to ever been in ZMK any time soon given the licensing challenges, or technical challenges involved in doing so in a way that is both efficient and secure.

Also, any such thing is likely to to squeeze out a few milliseconds, so there's the level of effort compared to the gains makes it something I have no interest personally in pursuing.

I'd rather we support "dongle mode" over BLE itself, which might allow a "unified receiver"-esque experience, without the technical baggage/challenges.

Nicell commented 2 years ago

Also, any such thing is likely to squeeze out a few milliseconds, so there's the level of effort compared to the gains makes it something I have no interest personally in pursuing.

To elaborate on the few milliseconds, once we have dongle mode, we'll be able to get latency down to about 4.25ms on average. (0.5ms USB transfer with 1000hz polling plus 3.75ms average BLE transfer with 7.5ms period). We'd really only be eliminating at most 3.5ms with a custom protocol, which would also take a lot of work as Pete mentioned.

fkpwolf commented 2 years ago

thanks for explanation. To me, the best part of 2.4G with dongle is that I can operation BIOS to choose different OS. And I can use keyboard on desktop machine which has no Bluethooth.

Looks the 2.4G RF is not standard and binds to MCU vendor. To implement it, may have to merge ZMK code and vendor SDK.

"dongle mode" over BLE is good idea. Hope this mode have easy way to pair keyboard and dongle.

xbliss commented 2 years ago

thanks for explanation. To me, the best part of 2.4G with dongle is that I can operation BIOS to choose different OS. And I can use keyboard on desktop machine which has no Bluethooth.

Looks the 2.4G RF is not standard and binds to MCU vendor. To implement it, may have to merge ZMK code and vendor SDK.

"dongle mode" over BLE is good idea. Hope this mode have easy way to pair keyboard and dongle.

This is kind of the issue with BLE that the PC system cannot respond, to the Keyboard or Mouse without OS + Driver having been loaded to run the BLE.

Which is where the Dongle is usable at BIOS as a fixed working link pre-OS boot.

That's definitely an area to look at developing open source "common" framework?

I wonder if a pre-boot common framework can be garnered from commonalities/ overlaps of the various "vendor" dongles.?

fkpwolf commented 2 years ago

thanks for explanation. To me, the best part of 2.4G with dongle is that I can operation BIOS to choose different OS. And I can use keyboard on desktop machine which has no Bluethooth. Looks the 2.4G RF is not standard and binds to MCU vendor. To implement it, may have to merge ZMK code and vendor SDK. "dongle mode" over BLE is good idea. Hope this mode have easy way to pair keyboard and dongle.

This is kind of the issue with BLE that the PC system cannot respond, to the Keyboard or Mouse without OS + Driver having been loaded to run the BLE.

Which is where the Dongle is usable at BIOS as a fixed working link pre-OS boot.

That's definitely an area to look at developing open source "common" framework?

I wonder if a pre-boot common framework can be garnered from commonalities/ overlaps of the various "vendor" dongles.?

Looks it is HID proxy mode as this topic shows https://www.0xf8.org/2014/02/the-crux-of-finding-a-hid-proxy-capable-usb-bluetooth-adapter/

205g0 commented 2 years ago

with 7.5ms period

@Nicell check https://www.rtings.com/keyboard/tests/latency, scroll down, sort the list by "Latency Bluetoth". Only the top three boards (gaming keyboards) have 7.x ms latency, then very few around 10ms. The most average around 15ms to 20ms.

Would love to see 7.5ms with ZMK in real life.

We'd really only be eliminating at most 3.5ms

Now, sort the same list by "Latency Receiver" and a few front runners average around 1ms latency. That would be still 6ms faster than the fastest Bluetooth board, so more than 3.5ms.

Not sure if I read the numbers right, but rtings latency measurement is ok-ish (there's a YT video explaining), could be better though.

However, I wonder where I can learn more about 2.4G non-Bluetooth stacks? I've checked this Gazell Protocol @petejohanson mentioned but found "240Hz puls" in their specs, not sure if this is similar to polling rate. If yes, this seems to be to slow.

lesshonor commented 3 months ago

With the addition of CONFIG_ZMK_USB_BOOT and a BLE-based "dongle mode" now possible (potential documentation PR in #2401) this issue would appear to be resolved.

The implementation of any bespoke or proprietary 2.4GHz communication protocols is a separate subject, and given previous messages not one ZMK is likely to do much with.