[GSoC 2026] Bluetooth Stack Improvements

vighnesh-sawant · March 16, 2026, 2:25pm

Hello!

I am Vighnesh Sawant a freshman majoring in Computer Science and Engineering. I am interested in contributing to Haiku since I love low level systems engineering and I am very intrigued by the philosophy behind making Haiku. I have been bitten by linux’s fragmented ecosystem and would love to contribute to an OS offering a coherent UI/UX.

I have already made a few contributions and have gotten myself familiarized with the existing bluetooth codebase. I have also done quite a bit of side projects of my own related to systems programming!

As I was trying to make a proposal, I would like to ask the community, what is the usecase for bluetooth that you feel would be lovely if it was shipped?

I was planning to implement HID first as support for that already exists over USB and I2C and then A2DP (the audio profile) as I mostly use bluetooth for listening to songs!

vighnesh-sawant · March 16, 2026, 2:37pm

Currently I am trying to understand and improve the h2generic driver for bluetooth.

waddlesplash · March 16, 2026, 2:57pm

Welcome!

The h2generic driver could probably use some work, yes. I have been meaning to (eventually) get around to merging the btCoreData and hci kernel modules into a proper “bluetooth bus_manager” (just like USB has), and then h2generic will be a Bluetooth “bus driver” (like e.g. XHCI for USB), and in the process drop a lot of the custom buffer code and use net_buffers all the way down the stack. But I don’t work on Bluetooth very often (last major work I did was the big L2CAP refactor), so it’s quite low priority for me.

On the whole, that work probably isn’t necessary for GSoC, and L2CAP should hopefully be functional enough that you can just make minor bugfixes where needed, and focus on the userland parts of the stack. (Though I guess if you want to implement audio, we need SCO support, which will require changes at this level…)

waddlesplash · March 16, 2026, 3:03pm

One thing you might want to investigate at this level, though, is adding support for tcpdump of Bluetooth packets. This will allow debugging with Wireshark and other tools. If we use the network stack’s routing functionalities, we get this support basically for free; but Bluetooth may not fit well with the Ethernet/IP-based design of the network stack (we obviously integrate with it already in order for L2CAP sockets to work at all, but packet routing below the L2CAP layer skips the stack altogether at present.)

waddlesplash · March 16, 2026, 3:16pm

OK, I looked into this more. Actually, if we can integrate Bluetooth more fully into the network stack, we might be able to avoid a Bluetooth “bus manager” altogether, and instead use a Bluetooth “network device handler” (see ethernet for how this is done for ethernet/WiFi).

I don’t know if this design makes sense or not, though. It may be worth comparing against FreeBSD to see if their Bluetooth stack is tied into their network stack in a similar way. Feel free to find me on IRC if you want to discuss in more detail.

mohammedrattia · March 16, 2026, 5:30pm

Hi Vighnesh,

I’m mohammedrattia. I’ve also been working on a proposal for the Bluetooth Stack Improvements project.

My plan is very close to what you described: finish the remaining HCI edge cases, add persistent Link Key storage (so devices don’t need re-pairing after reboot), implement SDP queries, and deliver a complete HID profile with a working input_server add-on for keyboards and mice.

I agree that HID is the best first target — it proves the whole stack works end-to-end without requiring SCO yet.

I have a detailed codebase analysis, proposed architecture diagram. Happy to share it here if anyone wants to take a look or give feedback : )

KitsunePrefecture · March 17, 2026, 4:16am

Ahoy @vighnesh-sawant !

Welcome to Haikuland !

I would be happy if I would get a message as Haiku - at least - found my BT device !..

   user  ~    03:58    listusb|grep tooth
413c:8143 /dev/bus/usb/2/0/4 "Dell Computer Corp." "Broadcom BCM20702A0 Bluetooth" ver. 0112
   user  ~    03:59    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  ~    03:59   

   user  ~    03:59    uname -a
Haiku HiQ_R1Nitely_512GO.szabadpart.n R1~beta5+development hrev59485 Mar 16 2026 06:02:24 x86_64 x86_64 Haiku
   user  ~    04:07    ps bluetooth_server
