Bluetooth Stack Improvements - End User reports

Ahoy @vighnesh-sawant, @mohammedrattia, @delphi20, @shivamsingh, @sayeed_1 !

Actually I do not know which one of you will be selected for GSoC 2026 - maybe all of you !

I assume you will communicate about development - and maybe status of your work via those topics you opened for introduction and possibly Blog-O-Sphere blog posts.

This thread was opened with different goal.

Actually I’m on Haiku x86_64 , hrev59601.If I start Bluetooth service

No local device detected -

This way my primal target is to Haiku detect my Broadcom device on USB bus.

My Dell Precision M6800 has an 4th Gen Intel i7 4800MQ CPU

and

Here you are my device list (HD Audio, EHCI, XHCI , ETH, WLAN [this Broadcom wifi actually not supported yet] - that can be important informations for the several BT services ) to decide for which services I can do a test for you :

  user  ~   23:27    listdev

device Bridge (Host bridge) [6|0|0]
vendor 8086: Intel Corporation
device 0c04: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 0c01: Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
vendor 1002: Advanced Micro Devices, Inc. [AMD/ATI]
device 6640: Saturn XT [FirePro M6100]

device Multimedia controller (Audio device) [4|3|0]
vendor 1002: Advanced Micro Devices, Inc. [AMD/ATI]
device aac0: Tobago HDMI Audio [Radeon R7 360 / R9 360 OEM]

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
vendor 8086: Intel Corporation
device 0416: 4th Gen Core Processor Integrated Graphics Controller

device Multimedia controller (Audio device) [4|3|0]
vendor 8086: Intel Corporation
device 0c0c: Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller

device Serial bus controller (USB controller, XHCI) [c|3|30]
vendor 8086: Intel Corporation
device 8c31: 8 Series/C220 Series Chipset Family USB xHCI

device Hub (Unused, Full speed (or root) hub) [9|0|0]
vendor 0000: Unknown
device 0000: Unknown

  device Hub (Unused, Full speed (or root) hub) [9|0|0]
    vendor 05e3: Genesys Logic, Inc.
    device 0608: Hub

     device Human Interface Device (No Subclass, None) [3|0|0]
       vendor 046d: Logitech, Inc.
       device c52b: Unifying Receiver

     device Human Interface Device (No Subclass, None) [3|0|0]
       vendor 046d: Logitech, Inc.
       device c52b: Unifying Receiver

  device Mass Storage (SCSI, Bulk-Only) [8|6|50]
    vendor 0781: SanDisk Corp.
    device 5595: Unknown

  device Mass Storage (SCSI, Bulk-Only) [8|6|50]
    vendor 04e8: Samsung Electronics Co., Ltd
    device 6300: Unknown

device Communication controller [7|80|0]
vendor 8086: Intel Corporation
device 8c3a: 8 Series/C220 Series Chipset Family MEI Controller #1

device Network controller (Ethernet controller) [2|0|0]
vendor 8086: Intel Corporation
device 153a: Ethernet Connection I217-LM

device Serial bus controller (USB controller, EHCI) [c|3|20]
vendor 8086: Intel Corporation
device 8c2d: 8 Series/C220 Series Chipset Family USB EHCI #2

device Hub (Unused, Full speed (or root) hub) [9|0|0]
vendor 0000: Unknown
device 0000: Unknown

  device Hub (Unused, Full speed (or root) hub) [9|0|0]
    vendor 8087: Intel Corp.
    device 8008: Integrated Rate Matching Hub

     device Video (Video Streaming) [e|2|0]
       vendor 1bcf: Sunplus Innovation Technology Inc.
       device 2984: Unknown

device Multimedia controller (Audio device) [4|3|0]
vendor 8086: Intel Corporation
device 8c20: 8 Series/C220 Series Chipset High Definition Audio Controller

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c10: 8 Series/C220 Series Chipset Family PCI Express Root Port #1

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c14: 8 Series/C220 Series Chipset Family PCI Express Root Port #3

