I've spent several days reverse engineering a Bluetooth compatibility issue between VMware Workstation and macOS Ventura.
This is not a normal Bluetooth support question. I've already gone well beyond typical troubleshooting and I'm hoping someone familiar with macOS Bluetooth internals, IOKit, DriverKit, BlueTool, or OpenCore may recognize what's happening.
Environment
Host:
Windows 11
Virtualization:
VMware Workstation
USB controller fixed at USB 3.2
USB passthrough enabled
VMware shared Bluetooth disabled
Guest:
macOS Ventura
Bluetooth USB Adapter:
USB VID/PID:
0A12:0001
Initially appears to be:
CSR8510 A10
However, after issuing raw HCI commands, the controller identifies itself as:
Bluetooth Manufacturer ID:
0x08E7
Barrot Technology Co., Ltd.
The device also reports:
USB revision:
0x8891
which matches Linux fake-CSR handling.
What has already been tested
This has already been verified:
✔ USB passthrough works
✔ VMware correctly passes the USB device into Ventura
✔ macOS detects the USB device
✔ Apple Bluetooth transport attempts to start
✔ Raw HCI communication works
Commands tested successfully:
HCI Reset
Read Local Version
Read Supported Commands
Read BD_ADDR
The adapter returns a valid Bluetooth address.
So the controller is definitely alive.
The actual problem
Despite the controller responding correctly,
Ventura never adopts it as the active Bluetooth controller.
Instead macOS reports something like
BCM_4350C2
Address:
NULL
No usable HCI controller becomes available.
Bluetooth never becomes functional.
OpenCore
Already tested.
BlueToolFixup was also investigated.
OpenCore itself does not appear to solve the problem.
From everything I've found, BlueToolFixup is not a Barrot compatibility layer.
What makes this interesting
The adapter is not actually CSR.
It is:
Barrot Technology
Manufacturer 0x08E7
while simultaneously exposing
VID 0A12
PID 0001
which mimics older CSR hardware.
Linux already contains fake-CSR handling for devices around:
bcdDevice 0x8891
which strongly suggests this controller requires a special initialization sequence.
Current hypothesis
The failure no longer appears to be:
VMware USB passthrough
USB permissions
HCI transport
the Bluetooth radio itself
Instead it appears to be somewhere between
AppleBluetoothUSBTransport
↓
BlueTool
↓
IOBluetoothHCIController
where Ventura refuses to register the controller after initial HCI communication.
What I'm looking for
Has anyone worked with:
Barrot Bluetooth controllers
fake CSR devices
Apple's Bluetooth transport
BlueTool
DriverKit Bluetooth transports
IOBluetoothFamily
USB Bluetooth initialization quirks
Specifically:
Has anyone successfully used a Barrot (0x08E7) controller under Ventura?
Does Apple reject Barrot after Read Local Version?
Is there already a transport patch somewhere?
Has anyone ported Linux's fake-CSR initialization to macOS?
Would DriverKit be the correct layer, or does this require patching Apple's Bluetooth transport?
Evidence collected
So far we've confirmed:
VMware USB 3.2 passthrough works.
USB 2.0 was ruled out because it breaks input devices, so testing continues with USB 3.2 only.
Raw HCI communication (Reset and Read BD_ADDR) was identified as the decisive diagnostic path, confirming the controller itself responds.
The investigation concluded the device identifies as Barrot Technology (0x08E7) while presenting the legacy CSR USB ID (0A12:0001), suggesting a fake-CSR implementation rather than genuine CSR hardware.
The proposed direction is to reproduce Linux's Barrot/fake-CSR initialization sequence because Apple's transport does not appear to handle this device automatically.
I'd be happy to share:
USB captures
HCI logs
Wireshark captures
Python HCI tools
VMware configuration
Reverse engineering notes
if anyone wants to investigate.
SOCIAL SHARE CARD GENERATOR