Team                                                  Id #Threads  Gid  Uid 
/boot/system/servers/bluetooth_server                719        2    0    0 

Thread                                   Id    State Prio    UTime    KTime
bluetooth_server                        719     wait   10       29       45 
BT Kernel-User Event thread             722     wait   20        0        0 
   user  ~    04:07   

Some hours ago I updated my Haiku 64bit R1Nightly, just as I seen so many BT patches on gitore so I became curious : how much visible of it , for us, end users … not much actually :))

Nevermind. I will follow them on gitore and on the forum too !

Anyway …

To detect available BT devices … well that does not happens successfully even on Linux – it highly depends on which distro you have – as I experienced lately.

The firm I work for .. last year had an anniversary in this Hungary location and we got a fistful JBL mobile BT speaker as a memorable gift. Seems it has a very new BT version,

so Linux Mint 22.2 cannot detect it. ( My non smart phone - a Caterpillar button one - also cannot detect it – however as I walked on the street the phone found many TVs from the houses from meters between them, but not the BT speaker from 5-10 centimeters Seems the difference between BT versioning is a vulnerability yet !..
My personal opinion : it is the most swacky IT improvement - how randomly worked for me , and how high expectations I had for it. )

I have a different distro which is base on Fedora … there the BT service find my cutie JBL without fail, and could send sound to it … so finally I had not gifted away for a more patient and more modern machine owner than me.

I hope you and Mohammed (@mohammedrattia)
¤ can split up your interest in BT stack in a fitting way

¤ to may parallelize it

–> and finalize fundamentals in kernel part and a specific service faster
–> and/or work on different services.

I dunno the Discourse engine can handle voting -

I do not remember - since 2017 I read it regularly - were voting or not here, I mean if you want to know really which services the most user want to have WORKING FIRST …

What are surely capable to have voting – the Trac TICKETS.

But how to open improvement tickets to have make sense to voting on them ? If not available them already ?

On Haiku HW wiki page

I found

–> a useful table about BT versions - I assume to be filled up with achieved support statuses : actually all empty.

–> another table about BT protocols - I assume these provide base for services

–> and finally a table about BT profiles – seems these are what I called as different BT services

Not some short lists both of them.

I dunno which is larger user base : BT keyboards/mices or speakers/headphones or network devices …

From OS perspective input and network availability is more important, however my Logitech K400r do not use BT but another radio technology, and I have no BT network device.

I bought one USB dongle only for an old XP laptop, as its package stated it is really for that Windows version(!) , but it had not worked at all. The polish firm that imported from China into Europe had not provided reliable service on their site to bother me to report the issue. ;j

Sum of it –

I hope you get more answers on the forum : even via voting tool if exists for Discourse -

or you open such tickets to have voting on them …

Thanks for your offer and coding in advance !

PulkoMandy · March 17, 2026, 8:02am

Hello,

As you have noticed there are two of you applying for the same project idea for GSoC.

Maybe you can discuss this with each other and make sure you submit proposals that don’t overlap. For example, one of you could be working on HID and the other on A2DP (maybe not the best way to split things up).

If you submit proposals for the same parts of the stack, we will for sure have to accept only one of the two. But if you set it up in a way that you can work on different parts, we can consider accepting both proposals. However you have to make sure one part of the work doesn’t block the other one, and I don’t know if the lower levels of the Bluetooth stack are ready enough for that. Maybe with all the preparation work you’ve already done, it is?

mohammedrattia · March 17, 2026, 9:51am

Hi @KitsunePrefecture ,

First, thanks for you’re reply; it’s really helpful : ).

I would be happy if I would get a message as Haiku - at least - found my BT device !..

Actually, I’ve written this problem of Haiku not recognizing BT devices in my proposal under the gaps section as following:

Lack of Proprietary Hardware Support

Currently, the Bluetooth stack is unable to communicate with non-generic Bluetooth dongles because it lacks the architecture to send proprietary firmware to the hardware during initialization. Testing on a virtual machine revealed that despite having the ability to communicate with a RealTek dongle after Linux uploading its firmware, Haiku cannot independently identify or start the same hardware on a bare-metal machine.

But I didn’t include it in the scope of the project because generic Bluetooth dongles currently are just as useless as firm-specific ones after being recognized. So, I thought that supporting a useful service first would allow users to use cheap generic Bluetooth device to use the services.

I’d really be happy if someone can give more technical details about how to tackle this, as I don’t know much. What I know is that as mentioned above, some Bluetooth dongles need firmware (including my RealTek one). While Linux (I am on Fedora which allows proprietary firmware) uploads this firmware to the Bluetooth dongle and start working with it, Haiku can’t do this on bare-metal. However, it can recognize it on virtual machine if I didn’t make Linux completely leave the device. So, Mostly what happens is that Linux already uploaded the firmware and Haiku then was able to communicate with it.

I believe splitting things up as @PulkoMandy states would actually work, because handling different Bluetooth dongles is related to a the device driver module in src/add-ons/kernel/drivers/bluetooth (where h2generic lives). And because upper layers just use the device hooks, we can add more device drivers here without affecting the higher-level work. Actually, I think we can support Bluetooth USB firm-specific hardware using same h2generic if we allow it to upload the firmware to them, but as I stated I don’t know much technical details about the difficulty of this.

However, supporting audio intersects with most of the Bluetooth layers and will depend on some previous work in pairing and handling connections for example.

mohammedrattia · March 17, 2026, 10:22am

Hello,

Yeah the architecture of the lower parts of Bluetooth is really good. The limitations I documented about h2generic was that it don’t handle SCO (like all other layers), and the scheduling in h2upper.cpp file isn’t used (I don’t know yet the effect of this). However, as far as I know, non of the upper layers of Bluetooth depend specifically on the h2generic driver, which would allow to add more drivers. Actually, the bluetooth_server tries to monitor 4 different directories of local devices (bluetooth/h2, 3, 4, and 5), but I don’t know the difference between those except that only bluetooth/h2/h2generic is available in the kernel drivers…

The other details I know is documented here: Bluetooth Proposal

Also, @waddlesplash mentioned something about merging btCoreData and hci, or integrating the bluetooth into the network stack. This shouldn’t overlap with the other work as far as I know. But I really don’t know much about handling the networking stuff that waddlespash talked about : )

brunobastardi · March 17, 2026, 11:19am

That sounds like a good and doable solution!

PulkoMandy · March 17, 2026, 11:47am

The support for more bluetooth dongles could be done either by writing our own drivers, or by porting drivers from FreeBSD or OpenBSD as we do for network devices.

I don’t know if the existing compatibility layer for network drivers could be of any use here, and if that requires making the bluetooth stack more integrated with the network stack, as Waddlesplash was suggesting earlier?

I’m not very knowledgeable about Bluetooth, the last time I looked a bit into our code was back in 2008, during my first attempt to be accepted as a GSoC student (it didn’t work that year ). So I don’t remember much about it.

mohammedrattia · March 17, 2026, 11:49am

Thanks for attaching this page! I didn’t knew about it, and it’s really useful. Also it mentions another article useful about Bluetooth here: Bluetooth .

mohammedrattia · March 17, 2026, 11:57am

np. I’d like to know more about the “existing compatibility layer for network drivers” if you know how Haiku handles networking and what parts should I read to understand more. I don’t think it’d be efficient to go read in the network drivers of Haiku randomly as there’s a lot of code there : P.

Also, I think it’s inspiring that you still here after all those years despite not being accepted in your first attempt : )

KitsunePrefecture · March 17, 2026, 12:49pm

You are welcome – I found it once

and now again when I searched for BT related tickets in Trac.

The Haiku wiki is also hosted by this site and software, any search works on both.

Otherwise …

Well, my Broadcom device is built-in, not a dongle, however Dell always uses USB bus to insert BT devices, and they are basically Broadcom products (chips).

Only one exception - If I could replace the all Dell (Broadcom) Wireless MiniPCIe with a combined Intel WLAN+BT device, like

Intel Dual Band Wirelles-AC 7260 HMW (it includes an Intel BT 4.0 version device)

In case older MiniPCI I can replace DELL (Broadcom) BT device only with a separate dongle - in a USB 2.0 port …

