On Wednesday 10 June 2020 10:27:25 Marcel Holtmann wrote: > Hi Pali, > > > This utility is very useful for determining which A2DP codecs are supported > > by remote side. So install it to system as part of bluez package. > > --- > > Makefile.tools | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Makefile.tools b/Makefile.tools > > index 9b9236609..d52721612 100644 > > --- a/Makefile.tools > > +++ b/Makefile.tools > > @@ -176,9 +176,9 @@ endif > > if TOOLS > > bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ > > tools/bluemoon tools/hex2hcd tools/mpris-proxy \ > > - tools/btattach > > + tools/btattach tools/avinfo > > > > -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \ > > +noinst_PROGRAMS += tools/bdaddr tools/avtest \ > > tools/scotest tools/amptest tools/hwdb \ > > tools/hcieventmask tools/hcisecfilter \ > > tools/btinfo tools/btconfig \ > > I had no intention to install that tool since it is too limited Sorry, but I have not seen any limitations with this tool yet. I'm using it very often. And also other people who use it have not mentioned any limitations or problems. So could you be more specific what are those limitations? Also it is the first thing which I'm saying people that should run and send me output of it if something related to A2DP does not work. And because linux distributions do not package this utility and bluez developers (for me for unknown reasons) decided to not install it, result is that people have to always compile bluez from source to run this utility if their A2DP audio does not work or "remote" debugging of A2DP is needed. So result is that who want to know why A2DP audio does not work is forced to compile & install bluez from sources and not to use from distribution package. And this probably not the expected state. In any case, nobody reported to me any limitation with one exception that it cannot decode capabilities of some custom vendor codecs. But most of them are already supported as I sent needed patches in past. > and makes too many assumption. For example which assumptions? > In addition it has a bad name with no Bluetooth prefix. So, lets rename it. What about "btavinfo"? > If we think it is useful to have such a test utility, then we need to clean this up first What exactly to clean up first? Note that I have already done cleanup of this utility. > and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes. I do not see how btinfo can be used for A2DP purposes. Seems this is utility for local controller info and not for remove A2DP.
