It can be useful for routing modules to know a profile's input
and output parts, in order to e g change output profile
while keeping the input profile unchanged.
For now filling in these fields is optional and a routing module
must be able to handle NULL in these fields.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
When given an explicit device.description in card_properties, prefer
this information over other default prefixes (e.g. 'Built-in Audio')
when constructing sink/source descriptions.
For example, if I manually configure the card description to be
"FooBar", I then expect that the sinks and created by the card also
have "FooBar" in their description instead of generic "Built-in
Audio".
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
f434087e42 introduced the potential to not select a card profile if
all the profiles were marked as unavailable.
While this is very unlikely, it's a theoretical posibility, so if the
initial choice of a profile fails, try harder.
When a card is being created and no profile has been assigned
pa_card_new will attempt to select one from the list but it does that
without checking the available flag which can lead to select profiles
not available.
Since the hashmap stores a pointer to the key provided at pa_hashmap_put()
time, it make sense to allow the hashmap to be given ownership of the key and
have it free it at pa_hashmap_remove/free time.
To do this cleanly, we now provide the key and value free functions at hashmap
creation time with a pa_hashmap_new_full. With this, we do away with the free
function that was provided at remove/free time for freeing the value.
This reverts commit a9c3f2fb0f.
It has been recently agreed that ports should somehow have some physical
meaning, leading to the port merge in module-bluetooth-device.
With this assumption in mind, it is very unlikely that a card would
add or remove ports dynamically. Therefore, the core can be simplified
by removing the support for this.
The revert affects the code added to module-card-restore in commit
a1a0ad1af2, which can now be partially
removed.
Conflicts:
src/pulsecore/card.c
src/pulsecore/core.h
Some cards are capable to announce if a specific profile is available or
not, effectively predicting whether a profile switch would fail or would
likely succeed. This can for example be useful for a UI that would gray
out any unavailable profile.
In addition, this information can be useful for internal modules
implementing automatic profile-switching policies, such as
module-switch-on-port-available or module-bluetooth-policy.
In particular, this information is essential when a port is associated
to multiple card profiles and therefore the port availability flag does
not provide enough information. The port "bluetooth-output" falls into
this category, for example, since it doesn't distinguish HSP/HFP from
A2DP.
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
In practice there is always at least one profile, and I
don't think there will ever be cards without profiles.
Therefore, I added assertions to pa_card_new() stating that
the card new data must always contain at least one profile.
Now a lot of code can be simplified, because it's guaranteed
that the profiles hashmap and the active_profile field are
always non-NULL.
In my opinion, pa_card_set_profile() should assert that name
is not NULL, and it would be the job of the client interface
to filter out NULLs from the client input, but this is done
this way also when setting sink and source ports, so for
consistency I'll do this this way for now.
This forms the base for being able to expose all ports of all
profiles (even inactive ones) to clients.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This will allow modules to know when a card profile has changed
and take appropriate action. This might prove useful when developing
UCM so that the appropriate verb can be set.
