On Tue, 2020-11-17 at 14:22 -0800, Sonny Sasaka wrote: > 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. But you don't need to go over D-Bus to implement this. > > > > > 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 > . Right. My advice would have been to say "the properties exported by BatteryProvider1 API match the properties exported by the Battery1 API", so you don't need to update 2 APIs separately when the API is extended. > > >
