From: Chen Ganir <chen.ganir@ti.com>
To: <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
Date: Thu, 16 Aug 2012 15:14:52 +0300 [thread overview]
Message-ID: <502CE43C.7040804@ti.com> (raw)
In-Reply-To: <20120816113941.GA20887@x220>
On 08/16/2012 02:39 PM, Johan Hedberg wrote:
> Hi Chen,
>
> On Thu, Aug 16, 2012, chen.ganir@ti.com wrote:
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -179,3 +179,8 @@ Properties string Address [readonly]
>> Note that this property can exhibit false-positives
>> in the case of Bluetooth 2.1 (or newer) devices that
>> have disabled Extended Inquiry Response support.
>> +
>> + array{string} Batteries [readonly]
>> +
>> + List of device battery object paths that represents the available
>> + batteries on the remote device.
>
> I don't think it's ok to pollute the Device interface or src/device.c
> with profile-specific details. That should happen in profile-specific
> plugins and interfaces. Since we're switching over to object manager
> maybe an interface/property like this isn't needed at all? (even if it
> would be needed the type should be array{object} and not array{string}
You are correct, the array should be object instead of string. However,
i fail to understand why the object manager prevents this from getting
accepted - do you have a time estimation when the object manager should
be active or available ? I do not think this patch set should be
deferred until we have changed the dbus API.
I prefer this way of putting the batteries below the device, since it is
obvious which battery belongs to each device. The other option i can
think of is to have another interface registered on the device object path:
Service org.bluez
Interface org.bluez.Batteries
Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
Methods dict GetProperties()
Returns all properties for the interface. See the
Properties section for the available properties.
Signals ProperyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} Batteries [readonly]
List of device battery object paths that represents the available
batteries on the remote devices.
Service org.bluez
Interface org.bluez.Battery
Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
Methods dict GetProperties()
Returns all properties for the interface. See the
Properties section for the available properties.
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties byte Level [readonly]
Battery level (0-100).
Any other suggestion ?
>
> Johan
>
--
BR,
Chen Ganir
Texas Instruments
next prev parent reply other threads:[~2012-08-16 12:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 9:34 [PATCH v4 0/10] Add GATT Client Battery Service chen.ganir
2012-08-16 9:34 ` [PATCH v4 01/10] Battery: Add Battery Service Gatt Client chen.ganir
2012-08-16 11:39 ` Johan Hedberg
2012-08-16 12:14 ` Chen Ganir [this message]
2012-08-16 12:44 ` Johan Hedberg
2012-08-16 12:55 ` Chen Ganir
2012-08-16 19:24 ` Johan Hedberg
2012-08-20 13:03 ` Luiz Augusto von Dentz
2012-08-26 7:04 ` Chen Ganir
2012-08-28 1:04 ` Johan Hedberg
2012-08-16 9:34 ` [PATCH v4 02/10] Battery: Add Battery Service plugin skeleton chen.ganir
2012-08-16 9:34 ` [PATCH v4 03/10] Battery: Add connection logic chen.ganir
2012-08-16 9:34 ` [PATCH v4 04/10] Battery: Discover Characteristic Descriptors chen.ganir
2012-08-16 9:34 ` [PATCH v4 05/10] Battery: Get Battery ID chen.ganir
2012-08-16 9:34 ` [PATCH v4 06/10] Battery: Add Battery list to btd_device chen.ganir
2012-08-16 9:35 ` [PATCH v4 07/10] Battery: Read Battery level characteristic chen.ganir
2012-08-16 9:35 ` [PATCH v4 08/10] Battery: Add Battery D-BUS API chen.ganir
2012-08-16 9:35 ` [PATCH v4 09/10] Battery: Add support for notifications chen.ganir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502CE43C.7040804@ti.com \
--to=chen.ganir@ti.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.