Bluetooth

What is it?

The Bluetooth roadmap plans a complete Bluetooth stack in the kernel: the HCI transport to the radio, chipset firmware loading, L2CAP, service discovery, wireless keyboards and mice, BLE, serial ports, headphone audio, pairing and the bluetooth.cpl and btctl tools. Nothing in it has shipped. There is no Bluetooth code in the tree today, so this page describes the plan and what it still waits on.

How will it work?

HCI, the radio link. Most laptop Bluetooth radios sit on an internal USB port. A USB transport (planned as bt_hci_usb.c in the USB stack roadmap) carries HCI packets: commands out, events and ACL data in. The HCI layer above it sends the start-up sequence (reset, read version, read the local address, enable scanning), keeps a table of 16 connections and dispatches events. Intel and Realtek radios first need a firmware patch from C:\Impossible\System\Firmware\bt\. The firmware section plans to open those files directly, and the firmware roadmap's Driver Conversion Pass later moves them to the shared Firmware Loader and its integrity and provenance checks.

Protocols on top. L2CAP multiplexes channels over each connection. SDP discovers what a remote device offers. Profiles then turn channels into devices: HID feeds keyboard and mouse reports into the existing input path, RFCOMM exposes serial ports, A2DP streams SBC-encoded audio to headphones with AVRCP for play and volume keys, and BLE with GATT reads values such as battery level.

Pairing and control. A Bluetooth manager owns discovery, Secure Simple Pairing and the paired-device list. Pairing nonces must be random; the kernel CSPRNG (csprng_fill() in csprng.h) provides that today, although the roadmap names a hwrng_read() source that does not exist.

flowchart LR
    R[Radio on USB] --> T[bt_hci_usb transport]
    T --> H[HCI: events, ACL, 16 connections]
    H --> L[L2CAP]
    L --> S[SDP]
    L --> HID[HID: input path]
    L --> RF[RFCOMM: serial]
    L --> A[A2DP + AVRCP: audio]
    H --> B[BLE + GATT]
    M[Bluetooth manager: pairing] --> H

What does it wait on?

The USB transport. The roadmap calls bt_hci_usb.c an existing stub; it does not exist yet. The USB host driver today only claims mass storage (class 0x08) and boot-protocol keyboards and mice (class 0x03) in xhci_dev.h, so a Bluetooth radio (class 0xE0) is ignored (USB Stack).
A HID report parser. Bluetooth keyboards and mice send full HID reports; the planned parser belongs to the I2C and Precision Touchpad roadmap.
An audio subsystem for A2DP (Audio Drivers).

What are its interfaces?

None yet. The planned surface is the HCI API (hci_send_cmd(), hci_acl_send()), the Bluetooth manager, Registry keys under HKLM\SYSTEM\Bluetooth, a /dev/rfcomm0 serial node, the bluetooth.cpl control panel, a Quick Settings tile and the btctl command.

How do I use it?

You cannot yet. Bluetooth keyboards, mice and headphones do not work; use USB or PS/2 input (Input System).

What is not implemented yet?

Everything:

HCI and firmware (HCI Transport Layer, HCI Firmware Loading).
Core protocols (L2CAP, SDP).
Profiles (HID, BLE, RFCOMM and SPP, A2DP, SBC and AVRCP).
Management and tools (Bluetooth Manager, Pairing UI and bluetooth.cpl, btctl Shell Command).

How does it compare with Windows 11 and Linux?

Windows 11 splits Bluetooth between kernel drivers (BTHUSB.sys, bthport.sys, hidbth.sys) and the user-mode bthserv service. Linux keeps HCI, L2CAP and RFCOMM in the kernel and the rest in the BlueZ daemon bluetoothd, driven by bluetoothctl. Impossible OS plans the whole stack in the kernel with no daemon, plus a btctl command, and has no Bluetooth support today.