I really miss the feature of CSR devices that allowed keyboard and mouse use before OS boot, and wish any modern Bluetooth receiver was capable of it. Is it a patent issue?
To use a bluetooth keyboard from the stage of "Press F10 to Enter Setup" we need the firmware (whether BT host, mainboard, or something else) to have a full bluetooth stack, some way to manage pairing/unpairing devices, and a bunch of other stuff.
If we do this outside the BT host, we probably need changes to the operating systems at least to handle how we're going to hand-off the state of the bluetooth stack when the OS takes control. Unless we want to _separately_ manage pairing/unpairing in the firmware, we would probably want some way to expose that to the operating system to be able to push its paired devices down.
And then it's probably still not super useful unless we substantially lengthen the prompt time because the time for you to turn the keyboard on, coax it into connecting, and hit the button is gonna probably have the OS booted already.
If you want this today just don't use bluetooth. Get one of the devices that uses "2.4GHz" or uses "Bluetooth + 2.4GHz" and shove a dongle in there. The keyboard/mouse will appear as a normal USB-connected device and you can use them how you want.
During the CSR hid2hci era, the adapter would just remember the last N pairings, since a sufficiently smart adapter can technically just store the keys used by the host when it tries to pair, then "impersonate" the host during the HCI part.
You need two things: 1) a processor which can present HID devices OR a Bluetooth adapter depending on the presence of 2) a driver which can inform the adapter when it should be in BT mode instead of the default HID and which can configure the firmware to auto-connect to which devices in HID mode.
The first is easy and effecively free. The USB stack is (usually) implemented in firmware which makes it trivial to present as different device classes.
My guess is the problem comes down to drivers. It is difficult and quite expensive to have a custom driver upstreamed to Windows Update. You can't do this without a custom driver or userland software. On the other hand, if you simply present as a generic BT adapter, windows has a generic driver that will (usually) always work and is always installed.
The benefit of this feature is miniscule and there probably is not enough demand to make it worthwhile for CSR to sell their soul to Microsoft to have their driver blessed.
In this day and age, almost nobody ships a custom driver for anything. You just use the generic drivers Windows already has for all standard device types.
While I was posting in that thread I also noticed there are a gazillion attempts in github to do something like this, so complicated it is not.
If you wait until the OS is up, the device itself can offload a good amount of logic and processing to the device driver.
My bet would be that the main reason is that it's easier to find programmers who can write complex device drivers than it is to find ones who can write complex embedded firmware, and it's quicker/easier in general to write device drivers than firmware.
That and just 99% of people will never notice that it doesn't work outside of the OS, and of the rest, 99% will only be vaguely annoyed but not change brands over that.
You still need to check if your motherboard supports Bluetooth at boot but many do.