HCI transport: Add support for Linux HCI socket? about btstack HOT 6 CLOSED

We've recently added support for FreeBSD's Netgraph Bluetooth HCI driver on the develop branch https://github.com/bluekitchen/btstack/blob/develop/port/freebsd-netgraph/hci_transport_netgraph.c - which required to disable FreeBSD's L2CAP layer, though.

Do you want/need to keep using BlueZ in parallel, or do you only require BlueZ to load/initialized the Bluetooth Controller (which isn't supported by BTstack directly yet)?

from btstack.

I don't need to use BlueZ in parallel. Btstack application can have exclusive control over the controller. It's fine. I just wonder whether it is possible to make Btstack application send/recv all HCI packets via HCI socket.

from btstack.

Good, running two Host Stacks with one Controller would be a disaster :)
BTstack should be fine once someone implemented hci_transport_t via BueZ' HCI socket. Given the references to Zephyr and NimBLE, it looks like it should just work out of the box (it didn't with FreeBSD which didn't want to send/receive ACL directly).

from btstack.

I am currently implementing this feature. However, I encountered some problems. I wrote a custom hci_transport_t driver which uses linux bluez socket to send/receive packets. The driver is synchronous, which means can_send_packet_now is NULL. However, in gap_run_set_local_name and gap_run_set_eir_data, hci_reserve_packet_buffer is used to reserve the HCI buffer. I cannot find a way to release the packet buffer under synchronous transport settings. Does that mean I must design the HCI driver as asynchronous?

from btstack.

Hi @AminoACID123 Please try the current develop branch. gap_run_set_local_name and gap_run_set_eir_data should work with synchronous implementations now as well.
In general, please consider if it's possible to implement an asynchronous driver.

from btstack.

I see. Thank you.

from btstack.