Hi Pauli, On Sat, Feb 15, 2025 at 1:27 PM Pauli Virtanen <pauli.virtanen@xxxxxx> wrote: > > Hi, > > pe, 2025-02-14 kello 15:32 -0500, Luiz Augusto von Dentz kirjoitti: > > On Fri, Feb 14, 2025 at 3:21 PM Luiz Augusto von Dentz > > <luiz.dentz@xxxxxxxxx> wrote: > > > > > > From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > > > > > > This introduces PreferredBearer property which can be used to indicate > > > what bearer shall be connected first rather than just using last seen > > > bearer which may not work always since it seems some devices sometimes > > > advertises on LE bearer but expects connections over BR/EDR e.g: > > > > > > https://github.com/bluez/bluez/issues/1092 > > > > > > Also with the introduction of LE Audio this might become even more of a > > > problem since most likely users would like to select which bearer to use > > > rather than using the last-seen policy. > > > --- > > > doc/org.bluez.Device.rst | 23 ++++++++++++++++++++++- > > > 1 file changed, 22 insertions(+), 1 deletion(-) > > > > > > diff --git a/doc/org.bluez.Device.rst b/doc/org.bluez.Device.rst > > > index f8d4a68a6b41..e3cf4d12b173 100644 > > > --- a/doc/org.bluez.Device.rst > > > +++ b/doc/org.bluez.Device.rst > > > @@ -40,7 +40,8 @@ void Connect() > > > are skip and check latest seen bearer. > > > > > > 3. Connect last seen bearer, in case the timestamps are the same BR/EDR > > > - takes precedence. > > > + takes precedence, or in case **PreferredBearer** has been set to a > > > + specific bearer then that is used instead. > > > > > > Possible errors: > > > > > > @@ -346,3 +347,23 @@ array{object, dict} Sets [readonly, experimental] > > > :byte Rank: > > > > > > Rank of the device in the Set. > > > + > > > +string PreferredBearer [readwrite, optional, experimental] > > > +`````````````````````````````````````````````````````````` > > > + > > > + Indicate the preferred bearer when initiating a connection, only > > > + available for dual-mode devices. > > > + > > > + Possible values: > > > + > > > + :"last-seen": > > > + > > > + Connect to last seen bearer first. Default. > > > + > > > + :"bredr": > > > + > > > + Connect to BR/EDR first. > > > + > > > + :"le": > > > + > > > + Connect to LE first. > > > -- > > > 2.48.1 > > > > Please have a look at this since we might need some integration with > > upper layers, at very least bluetooth settings needs to be involved, > > this is similar to the likes of Windows and Android settings which > > allows enabling LE Audio on per device basis but instead of being > > specific to LE Audio, which rules out other services that maybe > > exposed over LE, this enables the connection policy to be tuned per > > bearer. Now there maybe another policy which we could use which is to > > do dual-mode, but I don't think headsets will deal nicely with that, > > specially because no-one seem to be doing it, that said that would > > make things simpler since we could expose things to be just a > > codec/transport switch rather than a entire bearer switch. > > This sounds like like it could solve the problem that currently we more > or less have to set ControllerMode=le to get LE Audio on initial > pairing. > > In Pipewire this probably allows adding an user selectable "profile" > entry for LE Audio when connected via bredr, which would switch bearer > and issue disconnect + reconnect. > > Probably Gnome BT settings also would need to grow a corresponding > setting. Labeling such setting so that people understand it is maybe > harder... > > There's a few questions: > > - Is there something that tells which bearers are available for a > device? It would probably be needed too if it doesn't exist. The presence of PreferredBearer will indicate the device is a dual-mode, LE+BR/EDR, otherwise you can use the address type to determine what bearer it is but in that case you only have one bearer so I don't think it is useful. > - Interaction with CSIP, if you pair initially with bredr I think you > don't get the other earbud paired. If you switch bearer + disconnect + > connect, does it pair & connect the other one? I think we would normally try to do cross transport pairing automatically, if that is not currently happening then perhaps there is a bug, anyway as part of this exercise we can check how dual-mode is working and if there is some technical debt like this. > - Who is going to be the agent that accepts the pairing of the other > CSIP devices? GNOME BT settings I think is not running all time (and > does it do CSIP accepts?). Usually it is quick enough that once you attempt to connect to one member the other are pick up immediately so I assume this is not really a problem, well except if there is a problem and the other set members are not advertising or something, we could in theory bypass authentication based on other set members in case of just-works method since we are already doing this when there is a call to Device.Pair for example (see baafe60d9cbbd9e7939fb6d050d9896731d1ac70). > - Whether disconnect+reconnect should be needed to switch the bearer, > or if just changing the property is enough if already connected? Maybe > it is needed? Hmm, are asking about changing the property would trigger procedures in case it is already connected? I guess we will need to decide if that is required, it is not that great to pass errors via reply to a property change and I'd assume that even if the reconnection fails the idea is that the new policy persist so I think we would be better off not attempting to do anything when the property is changed and wait the user to disconnect, etc, and in that case I wouldn't put anything at pipewire to attempt to switch the PreferredBearer since this is sort of out of the Media* interface it probably shall be controlled by Bluetooth settings rather than audio, Id only recommend messing around with bearer switch if we ever implement the dual-mode bearer since then it is just a matter of switching the MediaTransport, but I don't think headsets realize they could allow dual-mode topology and instead just restrict the number of stream just as HFP and A2DP cannot be used simultaneously. > > -- > Pauli Virtanen -- Luiz Augusto von Dentz
