Re: [PATCH BlueZ v1] org.bluez.Device: Introduced PreferredBearer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

- 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?

-- 
Pauli Virtanen





[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux