You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to add CAP support in BlueZ. Here are some topics:
How should the application set/change the Context Type?
At this moment, the context type is specified via endpoint registration. The CAP specification allows the setting of Streaming Audio Contexts LTV dynamically. This could be a property of the MediaTransport.
Acquiring a transport would require writing the Lock database attribute for all transports in the corresponding set, before the actual procedure.
If the device have the lock set, just send an Acquire reply with failure over DBUS.
All the members of a coordinated set are kept inside "org.bluez.DeviceSet1" Devices list.
This means that the upper layer (i.e. Pipewire) has to take care of the whole ranking part and call "Acquire" for all transports belonging to the same Coordinated Set (in the order of the ranks). In case any of them is failing, then all the transports in the set should be released.
CAP specification says that if a lock is set on any device in the Coordinated Set, then the CAP procedure should fail and we have to subscribe to the attribute to see when it becomes unlocked, so that we retry the original procedure.
I see this as a new DBUS property, for the transport, or for the corresponding Device in "org.bluez.DeviceSet1", that will be kept up to date with the lock status of that particular device.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We would like to add CAP support in BlueZ. Here are some topics:
How should the application set/change the Context Type?
At this moment, the context type is specified via endpoint registration. The CAP specification allows the setting of Streaming Audio Contexts LTV dynamically. This could be a property of the MediaTransport.
Acquiring a transport would require writing the Lock database attribute for all transports in the corresponding set, before the actual procedure.
If the device have the lock set, just send an Acquire reply with failure over DBUS.
All the members of a coordinated set are kept inside "org.bluez.DeviceSet1" Devices list.
This means that the upper layer (i.e. Pipewire) has to take care of the whole ranking part and call "Acquire" for all transports belonging to the same Coordinated Set (in the order of the ranks). In case any of them is failing, then all the transports in the set should be released.
CAP specification says that if a lock is set on any device in the Coordinated Set, then the CAP procedure should fail and we have to subscribe to the attribute to see when it becomes unlocked, so that we retry the original procedure.
I see this as a new DBUS property, for the transport, or for the corresponding Device in "org.bluez.DeviceSet1", that will be kept up to date with the lock status of that particular device.
Beta Was this translation helpful? Give feedback.
All reactions