https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265066

Malte Andersson <ma...@wendernes.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ma...@wendernes.com

--- Comment #15 from Malte Andersson <ma...@wendernes.com> ---
The Good, the Bad and the Ugly - that pretty much sums up my experience with
the Bluetooth stack in FreeBSD.

Initially, when I started using FreeBSD 14-current in the summer of 2022, I
didn't need a functional Bluetooth stack. I used the Logitech Unifying receiver
to get my MX Keys and MX Master working on the system. Since this keyboard and
mouse support up to three connected computers, I could use the Bluetooth
functionality on the MX's with other computers.

One day, I discovered I had lost the pairing between the Unifying receiver and
my MX products. I first checked the handbook to set up Bluetooth, but the
system never created the ubt node. Although the computer's local Bluetooth
module was correctly detected as a USB device. I discovered that the Bluetooth
stack in FreeBSD wasn't compatible with newer firmware revisions. I tried
progressively older revisions until I found a semi-functional version.
Following the handbook, I could scan for remote Bluetooth devices, but none of
the devices I had activated for advertising showed up. While digging through
the hccontrol source code, I discovered support for BLE scanning, but these
commands weren't mentioned in the handbook, and the man-page didn't clearly
describe how to use them.

While it was possible to scan for remote Bluetooth devices in
pairing/advertising mode, the local Bluetooth module frequently crashed -
likely due to firmware issues. After extensive testing, I finally found the
right sequence of steps to reduce the frequency of crashes.

When I reached this point, I tested "LE_Connect" under hccontrol. This provided
a handle but nothing else. The remote device appeared briefly under
"Read_Connection_List," but this pseudo-connection was lost when the remote
device left advertising mode.

This led me to follow Andreas approach. I wrote userspace software, created a
daemon, and patched the kernel. However, I still experienced ongoing issues
with the Bluetooth module in my notebook crashing - sometimes after the first
HCI command, sometimes after several hours. I also received numerous warnings
in "/var/log/messages" related to the HCI node, along with multiple consecutive
timeouts.

This situation forced me to develop a new Bluetooth stack. Running in userspace
with the help of libusb, it supports firmware loading and manages everything
related to BLE from 4.0 to 5.4, including LE audio.

My recommendation for FreeBSD would be to implement the Bluetooth stack in
userspace. I wrote my implementation from scratch without external libraries.
It's POSIX-compliant where possible, and all BLE functionality works without
any issues.

The implementation I developed currently has limited hardware support, but
adding more VID and PID entries and including the necessary firmware is all
that's needed. I think it is much easier to handle everything if it exists in
the same place, like fully kernel based or fully user space based. If it is
splitted it only creates more friction when a upgrade is needed. 

And by having it fully user space based makes it ridiculously easy to provide
upgrade for newer specifications without the need to make changes in the
kernel. You can also create a configuration file where you can specify the VID,
PID and path to the firmware. And that makes it easy for users to easily enable
support for hardware that does not currently exist in the list. 

Yeah, and I have since the summer of 2022 worked on my own fork of FBSD
14-current and moved the majority of all USB based drivers from the kernel to
the user space. This also include the 802.11 stack which allowed me to
implement support for n/ac/ax in the user space. I'm currently working on a
kernel module wrapper that also will allow me to implement support for PCI(M.2)
NIC in the user space.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to