This solves a huge annoyance I've had: swap a Bluetooth keyboard/mouse between multiple laptops, without manually un0paring / re-pairing. I have a personal "hot desk" at home. I want to be able to plug in any laptop to the large monitor, and have the wireless keyboard/mouse on that desk instantly work. And when I leave the desk with my laptop, I don't want that keyboard/mouse connected anymore.
This has been impossible so far, because even USB bluetooth dongles still require each host computer to pair (and un-pair) with the keyboard/mouse.
I am going to try your solution, and I will plug the USB input into the large monitor on my desk. Then any laptop that plugs into that monitor should have access to the wireless keyboard/mouse. Thank you for creating and sharing this!
My pleasure, @reeddavid! I’m excited that you might find a use for it. Just a quick note: you may need an external power source for the RPi if you’re switching between devices frequently.
One popular request I’ve received is for certain RPi models (those with multiple USB ports as host) to act as a KVM, allowing them to serve as a USB host for multiple PCs simultaneously with easy switching—perhaps through shortcuts or physical buttons on the RPi. I’ll need to give it more thought, but it seems feasible with minimal changes. I already have some ideas for better state management for the devices!
many Bluetooth USB dongles have NVRAM, you can write the link key for a device (eg the keyboard or mouse) into the NVRAM and then when connecting, the dongle doesn't ask the Host computer for the key. I have used this to dual boot with a Bluetooth keyboard and mouse in the past.
I think the technique would be: pair in machine A (A has a link key). Then, pair again in machine B with the same dongle. Write that key into NVRAM, and machine A considers the device paired but it never gets asked for the key so just works if you plug the dongle into either machine. I don't know how the monitor thing works, does it act as a USB hub? I guess you can just leave the Bluetooth dongle plugged in there..
I've had many BT mouse and keyboards which supported multiple pairing profiles on the device. When I want to switch the device I just press a button on the mouse or keyboard and it's connected almost instantly.
Throwing more complexity at a simple problem might be "fun" from a nerd's POV, and, TBH, building this USB device sounds fun. But entirely unneeded while introducing more points of failure.
A simple solution to your problem:
1. Get a monitor with a built-in USB hub (nearly all of them?). Consider getting a USB-C monitor to reduce the number of cables to 1.
2. Don't use Bluetooth (for a keyboard, for multiple reasons, like needing the keyboard available in early boot). Get a keyboard/mouse with an external USB dongle like Logitech's Unify or Bolt, Corsair's SLIPSTREAM, or any of the other billion options that exist.
3. Plug keyboard/mouse into monitor, plug random computers into monitor. Bam. Unified mouse and keyboard without any pairing.
So your solution to solving one tiny flaw with the GP's otherwise-working setup is to... throw away their monitor, keyboard, and mouse, and spend lots of money (many times more money than an RPi-with-a-hat costs) to replace them?
All because you're offended by the complexity of... what?
• The idea of a device that acts as a stable host for Bluetooth devices, while presenting as a wired USB hub to an upstream USB host controller?
• The particular implementation here, which is a hacky proof-of-concept of the idea (and which could, in practice, be reduced to a single chip embedded into any USB-C-dock product if there was demand)?
• The entire concept of Bluetooth?
---
Also, I would like to point out that, given that this is HN, it's more than even odds that the GP:
• likely has multiple monitors (so using a monitor with a built-in hub is likely untenable);
• and also, that their laptops are probably Macbooks, and their mouse and keyboard are therefore very likely a Magic Keyboard and Magic Trackpad [for which there is no 1:1 substitute that does non-Bluetooth wireless while still having the same level of macOS support/integration];
• and that, given what they've said, they're likely already using a Thunderbolt hub to talk to those multiple monitors + all their USB devices through "one cable" (and all they really want is to add one more USB connection to this dock to make it act like a "Bluetooth dock" too);
• and that they likely have a big deep sit-stand desk, that they'd be cluttering/making it hard to put things on the 90% of the free "middle space" on, if they had to run actual wires from the keyboard and mouse over to the dock.
I did this for a while but was a bit annoyed with the delay since it "unplugs" and "plugs" in the mouse/keyboard each time you hit the button. What I ended up doing is buying a used KVM switch with DDM (https://en.wikipedia.org/wiki/Dynamic_device_mapping) which allows pretty much instant switching.
Be careful with these though, a lot of USB switches (most readily available ones, even) aren't wired correctly and can result in current flowing from one computer to the other.
Fun & cursed fact, the ArchWiki has a rather long section on dual boot pairing. Pair in Windows or Mac then painstakingly extract various bits of pairing info from the OS and toss it into Linux, so you can dual-boot & keep the pairing. https://wiki.archlinux.org/title/Bluetooth#Dual_boot_pairing
I've always wondered how feasible it would be to copy Bluetooth pairing information. This particular series of hacks seems to rest at least somewhat on it being the same Bluetooth host adapter. (But maybe the host side can spoof, trade IDs with the other device?)
Ideally I'd love to centrally and dynically manage what devices of mine are paired with what system... I think that might be technically feasible, as long as I'm not trying to pair multiple things with a single bt adapter.
This is brilliant! It just shows what can be done with the raspberry pi and other small computers, and some time! I love seeing stuff like this and the like. BlueSCSI is another example. If you think outside the box, the pi can act as a DPU, to an extent, for machines. It can already act as a KVM… and the PiKVM project has the option of mounting storage to the host, and even networking. Very cool stuff!
Quite probably, though there might be protocol latency issues that you need to be careful of and they might limit the effective range (lookup the “We can't send mail more than 500 miles” tale for a related issue!).
Well, you need a frame converter that sends it to an IP address/DNS server, and on the receiving side something that receives that packet on a specific port and translates it to a BT command.
I would say the most complicated part would be the TCP/IP stack, and binding/publishing your address, but if you are running something with Embedded Linux it is doable :)
> Note that while this component is named bluetooth_proxy, only BLE devices (and their Home Assistant integrations) are supported.
One specific use-case I have in mind is controlling a Chromecast over the internet. So a smartphone should have its bluetooth signal relayed over an IP network. I haven’t found anything that would allow me to do that yet.
Thank you, I'm glad you're finding this inspiring. I've been thinking about some similar ideas that excite me. Would be happy to help as well if you ran into any blockers.
Magic Trackpad 2 and (Mac) Magic Keyboards appear as USB HID devices when connected to a computer via Lightning-to-USB (-A or -C) cable.
One annoyance is that macOS automatically Bluetooth pairs with these devices when connected via USB, overwriting any existing pairing, but this shouldn't matter for purely wired scenarios.
For switching Bluetooth devices more generally, observe that most Bluetooth controllers are USB devices; with a bit of effort — mostly just copy/pasting the device pairing keys across all connected hosts — they can be switched just like any other USB peripheral (YMMV with "intelligent" USB KVM switches that virtualize USB HID device connections).
IME the connection delay is a couple seconds longer than switching wired USB HID devices directly, but entirely reasonable for typical KVM use cases.
Note here that "most Bluetooth controllers are USB devices" even extends to internal Wi-Fi/Bluetooth combo cards, which are commonly M.2 key A or E (= PCIe + USB 2.0 + …), or M.2 key A or E preinstalled on a mostly passive PCIe adapter, with a separate cable connection to a USB port or motherboard USB header used exclusively for Bluetooth.
This turns out to be a surprisingly useful implementation detail: on one of my work desktops, I'm currently virtual USB-switching the Bluetooth controller on an Intel BE200 PCIe card between a Linux host and a Windows VM running on that host, while keeping Wi-Fi connected to the host.
I have a matching hot key set up in each OS to attach/detach the Bluetooth controller from the VM and simultaneously DDC switch the monitor input between the host (iGPU) and guest (PCIe dGPU passthrough), and it works great.
Coincidentally, the Bluetooth devices I'm using in this configuration are a Magic Trackpad 2, a Magic Keyboard, and a Magic Mouse (the mouse was the motivation for using Bluetooth over USB in the first place, as, unlike the other Apple input devices, it's physically impossible to use when connected via USB).
Have you tried usb? My Magic Trackpad and keyboard work fine without BT on both windows and pop os. Would love a way to actually disable the radios though.
But — using a Raspberry Pi and Linux is overkill for this. It introduces huge unnecessary complexity. A simpler approach would be to go with Zephyr and a small microcontroller (ARM Cortex M4).
I think that's a fair point about potentially wasted resources, something like Pico would have been and a leaner choice if this was going to be mass-produced. But for me, part of the decision was my comfort level with system programming and what I desired to tinker with and learn along the way and still, it's a very affordable option (around 20 CAD I believe)
Perhaps I'll look into porting it to Pico in future as new challenge and learning experience. Thank you for your sharing your thoughts.
I had same worries like yours but worry not, check MicroPython/CircuitPython when you get a chance. You load it up onto Pico and play with REPL in IDE. It is easier than debugging Go on large-RPi.
Please don't get me wrong: I really do appreciate the hack value and I absolutely understand choosing this route to scratch a personal itch!
My point was more general: I see a lot of things getting built using Linux that really have no need for this level of complexity. And it doesn't come free: complex systems are more fragile, there are more things that can go wrong.
In this particular case, I'd recommend taking a look (for example) at the Seeed XIAO nRF52840 module and Zephyr: around $10, very capable CPU, very good Bluetooth stack (Zephyr+Nordic), USB-C connector.
Ooh, one thing that can be very useful for this is sending USB wakeup packets. I have an HTPC under my TV and game controllers (PS4, Xbox) at my coffee table and there is no way to wake up the PC with those over Bluetooth so I have to keep it on and idling at all times, wasting electricity.
If you have a wired connection to the box you should be able to use wake on lan from a phone (this is what I used to do, now homeassistant took over this responsibility).
Damned, I just purchased a new keyboard with a 2.4 GHz dongle because my Bluetooth keyboard cannot with GRUB and I got tired of having to plug it in every time I rebooted.
What a cool little project. I might build a couple of these for the KVMs at work.
This is very cool. I have a Kinesis Freestyle2 Blue for Mac that keep having repeating key issue when paired with my Macbook. The Kinesis CS unhelpfully blame Apple's BT stack implementation and offered no solution. I never had issues with the keyboard when connected to a Linux machine, so this will work nicely for my home office setup!
I'm assuming this also works with Pi Zero 2 W? (The repo only mention the original Zero W)
You can, of course, DIY something easily enough but you can also purchase devices like this off the shelf. Needing to make legacy RS232 devices wirelessly available is a common problem in industry. Search for "wireless RS232 gateway" and you should be able to find a ton of stuff.
If you still want to DIY, an ESP32 (BLE and Wi-Fi capable microcontroller) board, and an RS232 to logic-level breakout board should be all you need. Again, I'm sure if you search, you'll find existing projects doing exactly this.
You may find esp-link interesting: https://github.com/jeelabs/esp-link
I've built a WiFi<->RS232 bridge using the firmware, ESP8266 and a UART<->RS232 converter module.
All hardware is very cheap.
I can't find definitive information for RPi 4 though, I see some references to using it online but the spec here does not seem to mention USB host or OTG
I once plugged my personal phone into the USB port of a random machine in the office to get a quick charge, and a guy from Information Security showed up in under ten minutes ready to have a heart attack.
The reasoning I’ve heard is that Bluetooth traffic is easily snoopable without physical access to the device. Someone could potentially steal password keystrokes while sitting outside the office building, on the other side of a window with the shades drawn, whereas with USB you still need to get past the physical security and be at their desk.
As someone who uses Bluetooth headphones on a Switch and gaming PC from time to time, it's generally not a great experience. Computers and phones and what not compensate for the delay often for video sources, but low latency gaming can become noticeable for things like SBC and what not. Those proprietary wireless headphones are doing a lot to try and optimize the latency.
Out of curiosity, do you think this concept could be extended to other common bluetooth use cases, such as wireless headphones/speakers, or file transfers over bluetooth to mobile devices, or are the audio/file transfer/etc stacks too far removed from the HID stack for that to cleanly translate?
Great question. I can see this being fairly easily extendable to other HID devices and even modifying their behaviour slightly (e.g. remapping a key) but audio stack sounds like (no pun intended) a different beast altogether. A buddy of mine had a similar question around connecting his BT gamepad and headset to play PS games on PC so I'll be looking into this more.
I'd love to see something like this but the other way around - a native implementation of a Bluetooth mouse and keyboard in either Android, an iPhone or a RPi with a touchscreen. It would make life in a server rack so much easier if I didn't have to lug around a physical keyboard and mouse...
Oh interesting, I can see how something like that would be useful for myself as well.
I think you just gave me some good ideas for future projects as I have a few ideas around using Bluetooth in React Native apps and potentially amalgamating them with Single-board computers. Thank you!
Excuse the dumb question, but could I then pair this with OP's project, to give myself a USB wireless keyboard and mouse while only carrying my phone and a Pi Zero 2 W?
Blackberries could do that, I think it was called Blackberry Connect or something like that. I used to use my Bold as a keyboard for my laptop when it was parked next to the projector.
> This project was born out of a desire to help a friend who couldn't use his favorite Bluetooth mouse and keyboard due to Bluetooth being disabled on his work laptop.
Protip: If their company's IT section is like the one at my old company, they are quite unlikely to like this solution, either.
IT departments that are too restrictive will soon find that people have a parallel world executing in Excel sheets and using some external messaging app to keep the company operations running despite IT efforts to ensure it doesn't - I mean to ensure it is "secure"...
My CTO is quite adamant that he hates shadow IT. Especially those with mac, full of... well software used by those artsy employees. Or with strange software not validated by the IT.
Well.
Other departments ask for equipment, but only hear no back. Management product like Monday? No. Dedicated solution for jobs they don't understand? Hell no!
It's tough to be part of this. I know security is hard. Budget limit stuff. But we can, and should do better.
As someone who has worked in IT support: The problem is that people using that shadow IT will come running when they produce real tangible damage, because they lose data or some totally ridculous workflow stops working and you now have to reverse engineer some undocumented database format to extract at least the most urgent data. I am not a fan of IT GESTAPO, and everything should be measured, butbif I learned one thing it is that people will do the dumbest, riskiest shit if left tontheir own devices.
Also: if you work with certain customer data a good way to not only loose your job, but a ton of money would be to e.g. put that data into your shadow IT that might be running on some servers somewhere. E.g. people constantly asked us to use Zoom "because it is free and works", but we were in the public sector and a contract with them that guaruantueed the privacy of our clients would have costed a significant fraction of our yearly IT budget — and we are required by law to have such a contract.
When you then ask those people if they want to part with that money suddenly nobody is so adamant anymore.
This is true. I suspect that a lot of these massive breaches, was because some less-technical person loaded the customer data onto an unsecured AWS instance, while they were running measurements on it.
My company is the same, but it's not necessarily about it being "hard." It's about not hiring the right people.
My company's IT department is Windows clickops people who hire other Windows clickops people. When something goes wrong that requires the command line, they spend five figures on a consultant to fix it. Ditto for the few dozen Linux machines in the company.
Some of our departments, including mine, run Macs. I can't count the number of times I've had someone from IT tell me "OK, now click 'Start'…" or whatever the Windows convention is these days.
All they'd have to do is hire one guy who knows the command line, and one guy who knows how to support Macs. There must be a hundred people in the IT department, but they keep hiring the same type of people over and over.
I wish it was unique to my company, but there was an identical situation where I worked a few years ago.
Thank you for sharing your thoughts, I had thought about this as well but came to the conclusion that from the company's perspective, this is no different than connecting a random keyboard bought from Amazon, what do you think?
Another thought around this is that I don't even think there's anything intrinsically insecure about BT as an attack vector but most likely some old policy based on security issues that existed in the early days of Bluetooth. Or at least I don't know of any, but I'm no expert in this so I would love to hear other people's insights here.
Secure bluetooth requires manufacturers to get the cryptography right. Even big brands like Logitech have gotten that wrong in recent memory, allowing attackers both to decrypt what you type [1] and to inject keystrokes [2]. And these are long-lived devices, even if vulnerabilities get patched in newer devices there are still plenty of 5 year old or older mice and keyboards with outdated firmware floating around. Not to mention the possibility of 0-days known to your attacker.
Wired connections are inherently more difficult to attack. In security critical applications banning bluetooth is perfectly reasonable.
I'm always a proponent of just spending some money on your office equipment. Even a $90 mouse and $200 keyboard costs less than a tenth of a percent of salary of an average office worker, never mind developer (amortized over a very conservative 5 year lifespan). Give people the option to choose between 2-3 sanctioned models, throw in some vertical mice and split keyboard options and you can even brag about how much you care about your employees' health.
Some people will always want to bring their own equipment, but a lot of it is caused by penny pinching or lack of options
> Give people the option to choose between 2-3 sanctioned models
It quickly grows past the 2-3 sanctioned models. Everyone wants something not on the list, lots of bickering of "why was that model chosen?", etc. Well that pre-approved model is $150, this is only $175. Bob got that $175 model, this is only $200, it's not that much. Jenny got that $200 model, this is only $250. Jenny's got a $250 keyboard? I gotta upgrade, here's this $300 model... Wait did the company just buy Bill a 55" 4K display? I need that too...
Suddenly your $150/person budget has exploded to replace everyone's equipment for $1,000+ otherwise it's just not fair someone else got more.
Personally I'm fine with me buying and owning my own kb+m. Maybe give a once a year or two office hardware stipend or whatever. Then otherwise make basic stuff available for free. If you're wanting a $200 keyboard you're probably wanting a particular $200 keyboard, and it's probably not one of those 2-3 approved models.
In my experience, the IT section didn't trust anything they didn't approve, themselves. They certainly wouldn't allow us to buy any random device from Amazon.
In my experience, I just never asked for permission when I was going to work around an annoying policy. I think while the company IT department will not love you, as long as you don't show up in one of their dashboards, it's pretty unlikely they will care. For years. Even if someone does bug you, I doubt it will amount to much other than being forced to adhere to the policy. As long as you ensure it doesn't look too much like you did it on purpose. (I would at least recommend a nice case for the device and picking innocuous USB IDs. Might be able to make it seem like a reasonable looking product, like a normal wireless keyboard receiver.)
Remote work at startups has largely removed my need for this kind of behavior. Now I'm mostly just mad that I can't always run Linux at work anymore.
> In my experience, I just never asked for permission when I was going to work around an annoying policy.
Same here, though I've never been in a significantly restrictive place with no authority (in current long-term DayJob I have some involvement in decisions wrt what restrictions are appropriate, and what exceptions to them are appropriate).
If someone is in a truly restrictive environment, they should take care. A deliberate breach of policy could be a job terminating excuse, or at least further justification, if someone wants them out of the way for any other reason, and in such circumstances a workaround and a breach will be seen in the same light.
The irony of it is that these types love to then support software and hardware that is full of vulnerabilities. "Oh, our management software/SSL-VPN has just been pwned for the sixth time in two years? Well at least the vendor has a fix and the security team can deal with the problem!" or "well our infrastructure is so poorly managed that a single Bluetooth device could, in fact, take over the whole company!"
It's a USB device that types stuff sent through the air into the computer. For example, if the BT keyboard is vulnerable, you just opened a door for an attacker to remotely type things into the company laptop. I don't think it has the same risk profile as a wired keyboard
Exactly the same as what this device is doing, plus more. You would put it in HCI mode, pair whichever Bluetooth devices you wanted to pair with it (keyboards, mice, etc.). Then on the next reboot it would put itself back into HID mode, where all the paired devices would appear as USB HID devices. And therefore your keyboard would be available even during pre-boot, at the BIOS setup program.
Once the operating system finished loading, it would send the adapter the command to switch to HCI mode, and the adapter would then re-appear as a normal bluetooth adapter. Under BlueZ, this operation was done by a command called hid2hci.
I have several (even Apple used to do this), but they stopped being a thing during the 2.0 EDR era (therefore zero support for LE keyboards).
In fact, if you google these keywords ("HID proxy", "HID2HCI", ...) you will find that there are several much older projects to also replicate this using RPi Zeros. I personally would like one which extends the concept to audio devices, serial ports, etc. so that I can use them from OSes without BT stack.
This has been impossible so far, because even USB bluetooth dongles still require each host computer to pair (and un-pair) with the keyboard/mouse.
I am going to try your solution, and I will plug the USB input into the large monitor on my desk. Then any laptop that plugs into that monitor should have access to the wireless keyboard/mouse. Thank you for creating and sharing this!
One popular request I’ve received is for certain RPi models (those with multiple USB ports as host) to act as a KVM, allowing them to serve as a USB host for multiple PCs simultaneously with easy switching—perhaps through shortcuts or physical buttons on the RPi. I’ll need to give it more thought, but it seems feasible with minimal changes. I already have some ideas for better state management for the devices!
I think the technique would be: pair in machine A (A has a link key). Then, pair again in machine B with the same dongle. Write that key into NVRAM, and machine A considers the device paired but it never gets asked for the key so just works if you plug the dongle into either machine. I don't know how the monitor thing works, does it act as a USB hub? I guess you can just leave the Bluetooth dongle plugged in there..
My current keyboard:
https://www.logitech.com/en-us/products/keyboards/mx-mechani...
https://gist.github.com/madkoding/f3cfd3742546d5c99131fd19ca...
Throwing more complexity at a simple problem might be "fun" from a nerd's POV, and, TBH, building this USB device sounds fun. But entirely unneeded while introducing more points of failure.
A simple solution to your problem:
1. Get a monitor with a built-in USB hub (nearly all of them?). Consider getting a USB-C monitor to reduce the number of cables to 1.
2. Don't use Bluetooth (for a keyboard, for multiple reasons, like needing the keyboard available in early boot). Get a keyboard/mouse with an external USB dongle like Logitech's Unify or Bolt, Corsair's SLIPSTREAM, or any of the other billion options that exist.
3. Plug keyboard/mouse into monitor, plug random computers into monitor. Bam. Unified mouse and keyboard without any pairing.
All because you're offended by the complexity of... what?
• The idea of a device that acts as a stable host for Bluetooth devices, while presenting as a wired USB hub to an upstream USB host controller?
• The particular implementation here, which is a hacky proof-of-concept of the idea (and which could, in practice, be reduced to a single chip embedded into any USB-C-dock product if there was demand)?
• The entire concept of Bluetooth?
---
Also, I would like to point out that, given that this is HN, it's more than even odds that the GP:
• likely has multiple monitors (so using a monitor with a built-in hub is likely untenable);
• and also, that their laptops are probably Macbooks, and their mouse and keyboard are therefore very likely a Magic Keyboard and Magic Trackpad [for which there is no 1:1 substitute that does non-Bluetooth wireless while still having the same level of macOS support/integration];
• and that, given what they've said, they're likely already using a Thunderbolt hub to talk to those multiple monitors + all their USB devices through "one cable" (and all they really want is to add one more USB connection to this dock to make it act like a "Bluetooth dock" too);
• and that they likely have a big deep sit-stand desk, that they'd be cluttering/making it hard to put things on the 90% of the free "middle space" on, if they had to run actual wires from the keyboard and mouse over to the dock.
I've always wondered how feasible it would be to copy Bluetooth pairing information. This particular series of hacks seems to rest at least somewhat on it being the same Bluetooth host adapter. (But maybe the host side can spoof, trade IDs with the other device?)
Ideally I'd love to centrally and dynically manage what devices of mine are paired with what system... I think that might be technically feasible, as long as I'm not trying to pair multiple things with a single bt adapter.
Quite probably, though there might be protocol latency issues that you need to be careful of and they might limit the effective range (lookup the “We can't send mail more than 500 miles” tale for a related issue!).
I would say the most complicated part would be the TCP/IP stack, and binding/publishing your address, but if you are running something with Embedded Linux it is doable :)
https://esphome.io/components/bluetooth_proxy.html
> Note that while this component is named bluetooth_proxy, only BLE devices (and their Home Assistant integrations) are supported.
One specific use-case I have in mind is controlling a Chromecast over the internet. So a smartphone should have its bluetooth signal relayed over an IP network. I haven’t found anything that would allow me to do that yet.
https://www.techspot.com/review/420-hp-wifi-mouse/
Would this work? I’d buy one. I currently have to use Synergy to share peripherals between two MacBooks.
One annoyance is that macOS automatically Bluetooth pairs with these devices when connected via USB, overwriting any existing pairing, but this shouldn't matter for purely wired scenarios.
For switching Bluetooth devices more generally, observe that most Bluetooth controllers are USB devices; with a bit of effort — mostly just copy/pasting the device pairing keys across all connected hosts — they can be switched just like any other USB peripheral (YMMV with "intelligent" USB KVM switches that virtualize USB HID device connections).
IME the connection delay is a couple seconds longer than switching wired USB HID devices directly, but entirely reasonable for typical KVM use cases.
Note here that "most Bluetooth controllers are USB devices" even extends to internal Wi-Fi/Bluetooth combo cards, which are commonly M.2 key A or E (= PCIe + USB 2.0 + …), or M.2 key A or E preinstalled on a mostly passive PCIe adapter, with a separate cable connection to a USB port or motherboard USB header used exclusively for Bluetooth.
This turns out to be a surprisingly useful implementation detail: on one of my work desktops, I'm currently virtual USB-switching the Bluetooth controller on an Intel BE200 PCIe card between a Linux host and a Windows VM running on that host, while keeping Wi-Fi connected to the host.
I have a matching hot key set up in each OS to attach/detach the Bluetooth controller from the VM and simultaneously DDC switch the monitor input between the host (iGPU) and guest (PCIe dGPU passthrough), and it works great.
Coincidentally, the Bluetooth devices I'm using in this configuration are a Magic Trackpad 2, a Magic Keyboard, and a Magic Mouse (the mouse was the motivation for using Bluetooth over USB in the first place, as, unlike the other Apple input devices, it's physically impossible to use when connected via USB).
https://github.com/gdsports/usbhostcopro
But — using a Raspberry Pi and Linux is overkill for this. It introduces huge unnecessary complexity. A simpler approach would be to go with Zephyr and a small microcontroller (ARM Cortex M4).
I think that's a fair point about potentially wasted resources, something like Pico would have been and a leaner choice if this was going to be mass-produced. But for me, part of the decision was my comfort level with system programming and what I desired to tinker with and learn along the way and still, it's a very affordable option (around 20 CAD I believe)
Perhaps I'll look into porting it to Pico in future as new challenge and learning experience. Thank you for your sharing your thoughts.
My point was more general: I see a lot of things getting built using Linux that really have no need for this level of complexity. And it doesn't come free: complex systems are more fragile, there are more things that can go wrong.
In this particular case, I'd recommend taking a look (for example) at the Seeed XIAO nRF52840 module and Zephyr: around $10, very capable CPU, very good Bluetooth stack (Zephyr+Nordic), USB-C connector.
> A delightfully over-engineered solution
What a cool little project. I might build a couple of these for the KVMs at work.
I'm glad you might find this useful, be sure to create an issue on GH in case you run into any and I'll try my best to help :)
I'm assuming this also works with Pi Zero 2 W? (The repo only mention the original Zero W)
e.g. https://www.aliexpress.com/item/33010159305.html?spm=a2g0o.p...
If you still want to DIY, an ESP32 (BLE and Wi-Fi capable microcontroller) board, and an RS232 to logic-level breakout board should be all you need. Again, I'm sure if you search, you'll find existing projects doing exactly this.
If it's not actually at RS232 voltage levels and Classic Bluetooth is enough, then something like this will work just fine: https://www.amazon.com/Wireless-Bluetooth-Transceiver-Integr...
https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/ https://www.raspberrypi.com/products/raspberry-pi-zero-w/
I can't find definitive information for RPi 4 though, I see some references to using it online but the spec here does not seem to mention USB host or OTG
https://www.raspberrypi.com/products/raspberry-pi-4-model-b/...
I gotta test how this works with the Magic Trackpad. IIUC Magic Trackpad does something non standard to achieve smooth scroll.
I once plugged my personal phone into the USB port of a random machine in the office to get a quick charge, and a guy from Information Security showed up in under ten minutes ready to have a heart attack.
Thank you!
Great work Bahador.
Out of curiosity, do you think this concept could be extended to other common bluetooth use cases, such as wireless headphones/speakers, or file transfers over bluetooth to mobile devices, or are the audio/file transfer/etc stacks too far removed from the HID stack for that to cleanly translate?
Great question. I can see this being fairly easily extendable to other HID devices and even modifying their behaviour slightly (e.g. remapping a key) but audio stack sounds like (no pun intended) a different beast altogether. A buddy of mine had a similar question around connecting his BT gamepad and headset to play PS games on PC so I'll be looking into this more.
That’s where this relay comes in—it bridges Bluetooth to USB, so you can still use your devices.
It should work anywhere a USB keyboard works, realistically.
Protip: If their company's IT section is like the one at my old company, they are quite unlikely to like this solution, either.
But it's very clever. Kudos.
Well.
Other departments ask for equipment, but only hear no back. Management product like Monday? No. Dedicated solution for jobs they don't understand? Hell no!
It's tough to be part of this. I know security is hard. Budget limit stuff. But we can, and should do better.
Also: if you work with certain customer data a good way to not only loose your job, but a ton of money would be to e.g. put that data into your shadow IT that might be running on some servers somewhere. E.g. people constantly asked us to use Zoom "because it is free and works", but we were in the public sector and a contract with them that guaruantueed the privacy of our clients would have costed a significant fraction of our yearly IT budget — and we are required by law to have such a contract.
When you then ask those people if they want to part with that money suddenly nobody is so adamant anymore.
We had all kinds of scary tech, like custom-compiled metrics software from Intel.
They insisted that all of our machines run their malwa- er, security software.
It would totally screw up our measurements.
My company's IT department is Windows clickops people who hire other Windows clickops people. When something goes wrong that requires the command line, they spend five figures on a consultant to fix it. Ditto for the few dozen Linux machines in the company.
Some of our departments, including mine, run Macs. I can't count the number of times I've had someone from IT tell me "OK, now click 'Start'…" or whatever the Windows convention is these days.
All they'd have to do is hire one guy who knows the command line, and one guy who knows how to support Macs. There must be a hundred people in the IT department, but they keep hiring the same type of people over and over.
I wish it was unique to my company, but there was an identical situation where I worked a few years ago.
Love this!
Another thought around this is that I don't even think there's anything intrinsically insecure about BT as an attack vector but most likely some old policy based on security issues that existed in the early days of Bluetooth. Or at least I don't know of any, but I'm no expert in this so I would love to hear other people's insights here.
Wired connections are inherently more difficult to attack. In security critical applications banning bluetooth is perfectly reasonable.
[1] https://www.youtube.com/watch?v=GRJ7i2J_Y80
[2] https://www.youtube.com/watch?v=EksyCO0DzYs
The best way to correctly fight Shadow IT is to provide equipment and services so good nobody would even care using something else.
Some people will always want to bring their own equipment, but a lot of it is caused by penny pinching or lack of options
It quickly grows past the 2-3 sanctioned models. Everyone wants something not on the list, lots of bickering of "why was that model chosen?", etc. Well that pre-approved model is $150, this is only $175. Bob got that $175 model, this is only $200, it's not that much. Jenny got that $200 model, this is only $250. Jenny's got a $250 keyboard? I gotta upgrade, here's this $300 model... Wait did the company just buy Bill a 55" 4K display? I need that too...
Suddenly your $150/person budget has exploded to replace everyone's equipment for $1,000+ otherwise it's just not fair someone else got more.
Personally I'm fine with me buying and owning my own kb+m. Maybe give a once a year or two office hardware stipend or whatever. Then otherwise make basic stuff available for free. If you're wanting a $200 keyboard you're probably wanting a particular $200 keyboard, and it's probably not one of those 2-3 approved models.
It sucked. Big time, but they had the clout.
Remote work at startups has largely removed my need for this kind of behavior. Now I'm mostly just mad that I can't always run Linux at work anymore.
Same here, though I've never been in a significantly restrictive place with no authority (in current long-term DayJob I have some involvement in decisions wrt what restrictions are appropriate, and what exceptions to them are appropriate).
If someone is in a truly restrictive environment, they should take care. A deliberate breach of policy could be a job terminating excuse, or at least further justification, if someone wants them out of the way for any other reason, and in such circumstances a workaround and a breach will be seen in the same light.
This was especially true for memory sticks, but keyboards, and even bus-powered things like fans (or nerf turrets) would get banned.
They had the power to get you fired, if you crossed them.
They did not like my team, because we were the only ones in the building, that knew what bullshitters they were.
Once the operating system finished loading, it would send the adapter the command to switch to HCI mode, and the adapter would then re-appear as a normal bluetooth adapter. Under BlueZ, this operation was done by a command called hid2hci.
I have several (even Apple used to do this), but they stopped being a thing during the 2.0 EDR era (therefore zero support for LE keyboards).
In fact, if you google these keywords ("HID proxy", "HID2HCI", ...) you will find that there are several much older projects to also replicate this using RPi Zeros. I personally would like one which extends the concept to audio devices, serial ports, etc. so that I can use them from OSes without BT stack.