device Network controller [2|80|0]
vendor 14e4: Broadcom Inc. and subsidiaries
device 43b1: BCM4352 802.11ac Dual Band Wireless Network Adapter

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c16: 8 Series/C220 Series Chipset Family PCI Express Root Port #4

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c18: 8 Series/C220 Series Chipset Family PCI Express Root Port #5

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c1c: 8 Series/C220 Series Chipset Family PCI Express Root Port #7

device Bridge (PCI bridge, Normal decode) [6|4|0]
vendor 8086: Intel Corporation
device 8c1e: 8 Series/C220 Series Chipset Family PCI Express Root Port #8

device Generic system peripheral (SD Host controller) [8|5|1]
vendor 1217: O2 Micro, Inc.
device 8520: SD/MMC Card Reader Controller

device Serial bus controller (USB controller, EHCI) [c|3|20]
vendor 8086: Intel Corporation
device 8c26: 8 Series/C220 Series Chipset Family USB EHCI #1

device Hub (Unused, Full speed (or root) hub) [9|0|0]
vendor 0000: Unknown
device 0000: Unknown

  device Hub (Unused, Full speed (or root) hub) [9|0|0]
    vendor 8087: Intel Corp.
    device 8000: Integrated Rate Matching Hub

     device Application Specific Interface (Device Firmware Update) [fe|1|1]
       vendor 413c: Dell Computer Corp.
       device 8143: Broadcom BCM20702A0 Bluetooth

     device Chip/SmartCard () [b|0|0]
       vendor 0a5c: Broadcom Corp.
       device 5800: BCM5880 Secure Applications Processor

device Bridge (ISA bridge) [6|1|0]
vendor 8086: Intel Corporation
device 8c4f: QM87 Express LPC Controller

device Mass storage controller (SATA controller, AHCI 1.0) [1|6|1]
vendor 8086: Intel Corporation
device 8c03: 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode]

device Serial bus controller (SMBus) [c|5|0]
vendor 8086: Intel Corporation
device 8c22: 8 Series/C220 Series Chipset Family SMBus Controller
  user  ~   23:27   

Basically I will monitor CGIT website for Bluetooth patches and update 64 bit Nightly and then
–> first probe Bluetooth service :

is there my local device finally detected ?

   user  ~    23:11    listusb | grep -E -i bluetooth
413c:8143 /dev/bus/usb/2/0/4 "Dell Computer Corp." "Broadcom BCM20702A0 Bluetooth" ver. 0112
   user  ~    23:12    listusb -v /dev/bus/usb/2/0/4
[Device /dev/bus/usb/2/0/4]
    Class .................. 0xff Vendor Specific Class ()
    Subclass ............... 0x01 (Unknown) (255:1:0)
    Protocol ............... 0x01 (Unknown) (255:1:1)
    Max Endpoint 0 Packet .. 64
    USB Version ............ 2.0
    Vendor ID .............. 0x413c (Dell Computer Corp.)
    Product ID ............. 0x8143 (Broadcom BCM20702A0 Bluetooth)
    Product Version ........ 0x0112
    Manufacturer String .... "Broadcom Corp"
    Product String ......... "BCM20702A0"
    Serial Number .......... "3052CBEA81BC"
    [Configuration 0]
        Configuration String . ""
        [Interface 0]
            [Alternate 0 active]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 16 bytes
                    Interval ......... 1
                    Type ............. Interrupt
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 64 bytes
                    Interval ......... 1
                    Type ............. Bulk
                    Direction ........ Input
                [Endpoint 2]
                    MaxPacketSize .... 1x 64 bytes
                    Interval ......... 1
                    Type ............. Bulk
                    Direction ........ Output
        [Interface 1]
            [Alternate 0 active]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 0 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 0 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
            [Alternate 1]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 9 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 9 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
            [Alternate 2]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 17 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 17 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
            [Alternate 3]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 25 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 25 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
            [Alternate 4]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 33 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 33 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
            [Alternate 5]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0x01 (Unknown) (255:1:0)
                Protocol ........... 0x01 (Unknown) (255:1:1)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 49 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 49 bytes
                    Interval ......... 1
                    Type ............. Isochronous
                    Direction ........ Output
        [Interface 2]
            [Alternate 0 active]
                Class .............. 0xff Vendor Specific Class ()
                Subclass ........... 0xff Vendor Specific Class (Vendor Specific Subclass)
                Protocol ........... 0xff Vendor Specific Class (Vendor Specific Subclass, Vendor Specific Protocol)
                Interface String ... ""
                [Endpoint 0]
                    MaxPacketSize .... 1x 32 bytes
                    Interval ......... 1
                    Type ............. Bulk
                    Direction ........ Input
                [Endpoint 1]
                    MaxPacketSize .... 1x 32 bytes
                    Interval ......... 1
                    Type ............. Bulk
                    Direction ........ Output
        [Interface 3]
            [Alternate 0 active]
                Class .............. 0xfe Application Specific Interface ()
                Subclass ........... 0x01 Application Specific Interface (Device Firmware Update)
                Protocol ........... 0x01 Application Specific Interface (Device Firmware Update)
                Interface String ... ""
                [Descriptor 0]
                    Length ........... 0x09
                    Type ............. 0x21
                    Data ............. 05 88 13 40 00 10 01 
   user  ~    23:12   

