| Message ID | 20250214202129.968369-1-luiz.dentz@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [BlueZ,v1] org.bluez.Device: Introduced PreferredBearer | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/pre-ci_am | success | Success |
| tedd_an/BuildEll | success | Build ELL PASS |
| tedd_an/BluezMake | success | Bluez Make PASS |
| tedd_an/MakeCheck | success | Bluez Make Check PASS |
| tedd_an/MakeDistcheck | success | Make Distcheck PASS |
| tedd_an/CheckValgrind | success | Check Valgrind PASS |
| tedd_an/CheckSmatch | success | CheckSparse PASS |
| tedd_an/bluezmakeextell | success | Make External ELL PASS |
| tedd_an/ScanBuild | success | Scan Build PASS |
Hi Pauli, Bastien, On Fri, Feb 14, 2025 at 3:21 PM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > 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 is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=934171 ---Test result--- Test Summary: CheckPatch PENDING 0.29 seconds GitLint PENDING 0.27 seconds BuildEll PASS 20.26 seconds BluezMake PASS 1450.79 seconds MakeCheck PASS 12.91 seconds MakeDistcheck PASS 158.43 seconds CheckValgrind PASS 215.68 seconds CheckSmatch PASS 283.75 seconds bluezmakeextell PASS 97.88 seconds IncrementalBuild PENDING 0.39 seconds ScanBuild PASS 861.14 seconds Details ############################## Test: CheckPatch - PENDING Desc: Run checkpatch.pl script Output: ############################## Test: GitLint - PENDING Desc: Run gitlint Output: ############################## Test: IncrementalBuild - PENDING Desc: Incremental build with the patches in the series Output: --- Regards, Linux Bluetooth
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@gmail.com> wrote: > > > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > > > 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. - 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? - 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?). - 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?
Hey, On Sat, 2025-02-15 at 20:27 +0200, Pauli Virtanen wrote: > <snip>robably 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. > > - 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? > > - 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?). > > - 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? I don't have access to any CSIP supported devices, which is one of the reasons why gnome-bluetooth has no support for it. I think that the AX210 I have has support for CSIP on the adapter side, but I would need to know what cheap device I could get that supports it. This is tracked in: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/130
Hi Pauli, On Sat, Feb 15, 2025 at 1:27 PM Pauli Virtanen <pauli.virtanen@iki.fi> 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@gmail.com> wrote: > > > > > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > > > > > 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
ma, 2025-02-17 kello 16:39 +0100, Bastien Nocera kirjoitti: > Hey, > > On Sat, 2025-02-15 at 20:27 +0200, Pauli Virtanen wrote: > > <snip>robably 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. > > > > - 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? > > > > - 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?). > > > > - 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? > > I don't have access to any CSIP supported devices, which is one of the > reasons why gnome-bluetooth has no support for it. > > I think that the AX210 I have has support for CSIP on the adapter side, > but I would need to know what cheap device I could get that supports > it. > > This is tracked in: > https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/130 Of the devices I have, Sony Linkbuds S has working CSIP + LE Audio. It does not support duplex at 48 kHZ, so Pipewire needs to have some config to disable input direction for it to work. https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/LE-Audio-+-LC3-support Samsung Galaxy Buds2 Pro, and Creative Zen Hybrid initially had firmware that had working LE Audio, but the manufacturer broke it somehow in later FW updates. These devices now refuse to Enable streams or even connect. Not clear what the firmware of these devices is expecting to get. *** How it currently works in Gnome Settings: Earbuds appear as two devices with the same name. If you pair one earbud, it'll after some seconds ask if you accept that a device with the same name as you just paired wants to pair. If you connect one, also the other one usually connects after a few seconds. Devices also autoconnect if they were previously connected. If you disconnect one, though, it only disconnects one of the two earbuds. The other one remains as available sound device, but now with just one channel. So the basics work, similarly as in bluetoothctl, but it may be somewhat confusing to users.
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.
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 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(-)