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. 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.
