Re: GATT Dbus API on BlueZ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Chen Ganir,

On Tue, Oct 25, 2011 at 10:19 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote:
> Claudio
>
>> -----Original Message-----
>> From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx]
>> Sent: Tuesday, October 25, 2011 2:53 PM
>> To: Ganir, Chen
>> Cc: linux-bluetooth@xxxxxxxxxxxxxxx
>> Subject: Re: GATT Dbus API on BlueZ
>>
>> Hi Chen Ganir,
>>
>> On Tue, Oct 25, 2011 at 4:38 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote:
>> > Hi.
>> >
>> > Currently, the DBUS API for GATT Client will allow discovering
>> characteristics and services, connecting to the peer device if
>> required. However, when the operation is done, the link is dropped (no
>> more attio registered). The only way to register a global gatt_service-
>> >attio and keep the connection alive all the time is to register a
>> characteristic watcher. Is there another way to do it ? I'd like to
>> keep the link a live (for example, implementing a proximity link loss
>> profile on top of the DBUS GATT Client) without the need for a watcher.
>> >
>> > Thanks,
>> > Chen Ganir
>> >
>> >
>>
>> At the moment there isn't another way to keep the link up. GATT
>> Profiles have different connection requirements, you will need a
>> dynamic mechanism anyway. The callback registration is the mechanism
>> to inform the core that connection is required. If you keep the
>> connection always up it will be necessary a function to get access to
>> the GAttrib instance and a way to notify that the connection has been
>> established.
>>
>> I tried to remove the association between GAttrib and GIOChannel. The
>> idea was to create GAttrib even if the link is disconnected, but the
>> effort doesn't worth. We will have problems with MTU and GATT
>> abstractions for read long.
>>
>> Do have another suggestion to control connections and control the ATT
>> request/response queue?
>>
>> BR,
>> Claudio
>
> Thanks for the reply.
>
> However, I did not quite understand your response, nor the relevancy to read long.
>
> My basic requirement is to allow a profile to control the connection - meaning that if I implement a proximity or other profile over dbus, I would like to be able to tell it to connect, discover services, discover characteristics, poll from time to time the value of a certain GATT char, or simply idle and wait for disconnection (like proximity does) or notification/indication. When using dbus-send I end up with a disconnected link at the end of the process. Do you think the disconnection results from the termination of the dbus-send application, or is it something else ?
>
> Thanks,
> Chen Ganir.
>
>

You are disabling all the GATT plugins, so my suggestion is: open the
ATT L2CAP socket directly in your JNI bindings. Using this approach
you will have all the control that you need.

We track the users/clients based on the D-Bus connection, if the
client(dbus-send or any other) leaves the bus the core will disconnect
link if watcher list is empty.

BR,
Claudio.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux