Re: [PATCH] Install avinfo utility

["Pali Rohár" <pali@kernel.org>]

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.