Hi Bastien, More responses below. On Tue, Nov 17, 2020 at 10:01 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > On Tue, 2020-11-17 at 11:51 +0100, Bastien Nocera wrote: > > < > > <snip> didn't review the code in depth, but, having written this > > mechanism > > for Bluetooth battery reporting, I think that this is the right way > > to > > go to allow daemons like pulseaudio to report battery status. > > It would also be useful to know what external components, or internal > plugins you expect to feed this API. BlueZ could have internal plugins to read proprietary battery reporting, e.g. JBL speakers and Bose QC35. > > Apparently HSP/HFP, for example, provide more information that what can > be expressed with the Battery1 API, whether it is charging or not, or > whether a battery level is unknown, etc. > > So I would say that, even if the current battery API is extended, we > need to make sure that the D-Bus API to feed new data is extensible > enough to allow new properties, and they don't need to be added > separately to org.bluez.BatteryProvider1 or org.bluez.Battery1. I proposed the API to start simple, but I believe that it can always be extended as we need in the future so I don't think the additional features need to be coded now. I documented how this API could evolve in the future by extending other features as well in this design document that I shared with Luiz and Marcel: https://docs.google.com/document/d/1OV4sjHLhTzB91D7LyTVT6R0SX2vXwSG1IA3q5yWQWps. >
