Hi Marcel, On Mon, Aug 17, 2020 at 4:07 PM Yu Liu <yudiliu@xxxxxxxxxx> wrote: > > From: Archie Pusaka <apusaka@xxxxxxxxxxxx> > > Initially this is introduced to query whether WBS is supported by the adapter, > the API is generic enough to be extended to support querying others in > the future. > > Reviewed-by: sonnysasaka@xxxxxxxxxxxx > > Signed-off-by: Yu Liu <yudiliu@xxxxxxxxxx> > --- > > Changes in v2: > - Return an array of strings instead of a dict > > Changes in v1: > - Initial change > > doc/adapter-api.txt | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > index 1a7255750..8fbcadb54 100644 > --- a/doc/adapter-api.txt > +++ b/doc/adapter-api.txt > @@ -204,6 +204,18 @@ Methods void StartDiscovery() > org.bluez.Error.NotReady > org.bluez.Error.Failed > > + array{string} GetCapabilities() > + > + This method returns a list of supported > + capabilities that is populated when the adapter > + initiated. > + > + Possible values: > + "wbs" - Wide band speech Btw, should we stick to use wbs terminology here, or we should actually use the HCI feature/command, because wbs has actually to be implemented by the HFP afaik this is only indicating that the controller is able to notify packets drops, etc, with use of erroneous command. Perhaps we should actually use the term PLC (Packet Loss Concealment) instead since that seems to be the real capability here, afaik WBS does not actually require PLC. > + > + Possible errors: org.bluez.Error.NotReady > + org.bluez.Error.Failed > + > Properties string Address [readonly] > > The Bluetooth device address. > -- > 2.28.0.220.ged08abb693-goog > -- Luiz Augusto von Dentz