As I recognized, Dell provided 2 kind of radio devices (WLAN and BT) earlier

Broadcom ones under its Dell brand

and

Intel ones …

at least in the all 4 Dell (one really old Inspiron and 3 Precision Workstation grade) laptops.

What if the original Haiku BT stack designer created those different h2generic directories for different BT versions ?

This way it is obvious : he started with version 2.0 implementation.

Of course it’s just a guessing from my side. ;-j

If you and Vighnesh check out the separate Bluetooth page, you will find short explanations on design, and FreeBSD Bluetooth link as well among the list of documents of sources of Haiku BT Stack development - at the bottom of the page. I assume that may progressed a lot since then, but may worth to consider to use as waddlesplash and Pulkomandy offered to read about and compare / examine for drivers.

mohammedrattia · March 17, 2026, 1:25pm

yeah what I mean by USB is the bus. Many bluetooth dongles use USB bus even if they’re built-in they use the same USB interface.

Hmm, I don’t think so, as Bluetooth version 5 surly wasn’t there back then : P. Also the low-level drivers shouldn’t be concerned with those Bluetooth versions too much. After some searching I found out that those mostly refer to types of HCI transport layers link. But not sure why they are called by those H:X names. Grok told me that in older Bluetooth specifications here: http://www.tscm.com/BluetoothSpec.pdf the parts of those layers were named by “Part H:2”, etc. while new specifications make a whole volume for HCI. So… maybe they’re just ancient names?! : )

vighnesh-sawant · March 17, 2026, 2:00pm

As PulkoMandy suggested, I think splitting the work with @mohammedrattia working on hid (and more stuff which he might have planned) and me working on getting sco support in the rest of stack and then implementing the SCO profile and A2DP profile might be a good idea , I am currently looking into if its even feasible without us blocking each other.

Also A2DP does not require sco support, they are two different profiles, A2DP for streaming music and SCO(HFP profile) for the calls stuff (which requires low latency). I really want to add A2DP and SCO as irl thats the only use case I have seen for bluetooth. (Most “bluetooth” mouse and keyboards use some proprietary protocol not dependent on bluetooth, Although this just might be more common where I live)

As @waddlesplash has quite more understanding of the current state of the bluetooth stack, do you think this would be a feasible idea?

@mohammedrattia We can discuss more about this on irc/mail if you want!

waddlesplash · March 17, 2026, 2:17pm

There is going to be overlap in some parts of userspace, e.g. SDP is necessary I think to probe for audio-related services as well as HID (or file sharing, or anything else really), and we don’t have much of an SDP implementation at all. But that may not be so much code, and the rest of it after devices are paired and we have SDP is mostly separate indeed.

Please try to hold discussions in public (e.g. on this forum thread or in the #haiku IRC channel) so that others can benefit or chime in, too!

mohammedrattia · March 17, 2026, 2:37pm

About that… maybe if @vighnesh-sawant will work on SCO, it’ll require many edits in lower drivers such as hci and h2generic that won’t require the SDP. So, if he did those parts in first month I would have finished the SDP. So, we both can continue in our bluetooth profiles. Is that looks realistic?

mohammedrattia · March 17, 2026, 11:38pm

Hi Vighnesh,

I looked into this more, and SDP seems to be really the only part that both profiles depends on. We can plan it together if needed, and as I mentioned in the last comment, I can finish it early in the first month, so we both can use it right away.

You mentioned that you prefer working on SCO and A2DP profile. That already don’t overlap with what I am planning.

To make things more clear, do you agree on this split?

My part (HID + userland focus):

Finish remaining HCI events & edge cases
Core SDP client (will be done early in month 1)
Persistent Link Key storage
HID profile (mouse + keyboard support)

Your part (Audio + lower layers):

Complete SCO support in the kernel layers (h2generic and hci)
A2DP profile (music streaming)
Supporting more hardware or HFP (if time allows)

In the end, Haiku users would finally get both working Bluetooth keyboards/mice and music streaming (A2DP).
btw I also use Bluetooth mostly for connecting earbuds, so I’d love if it works ; )

If you’re still investigating things, please feel free to take you’re time : )