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?
Probably just a "it's hard for little pay-off" 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.
> 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.
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.
I don't think the other comments in this thread are at all correct. This is not a hard problem to solve and these comments vastly overcomplicate it.
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.
In fact, quite recently there was a Show HN showing a "appears-as-USB-HID" Bluetooth adapter: https://news.ycombinator.com/item?id=42125863 . The only thing missing was the hid2hci part.
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.
These do essentially exist in dongle form, though you'd need some kind of driver support to get rid of the physical pairing button: https://handheldsci.com/kb/
Mostly it's a cost/ease thing. For the device to work correctly with no OS, the hardware inside has to be powerful enough to run all of the logic itself and it has to be coded up to do that.
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.
nucleardog|1 year ago
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.
AshamedCaptain|1 year ago
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.
evoke4908|1 year ago
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.
AshamedCaptain|1 year ago
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.
Groxx|1 year ago
kadoban|1 year ago
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.
AnotherGoodName|1 year ago
You still need to check if your motherboard supports Bluetooth at boot but many do.
AshamedCaptain|1 year ago