–> just as my device detected, or you ask some test I would be ready to follow your request.

\ #01 - 2026-04-09, hrev59601

On CGIT - filtering for Bluetooth - the following merged patches found for master branch

List of merge patches - Haiku x86_64, master branch - filtered to ‘Bluetooth’

   user  ~    00:15    ps bluetooth_server
Team                                                  Id #Threads  Gid  Uid 
/boot/system/servers/bluetooth_server              42564        3    0    0 

Thread                                   Id    State Prio    UTime    KTime
bluetooth_server                      42564     wait   10       25       34 
BT Kernel-User Event thread           42567     wait   20        0        0 
SDP server thread                     42568     wait   10        0        0 
   user  ~    00:16    

   user  ~    00:18    grep -E -i bluetooth /var/log/syslog.old
   user  ~    00:18    
   user  ~    00:18    grep -E -i bluetooth /var/log/syslog
2026-04-09 17:38:11 KERN: bt: bluetooth_std_ops: Connection Thread error
2026-04-09 22:51:06 KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/bluetooth/h2/h2generic
   user  ~    00:18    grep -E 17:38:11 /var/log/syslog
...
2026-04-09 17:38:11 KERN: bt: bluetooth_std_ops: Connection Thread error
2026-04-09 17:38:11 KERN: register_domain(10, l2cap)
...
   user  ~    00:20    grep -E 22:51:06 /var/log/syslog
2026-04-09 22:51:06 KERN: Last message repeated 2 times.
2026-04-09 22:51:06 KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/bluetooth/h2/h2generic
2026-04-09 22:51:06 KERN: register_domain(10, l2cap)
2026-04-09 22:51:06 KERN: check_sense: encountered DEFERRED ERROR - bye, bye
   user  ~    00:35    




These are the the details what I can provide from my own knowledge about Haiku Bluetooth status on my workstattion laptop machine.

This does not currently work because these broadcom chips require us to upload firmware for it to work, I’ll be starting to implement this PATCHRAM feature. Though as per my research ,freebsd and netbsd do not distribute this firmware due to licensing issues hence we might also not be able to distribute firmware. Hence we would not be able to get this adapter working for users out of the box and would need the user the get the firmware from somewhere else. (perhaps from here)
If anyone has any other ideas please tell!

1 Like

Usually in Haiku this is handled by the install-wifi-firmware.sh script, that will assist users to download the file (preferrably from Broadcom themselves, as I’m not sure the redistribution on Github that you linked to is itself allowed by the license) and convert it into a package usable on Haiku.

Unless the license can be read in a way that allows some form of redistribution of the firmware files, in which case we could put them in a package.

1 Like

Broadcom is notorious for shutting down with DMCA requests anything they don’t remotely like. If a popular GitHub project has been there for 10 years you can be sure Broadcom legal team knows about it and they are okay with its existence. Fwiw the place is suggested¹𝄒² by Arch and Gentoo Linux manuals.

The firmwares are also redistributed in dozen of driver download websites for Windows.

