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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).