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? that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation. >> In addition it has a bad name with no Bluetooth prefix. > > So, lets rename it. What about "btavinfo"? Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them. > >> 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. This needs a bit thinking, but pretty much simple things like this: btinfo local btinfo avdtp <remote_bdaddr> We can create a module handling system so that you can easily links existing tiny utilities into one. Regards Marcel
