On Wednesday 10 June 2020 19:31:47 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? > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation. Marcel, but this is not a problem. For that one purpose which avinfo provides it ideal and works fine. Personally I do not see any problem with it. > >> 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. This looks like a not-so-trivial task and moreover independent of providing current version of avinfo to users. avinfo already exists, is already part of bluez project, it is already compiling during bluez build and is already used by me and lot of other users and works for that one purpose as expected. > > > >> 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. I'm not against this change. But this is additional work which needs to be done. And it would not happen today or tomorrow unless you have already patches which implement it. As I said avinfo is already there, implemented, it is working and is part of bluez source code. And is basically the first step when debugging issues with A2DP audio. So what is the real issue with not only compiling this avinfo tool during building bluez but also installing it?
