|
|
|
|
|
|
by evoke4908
576 days ago
|
|
|
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. |
|
|
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.