Controller for regular old linux

[Ciantic]

I'm planning to use bt-hci with regular old linux, like in Raspberry PI 4 or Zero.

It should be doable, one just opens HCI socket like this:

let fd = unsafe {
        libc::socket(
            libc::AF_BLUETOOTH,
            libc::SOCK_RAW | libc::SOCK_CLOEXEC,
            BTPROTO_HCI,
        )
    };
    if fd < 0 {
        return Err(Box::new(io::Error::last_os_error()));
    }

    // Bind to hci0 (device index 0) on the raw HCI channel.
    let mut addr: sockaddr_hci = unsafe { mem::zeroed() };
    addr.hci_family = libc::AF_BLUETOOTH as u16;
    addr.hci_dev = 0; // Use hci0; adjust if needed.
    addr.hci_channel = HCI_CHANNEL_RAW;
    let ret = unsafe {
        libc::bind(
            fd,
            &addr as *const _ as *const libc::sockaddr,
            mem::size_of::<sockaddr_hci>() as libc::socklen_t,
        )
    };

(Taken shamelessly from here: https://github.com/kevinisabelle/raspigamecontroller/commit/8e2cbd8c41b82d53cc1e226096792056c9c4b8a8 )

I'm not entirely sure but it should then just interacting with write and read, it should work with most Linux installations with bluez running or not.

I know there is one entire C codebase that works like this: https://github.com/petzval/btferret/blob/main/btferret.c

[lulf]

It should work then I think if you implement this trait.

[Ciantic]

I might have opened this issue in wrong repo, if one were to create socket based transport, should it be merged to bt-hci or trouble?

Edit I do think this is right repo, I just make an example (like others are) with socket transport.

I wanted to contribute or suggest a feature for regular old Linux socket transport. It would generally make bt-hci more useful because it could be used in Linux projects for Bluetooth. This socket based transport could be used wit embassy's std examples.

I now see that SerialTransport is inside the bt-hci. However, in my mind, bt-hci is just the protocol definition and shouldn't have implementation details like opening a socket.

[lulf]

I might have opened this issue in wrong repo, if one were to create socket based transport, should it be merged to bt-hci or trouble?

Edit I do think this is right repo, I just make an example (like others are) with socket transport.

I guess it depends on how big the implementation is, if it's worth creating a separate crate (i.e. linux-hci), or just embed it into the example. Up to you really!

I wanted to contribute or suggest a feature for regular old Linux socket transport. It would generally make bt-hci more useful because it could be used in Linux projects for Bluetooth. This socket based transport could be used wit embassy's std examples.

Agreed, it would be useful!

I now see that SerialTransport is inside the bt-hci. However, in my mind, bt-hci is just the protocol definition and shouldn't have implementation details like opening a socket.

Agreed it shouldn't be in the bt-hci repo. But I also don't think controller implementations as such belong in trouble-host repo either, unless it's baked into the example and is really simple.

[theol0403]

Out of curiosity, did you get this working? Is it more a matter of documentation, or does someone still have to go through the process of setting up the plumbing for read/write traits.?

[Ciantic]

@theol0403 well, I did get a hugely sidetracked, I started to build my own Bluetooth stack working on H4 protocol. I think this is one of those "tar pit" ideas, which seems easy and many engineers (just by searching Github) start but never finish.

However I did write the controller for lib-c socket, it's in my git history:

https://github.com/Ciantic/rust-hid-gat/blob/ca4974c015473b79c2abff48ccdc58592b0ff5f2/src/controller.rs

I couldn't figure out how to get it working, now I have more clues to do it, but no interest at the moment 🙂

I guess my problem with embassy's way of doing this is that it has too many dependencies, that's why I started my own (never to be finisihed?) bluetooth stack.

[lulf]

Regular old linux merged #420