Feature: HCI Transport for Linux/BlueZ HCI_CHANNEL_USER socket

[steven-buytaert]

I have the impression that I am asking the obvious, and I only started skimming the documentation and source code here, but would it be possible to make a generic IO interface with a physical USB Bluetooth device by means of the HCI_CHANNEL_USER feature of the kernel, described here?

With a quick scan over the code, the HCI_CHANNEL_USER was not found.

If a bad idea, I would like to know why. If not, I probably implement it myself in a few days. I just ordered a few dongles :-)

Regards,

Steven

[mringwal]

Hi Steven! Thanks for your mail about the Core Spec HCI parser - I'll reply to that one, too.

There's no implementation of an HCI Transport that uses the raw interface of a Linux/BlueZ system. I thought there was already a feature request here, but there isn't. it's on our "nice to have" list, though.

I've recently implemented something similar for FreeBSD, which also required some hacks to make it work. From what I've read, the BlueZ user channel should work directly. If you like, here's a few comments. You could create port/linux-bluez and keep implement the hci_transport.h interface in there. We generally prefer asynchronous transport, but as that's a socket, with a large buffer anyway, you can also make it blocking.

Besides the "nice to have" feature, I'm not so sure about the use case as this only work on Linux. There, you can use port-libusb with USB Bluetooth dongles and posix-h4 with Bluetooth Controllers connected via serial port / UART. Both cases work without modifications on your linux system and don't require to install BlueZ. While there might be a case for using the built-in Bluetooth in some situation, it's usually easier to buy an USB Bluetooth dongle and use that with BTstack.

That said, I'd be happy to merge your driver ;)

[steven-buytaert]

Hi Matthias,

Thanks for the reply. I was under the impression that the HCI_CHANNEL_USER is a kernel feature pur sang; you don't need any Bluez on top of it.

But even that said, I think your remark on 'what would it bring extra on top of the existing libusb port' is bang on. I hadn't played around with the libusb yet, since I lacked a USB dongle, but this morning I found one and it worked flawlessly.

So that I where I will concentrate on now for the moment. I will also reply to your mail (later tomorrow), but I will try to generate the YAML as a sample app, from the spec2src.h header file :-). I will first need to learn how to write YAML. I have some notions of it, but not that much.

Thanks for the nice work in BTStack and the reply. Cheers,

Steven

[mringwal]

BlueZ has components on all levels, as far as I know the HCI user channel is also part of BlueZ (but I might be wrong).

It doesn't need to be YAML... but I'd suggest to avoid XML.

You've collected HCI commands with different version into a single item. While that's nice, I'm wondering if this information is needed/useful in applications that use the definition. Maybe a logger could use the shared fields, but still check if the additional fields are available in the particular command variant.

[steven-buytaert]

Hi Matthias,

BlueZ has components on all levels, as far as I know the HCI user channel is also part of BlueZ (but I might be wrong).

As far as I can tell from the original announcement, the item is purely kernel, no Bluez interception; I like it when there's no dependency... But as I already said, the point is currently moot as I will use libusb as per your suggestion.

It doesn't need to be YAML... but I'd suggest to avoid XML.

In the meantime, I added a YAML file and a small application to generate it, so you can adapt it to your liking.

You've collected HCI commands with different version into a single item. While that's nice, I'm wondering if this information is needed/useful in applications that use the definition. Maybe a logger could use the shared fields, but still check if the additional fields are available in the particular command variant.

For others following this thread, we are discussing the files here.

The old file for the 5.3 spec collected the different versions in a single item, the new file for the 5.4 spec, has 1 item per command, but different 'instances' of each item when versioned. As per the README, when there is only 1 version of an item, there is 1 instance. For an item with versions, there will be an instance of each version.

BTW, the YAML file is now my first attempt, but I am not a YAML expert and maybe the structure could be made better. Any suggestion is welcomed. The generated file now passes yamllint.