Hi Bastien, On Thu, Nov 19, 2020 at 2:53 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > 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. Some proprietary protocols may not want to become an internal BlueZ plugin, for example because it is developed closed source. D-Bus API is useful to support these cases. > > > > > > > > > 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. I am considering doing this. Let me think it through to make sure we don't stumble on anything in the future if we do it this way. > > > > > > > >
