Hi Bastien, On Tue, Nov 17, 2020 at 2:22 PM Sonny Sasaka <sonnysasaka@xxxxxxxxxxxx> 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. Adding to mention that in Chrome OS we also plan to have a plugin to decode Pixel Buds 2 multiple battery values (left, right, and case). We have not yet decided whether this is going to be internal plugin or external client though. But generally the API should allow this kind of feature as well. > > > > > 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. > > >