Either Broadcam doesn’t care about their own license, or it can be read in a way that allows this. If it’s the latter, there should be no problem repackaging and distributing the firmwares in Haiku either?

1 Like

The link contains important information too:

Notes about combined WiFi+Bluetooth devices

Some Bluetooth controller (for example, BCM4354 and BCM4356) are integrated to WiFi chipset (this can be BCM43XX 802.11ac Wireless Network Adapter or just simple generic Broadcom PCIE Wireless). These devices requires two kinds of firmware - first for WiFi, and second for Bluetooth. Without WiFi firmware Bluetooth will not initialize and will not work properly. Firmware for WiFi already included to kernel, but you may need to do additional work to place correct NVRAM.

EDIT: blue

wifi

Not really clear to me. The license says it cannot be distributed except as permitted in the license, and it appears to make no permissions to do so anywhere in the license:

Licensee may not use, disclose, modify, reproduce or distribute the Software except as expressly permitted in this Agreement.

But then it does say that you may create a backup for archival purposes:

Subject to the terms and conditions of this Agreement, BROADCOM grants
to Licensee the non-exclusive, non-transferable, personal, revocable right to
use the Software only in connection with BROADCOM Products, and to make one (1) copy of the Software for back-up or archival purposes only.

I suppose that one might argue that the backup on github is your archive. However I think it’s not really a valid argument because you are then also distributing, and the license grants no rights to distribute.

I am not a lawyer, so hard to be certain. But the license looks about as closed as they come to me. It has numerous unenforceable clauses. You aren’t even technically allowed to have three copies of the software in your possession, and after 50 years you have to destroy it.

Unfortunately I do not have an broadcom bluetooth device to test on (I though I had one,but I found out its an Intel) , hence it will be hard for me to test this out and therefore decided I’ll not be able to implement this. If anyone has one and is interested in implementing this,the freebsd implementation will be a good starting point! Though they have it in userspace, I think its better to do it on the driver side itself in Haiku.

From the information you provided, I believe the issue is only because the Bluetooth chip can’t initialize without the firmware like @vighnesh-sawant mentioned before. Also, that’s what happened to me when I tried to work with Bluetooth on bare-metal Vs. virtual machine.

I don’t know how if the install-wifi-firmware.sh script that PulkoMandy mentioned can handle this (probably I’ll read it). Also, I don’t know much about firmwares or if all of them are treated the same (in distribution license and uploading them to the devices). So, I need to do more research into this.

Do anyone know which parts of Haiku should handle firmware devices?

When I searched about how Linux handles this I found out there’s a kernel method called request_firmware() that the hardware driver can use to make the kernel search for the firmware in /lib/firmware then the hardware driver injects it into the device.

I think that the injection process differs based on the firmware family and the h2generic don’t handle this injection as far as I know. But, my question is should h2generic handle this (like hardware drivers in Linux) or does Haiku handles that firmware stuff in another way?

As far as I know, in Haiku, only FreeBSD-ported drivers have a mechanism to load firmwares. It’s considerably simpler than the Linux one, because the Haiku kernel knows and expects a specific filesystem organization, and doesn’t need to ask userspace services to find the firmware (Linux needs that because the same kernel can be used in many different situations).

So, the firmware finding function would be in Making sure you're not a bot!

h2generic could reuse that, or do something similar.

Ahoy !

I think, if it’s problematic to store/distribute legally the firmware for Haiku itself … it can be done via a script as a one time conveniency service for end users. This way it is really can compared to wifi firmware installer.

This script would

  1. Ask for initiate a firmware installation for this specific Haiku instance, so it will be an end user action to get it, but conveniently helped by this script, so the license file can be downloaded as well, if any needed, for as evidence

  2. create the subdir for firmware and license file to download

  3. do the download onto Haiku filesystem standardized place(s) for firmware and license file

  4. and then this way it will be available for BT services to use for local device detection.

Or even this process point can do hadle the BT device insertion into the device tree.

This way I interpret the offering to use some similar as wifi firmware install script …

Probably, the script should be renamed “proprietary firmware installer” ; I think that it would be less confusing than “wifi firmware installer” anyway.