On Thu, 2017-09-07 at 17:15 +0300, Luiz Augusto von Dentz wrote: > Hi Bastien, > > On Thu, Sep 7, 2017 at 5:03 PM, Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > On Thu, 2017-09-07 at 01:16 +0200, Bastien Nocera wrote: > > > On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote: > > > > On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote: > > > > > > > > > > > > > <snip> > > > > > I assumed that it is forbidden to include HID battery > > > > > reporting > > > > > events via the GATT HID descriptors. I think the standard > > > > > clearly > > > > > says these have to come via battery service and not via HID. > > > > > > > > So we're back to implementing battery reporting as a separate > > > > profile. > > > > What would be a good example/skeleton to use to implement this? > > > > > > This is what I managed to do so far: > > > https://github.com/hadess/bluez/commits/ble-battery > > > > > > A first (gentle) pass at a review would be nice, especially if > > > there's > > > a better way to get notifications on both the attributes in one > > > go. > > > > Obviously, the reworked code I wrote at 1 AM didn't work correctly. > > I've fixed the copy/paste bugs and pushed it. > > > > > The second question is how I would export this. > > > > > > I'm currently thinking that exporting a new interface on the > > > device > > > itself might be the best idea, and I'll monitor devices directly > > > in > > > UPower to export them to desktops. Would that be a good way? > > > > Still unsure about this, comments welcome. > > > > > And as UPower will be the likely consumer of this data, I think > > > I'll > > > try mapping this set of flags: > > > https://www.bluetooth.com/specifications/gatt/viewer?attributeXml > > > File > > > =org.bluetooth.characteristic.battery_power_state.xml > > > to UPower properties rather than trying to export it as-is. > > > > I've written parsing code for this. Does anyone know of a device > > which > > would use the Battery Power State characteristic so I could try it > > out? > > > > Finally, I've realised that my code replicates a lot of the code in > > bas.[ch], which is only used by the hog profile plugin. Seeing as > > this > > does nothing (the Battery Level is at the same level as the HoG > > characteristics, not a child of it), I've removed it. > > We should probably make similar changes to what was done in dis.c so > it can operate with gatt_db directly instead of doing its own > discovery. This is what I came up with: $ gdbus introspect --system --dest org.bluez --object-path /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX --only-properties node /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX { <snip> interface org.bluez.Battery1 { properties: readonly b Present = true; readonly b Rechargeable = false; readonly n Percentage = 86; readonly s State = ''; readonly s WarningLevel = ''; }; $ gdbus monitor --system --dest org.bluez --object-path /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX Monitoring signals on object /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX owned by org.bluez The name org.bluez is owned by :1.645 /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Device1', {'Connected': <true>}, @as []) /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Present': <true>, 'Percentage': <int16 100>}, @as []) /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Device1', {'ServicesResolved': <true>, 'Paired': <true>}, @as []) /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 99>}, @as []) /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 98>}, @as []) /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 97>}, @as []) Code is at: https://github.com/hadess/bluez/commits/ble-battery I've only compile-tested the Battery State reporting, as I don't have a device that implements it. If somebody knows of one, let me know and I'll look into buying it for testing. If the general code and interface are agreeable, I'll go ahead and implement the UPower side of things, and then the API documentation for bluez itself. Cheers -- 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
