Hi,
struct btd_profile contains folowing callbacks:
.connect
.disconnect
.device_probe
.device_remove
.accept
I noticed that those callbacks:
.device_probe
.device_remove
.accept
are called properly, but:
.connect
.disconnect
callbacks are not being called at all when LE device disconnected
itself or was connected or autoconnected back. There is no doc, but
I'm guessing those should be triggered in this cases, right ? Also,
when I connect first time to a device, only .accept should be
triggered, but when I connect next time only .connect ?
Can you please explain what is the intended order of those callbacks ?
Then I can fix them if I find some discrepencies from intended
behaviour.
Jakub
Hi Luiz,
On Wed, Oct 28, 2015 at 1:52 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Jakub,
>
> On Wed, Oct 28, 2015 at 5:34 PM, Jakub Pawlowski <[email protected]> wrote:
>> Hi Johan
>>
>> On Wed, Oct 28, 2015 at 1:13 AM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Jakub,
>>>
>>> On Wed, Oct 28, 2015 at 6:10 AM, Jakub Pawlowski <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> struct btd_profile contains folowing callbacks:
>>>> .connect
>>>> .disconnect
>>>> .device_probe
>>>> .device_remove
>>>> .accept
>>>>
>>>> I noticed that those callbacks:
>>>> .device_probe
>>>> .device_remove
>>>> .accept
>>>>
>>>> are called properly, but:
>>>> .connect
>>>> .disconnect
>>>>
>>>> callbacks are not being called at all when LE device disconnected
>>>> itself or was connected or autoconnected back. There is no doc, but
>>>> I'm guessing those should be triggered in this cases, right ? Also,
>>>> when I connect first time to a device, only .accept should be
>>>> triggered, but when I connect next time only .connect ?
>>>> Can you please explain what is the intended order of those callbacks ?
>>>> Then I can fix them if I find some discrepencies from intended
>>>> behaviour.
>>>
>>>
>>> Actually it is working as intended since for LE the GATT based drivers
>>> are not responsible for the connection management, unless LE CoC is
>>> used. We actually have an item in the TODO to move the connection
>>> management back to core to simplify the drivers.
>>
>> Ok, so let's say I want to rewrite HoG profile. How do I detect device
>> was connected/disconnected ?
>
> You will get the accept callback which at than you can get access to
> bt_gatt_client, for disconnection the idea is that you register a
> callback directly to bt_att but perhaps we need some other mechanism.
Ok, so here I assumed that .disconnect callback will be called on
disconnections, and that .connect callback will be called on
re-connections, which is not true.
That means that HoG will continue using btd_device_add_attio_callback
to get connected/disconnected ? That is fine for HoG, but what about
profiles that don't want to autoconnect (calling
btd_device_add_attio_callback triggers autoconnect)
> Anyway we first need to move to bt_hog instead.
>
>> Or how do I get current db and client handles that I can use for all operations?
>
> That sound strange, you just have done this for device_info and you
> don't know it? From the accept callback you get the device and with
> that you can access the db that should contain all the details, anyway
> we should probably change bt_hog to use bt_gatt_client and gatt_db
> internally so we can share with android code.
I know how to obtain db and client when .accept is called, but if
device is disconnected and then re-connected those instances will be
no longer valid, right ?
I would have to obtain db and device again, and all I have in
attio_connected_cb is GAttrib, which have no reference to db or
client.
>
>
> --
> Luiz Augusto von Dentz
Hi Jakub,
On Wed, Oct 28, 2015 at 5:34 PM, Jakub Pawlowski <[email protected]> wrote:
> Hi Johan
>
> On Wed, Oct 28, 2015 at 1:13 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Jakub,
>>
>> On Wed, Oct 28, 2015 at 6:10 AM, Jakub Pawlowski <[email protected]> wrote:
>>> Hi,
>>>
>>> struct btd_profile contains folowing callbacks:
>>> .connect
>>> .disconnect
>>> .device_probe
>>> .device_remove
>>> .accept
>>>
>>> I noticed that those callbacks:
>>> .device_probe
>>> .device_remove
>>> .accept
>>>
>>> are called properly, but:
>>> .connect
>>> .disconnect
>>>
>>> callbacks are not being called at all when LE device disconnected
>>> itself or was connected or autoconnected back. There is no doc, but
>>> I'm guessing those should be triggered in this cases, right ? Also,
>>> when I connect first time to a device, only .accept should be
>>> triggered, but when I connect next time only .connect ?
>>> Can you please explain what is the intended order of those callbacks ?
>>> Then I can fix them if I find some discrepencies from intended
>>> behaviour.
>>
>>
>> Actually it is working as intended since for LE the GATT based drivers
>> are not responsible for the connection management, unless LE CoC is
>> used. We actually have an item in the TODO to move the connection
>> management back to core to simplify the drivers.
>
> Ok, so let's say I want to rewrite HoG profile. How do I detect device
> was connected/disconnected ?
You will get the accept callback which at than you can get access to
bt_gatt_client, for disconnection the idea is that you register a
callback directly to bt_att but perhaps we need some other mechanism.
Anyway we first need to move to bt_hog instead.
> Or how do I get current db and client handles that I can use for all operations?
That sound strange, you just have done this for device_info and you
don't know it? From the accept callback you get the device and with
that you can access the db that should contain all the details, anyway
we should probably change bt_hog to use bt_gatt_client and gatt_db
internally so we can share with android code.
--
Luiz Augusto von Dentz
Hi Johan
On Wed, Oct 28, 2015 at 1:13 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Jakub,
>
> On Wed, Oct 28, 2015 at 6:10 AM, Jakub Pawlowski <[email protected]> wrote:
>> Hi,
>>
>> struct btd_profile contains folowing callbacks:
>> .connect
>> .disconnect
>> .device_probe
>> .device_remove
>> .accept
>>
>> I noticed that those callbacks:
>> .device_probe
>> .device_remove
>> .accept
>>
>> are called properly, but:
>> .connect
>> .disconnect
>>
>> callbacks are not being called at all when LE device disconnected
>> itself or was connected or autoconnected back. There is no doc, but
>> I'm guessing those should be triggered in this cases, right ? Also,
>> when I connect first time to a device, only .accept should be
>> triggered, but when I connect next time only .connect ?
>> Can you please explain what is the intended order of those callbacks ?
>> Then I can fix them if I find some discrepencies from intended
>> behaviour.
>
>
> Actually it is working as intended since for LE the GATT based drivers
> are not responsible for the connection management, unless LE CoC is
> used. We actually have an item in the TODO to move the connection
> management back to core to simplify the drivers.
Ok, so let's say I want to rewrite HoG profile. How do I detect device
was connected/disconnected ?
Or how do I get current db and client handles that I can use for all operations?
>
> --
> Luiz Augusto von Dentz
Hi Jakub,
On Wed, Oct 28, 2015 at 6:10 AM, Jakub Pawlowski <[email protected]> wrote:
> Hi,
>
> struct btd_profile contains folowing callbacks:
> .connect
> .disconnect
> .device_probe
> .device_remove
> .accept
>
> I noticed that those callbacks:
> .device_probe
> .device_remove
> .accept
>
> are called properly, but:
> .connect
> .disconnect
>
> callbacks are not being called at all when LE device disconnected
> itself or was connected or autoconnected back. There is no doc, but
> I'm guessing those should be triggered in this cases, right ? Also,
> when I connect first time to a device, only .accept should be
> triggered, but when I connect next time only .connect ?
> Can you please explain what is the intended order of those callbacks ?
> Then I can fix them if I find some discrepencies from intended
> behaviour.
Actually it is working as intended since for LE the GATT based drivers
are not responsible for the connection management, unless LE CoC is
used. We actually have an item in the TODO to move the connection
management back to core to simplify the drivers.
--
Luiz Augusto von Dentz