=== Bluetooth HID drivers
Links:

link:https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices[FreeBSD wiki project page] URL: link:https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices[] +
link:https://github.com/majintosh/freebsd-bthid[Project GitHub repo] URL: link:https://github.com/majintosh/freebsd-bthid[]

Contact: Majed Alkhaleefah <majed@FreeBSD.org>

I have been working on two drivers to enable support for HID drivers for Bluetooth devices as part of GSoC 2026.

The primary goal of this project is to register connected Bluetooth HID devices as Newbus devices via two new drivers: `bthidbus` and `bthid`.
`bthidbus` acts as the parent bus that manages the creation and attachment of `bthid` child devices.
`bthid` serves as the transport layer, spawning a `hidbus` device and routing all received packets to it once they are stripped of their headers.
The short-term goal here is to enable support for wireless HID connections.
The longer-term goal is to begin setting the foundation that allows others to write drivers for devices that can only connect via Bluetooth.

What has been accomplished:

* `bthidbus` can successfully open a connection to a Bluetooth device via sockets.
* `bthid` can receive and manage sockets handed down from `bthidbus` via ivars.
* `bthid` can send the report descriptor to `hidbus`, which successfully spawns the correct HID device and driver.
(e.g., a gamepad connected over Bluetooth spawns an `hgame` device and an `evdev` node.)
* Input from Bluetooth devices is successfully received by `hidbus` and `evdev`.


Current issues and planned changes:

* The actual report descriptors, Bluetooth addresses, etc, have to be hardcoded into `bthidbus`.
I initially considered adding the querying/listening logic to `bthidbus` to make it act like a pseudo-server, but I worried this would risk bloating and scope creep.
The approach I will be going with instead is to rely on the `bthidd` daemon's existing querying logic and have it send new connection information to `bthidbus` via an `ioctl`.
This would remove `bthidbus` 's current role as the connection-initiator and instead have it only manage connections that have already been opened.
* There is significant input latency when monitoring via `evtest`.
I have two different working hypotheses.
The first is that the issue lies in `bthid` and how it manages interrupts via taskqueues.
The second is that it lies in the Networking stack, as Bluetooth packets are piped between multiple different Netgraph nodes before being received by `bthid`.
This could also very well be an issue with `evtest`; I still have to look into this.


All testing so far has been done with the Nintendo Switch Pro Controller.