diff mbox series

[BlueZ,v2,2/2] client: Update transport.select documentation

Message ID 20250127093004.19268-3-iulia.tanasescu@nxp.com (mailing list archive)
State Accepted
Commit 46fbbd600578a7edc17a1b76ac6b8673335cc601
Headers show
Series client/player: Rework transport.select | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success

Commit Message

Iulia Tanasescu Jan. 27, 2025, 9:30 a.m. UTC
This updates the transport.select documentation to explain the expected
behavior when selecting multiple transports and when an audio server is
involved.
---
 client/bluetoothctl-transport.rst | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
diff mbox series

Patch

diff --git a/client/bluetoothctl-transport.rst b/client/bluetoothctl-transport.rst
index c7a57716f..39b7fad2b 100644
--- a/client/bluetoothctl-transport.rst
+++ b/client/bluetoothctl-transport.rst
@@ -56,8 +56,17 @@  the transport to the "broadcasting" state, pending acquire.
 :Usage: **> select <transport> [transport1...]**
 
 Note:
-If running the setup with an audio server that has LE Audio support (such as PipeWire), it will
-prompt it to automatically acquire the transport.
+
+If the select command receives a list of transports, they will first be linked using the
+"Links" MediaTransport property. They will then be selected one by one, by calling
+the "Select" MediaTransport method. After the first transport is acquired, the Broadcast
+Sink will create fds for the associated stream and all its links. Each link can then be
+acquired one by one, setting the fd for the transport and starting to receive audio.
+
+The select command does not require a local endpoint to be registered beforehand. This is
+because if the setup runs with an audio server that has LE Audio support (such as PipeWire),
+the audio server is the one to register endpoints and the transports are created as a result.
+Once a transport is selected, the audio server will automatically acquire.
 
 unselect
 --------