You're right, maybe I'm caught on the callback interface because that is how it
is
implemented now, but in the end there's always a packet you process.
I still wonder if also having L2CAP in kernel would be better since it deals
with multiple connection handling, packet fragmentation and so on (to
You're right, maybe I'm caught on the callback interface because that is how it
is
implemented now, but in the end there's always a packet you process.
I still wonder if also having L2CAP in kernel would be better since it deals
with multiple connection handling, packet fragmentation and so on
Also, I understand that Xiaomi intends to replace the entire Bluetooth
stack with a newer BT 5.0 stack. I don't know if that is still a plan
of record or not, but you probably should coordinate Bluetooth
architectural changes with Xiao Xiang in any event.
Thanks for the heads up. Would be good to get Xiao Xiang's input on this
then. Maybe he already encountered this issue.
For now I'm working on the Link Layer, looking at 4.0 spec as a start.
If the host layer is reimplemented for 5.0 I understand it shouldn't invalidate
the LL in principle. But fo
Thanks for the heads up. Would be good to get Xiao Xiang's input on this
then. Maybe he already encountered this issue.
You should also be aware of the wireless architectural principles of
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397
Some of the things you hav
On Mon, Aug 24, 2020 at 12:34 PM Gregory Nutt wrote:
>
> Some of the things you have speculated about would be contrary to these
> principles. The basic wireless rules are:
>
> 1. Network sockets are used to communicate with complex wireless
> networks (like bluetooth)
>
> 2. Character drivers sh
On 8/24/2020 2:20 PM, Brennan Ashton wrote:
On Mon, Aug 24, 2020 at 12:34 PM Gregory Nutt wrote:
Some of the things you have speculated about would be contrary to these
principles. The basic wireless rules are:
1. Network sockets are used to communicate with complex wireless
networks (like bl
> I see that there is an ioctl interface for the bluetooth network
> driver, but I don't think this is really a good idea. GATT is really
> something that should be handled in userspace.
Yes, I've been using what exists at the host layer in NuttX, via the btsak
application.
While it opens a soc
> I have been puzzling through the Goobledegook GATT server (GGK,
> https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus
> interface. It is GPLv3 so not a candidate for porting. And also not
> much use for understanding APIs since the OS interface is hidden inside
> of the B
On Mon, Aug 24, 2020 at 1:40 PM Matias N. wrote:
>
>
> > I have been puzzling through the Goobledegook GATT server (GGK,
> > https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus
> > interface. It is GPLv3 so not a candidate for porting. And also not
> > much use for understandin
I have been puzzling through the Goobledegook GATT server (GGK,
https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus
interface. It is GPLv3 so not a candidate for porting. And also not
much use for understanding APIs since the OS interface is hidden inside
of the Bluez D-Bus int
On Mon, Aug 24, 2020 at 2:25 PM Gregory Nutt wrote:
>
> >>> I have been puzzling through the Goobledegook GATT server (GGK,
> >>> https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus
> >>> interface. It is GPLv3 so not a candidate for porting. And also not
> >>> much use for und
> I think you are missing something here, the interface that needs to be
> supported is not L2CAP, it is HCI.
So you suggest to implement L2CAP in userspace? I'm confused when you mention
that there's a L2CAP socket
already and HCI socket needs to be added. Just to be clear, I have this stack
i
I also think D-Bus does not seem to be appropriate for small systems. It is
overkill.
Also, having a library implementing all functionality and then a daemon using
that library
would be the best way. As Brennan mentions, in many use cases (such as mine) I
would
only have a single bluetooth appli
On Mon, Aug 24, 2020 at 3:56 PM Matias N. wrote:
> That's quite a strange stack arrangement. If you go to the BLE spec, the
> L2CAP sits above the HCI layer.
> I would guess that the arrow between L2CAP and Bluez actually speaks the
> HCI protocol and the "HCI sockets" allow you to directly call
Ah, ok, it was much more complex than what I thought. Thanks for the
explanation!
On Mon, Aug 24, 2020, at 20:10, Brennan Ashton wrote:
> On Mon, Aug 24, 2020 at 3:56 PM Matias N. wrote:
>
> > That's quite a strange stack arrangement. If you go to the BLE spec, the
> > L2CAP sits above the HCI
16 matches
Mail list logo
