Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client

Hi Chen,

On Sun, Aug 26, 2012, Chen Ganir wrote:

So what do you suggest here ? Calculating an average ? How shoudl it
be done ? If 2 batteries are available, first is 100% and the second
is 50%, we should simply set the value as 75%? I'm not so sure that we
should make such decisions for the end user.

quoted

Another thing that worth adding is that there are other profiles that
do support battery status such as HFP and AVRCP, so I think this
should be made generic enough so other sources could be supported.

The internal device API uses the device_add_battery(...) and
device_remove_battery(...) to allow adding/removing batteries to the
device battery list, but it is the responsibility of the profile to
register a D-Bus interface, and update.

I could redesign this, to add a generic battery API, which will
expose a new API, such as battery_add(battery_struct* batt),
battery_remove(battery_struct* batt) and
battery_update(battery_struct* batt) which will allow a more generic
approach. This Battery module will be responsible for
registering/unregistering the D-Bus API, and profiles which need to
use it will simply use the exposed API to add/remove/update. The
batt_structure will also include some callback functions to be
called when a value is queried for example, or if a device is
removed. The LE Battery plugin will use the GATT to
read/write/receive notification, and use the Generic Battery
interface to interface with the external world. What do you think
about it ?

I had a brief chat with Marcel about this and the following were the
main conclusions:

1. It'd be nice to have support for this added to UPower so that it can
enumerate Bluetooth batteries.

2. The easiest way to do 1. would be to have this one D-Bus object per
battery.

3. Use uint16 instead of byte to keep our D-BUs API consistent wrt.
unsigned integers (byte is signed).

4. No Adapter property or interface needed once we've merged the object
manager patches.

5. (as you proposed) we'll probably want/need a src/device.c API for
device drivers to register batteries. Other profiles supporting battery
info (AVRCP, HFP, etc) could use the same API.

Johan