diff --git a/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc b/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc
new file mode 100644
index 0000000000..3e0d719861
--- /dev/null
+++ b/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc
@@ -0,0 +1,39 @@
+=== 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.