Hi Marijn, On Wed, Oct 9, 2024 at 6:30 AM Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx> wrote: > > On 2024-10-07 11:56:06, Luiz Augusto von Dentz wrote: > > Hi Marijn, > > > <snip> > > > diff --git a/src/main.conf b/src/main.conf > > > index fff13ed2f..b6b32a720 100644 > > > --- a/src/main.conf > > > +++ b/src/main.conf > > > @@ -316,6 +316,15 @@ > > > # notifications. > > > #VolumeCategory = true > > > > > > +# Require peer AVRCP controllers to have at least version 1.4 before > > > +# accessing category-2 (absolute volume) features (depending on the value > > > +# of VolumeCategory above). It is common for Android-powered devices to not > > > +# signal the desired minimum version of 1.4 while still supporting absolute > > > +# volume based on the feature category bit, as mentioned in this comment: > > > +# https://android.googlesource.com/platform/system/bt/+/android-12.0.0_r1/bta/ > > > +# av/bta_av_main.cc#621 > > > +#VolumeVersion = false > > > > I'd change this to have the version e.g. #VolumeVersion = 1.4, so the > > user can switch to 1.3 or "any" in case he want to bypass version > > checking > > We can surely change this to parse a version which would override the version > of the remote CT, and rename it to CTVersion since it's no longer only affecting > volume? Maybe add a TGVersion as well, and/or something else entirely? > > That would save the ugly combinatorial explosion. Maybe the same works for > VolumeCategory introduced in the previous patch as well? Yeah, well we could do something to disable strict version check so we rely only on capabilities, anyway a good way to avoid interoperability problems is to be very strict to the spec to what we send but more relaxed to what we receive, the latter may not be possible if there are qualification tests that requires us to strict though. > > also perhaps we should create an issue for Android folks to > > fix their version, as it seems they do support browsing features > > channel for TG they should be able to do the same for CT. > > I don't think this patch aged particularly well as hinted by the testing > steps in the cover letter: on my Android 14 phone AVRCP 1.5 is the default in > developer settings, so they might have realized that this was a problem in the > past. Don't think we need to report it anymore, and we should perhaps start > discussing whether this patch is still desired in the first place? Either way > I'd appreciate to land the first and second patch. Oh, in that case why are we even bothering to change this? Or this is to allow working with Android when the user has set it to AVRCP 1.3, well that still sound like a bug if you ask me, even if it is not the default behavior that should have been 1.4. > - Marijn > > > > + > > > [Policy] > > > # > > > # The ReconnectUUIDs defines the set of remote services that should try > > > -- > > > 2.46.2 > > > > > > > > > -- > > Luiz Augusto von Dentz -- Luiz Augusto von Dentz
