On Wed, 2011-10-19 at 14:29 +0300, David Henningsson wrote:
> Looks good and does not seem to interfere with anything in the jack
> detection patches. Having a card pointer might even be helpful.
>
> Just a thought: Can profiles be added after pa_card_new? In that case
> they will never get a co
Looks good and does not seem to interfere with anything in the jack
detection patches. Having a card pointer might even be helpful.
Just a thought: Can profiles be added after pa_card_new? In that case
they will never get a correct card pointer.
On 10/18/2011 05:08 PM, Tanu Kaskinen wrote:
T
On Wed, 2011-10-19 at 13:46 +0300, Tanu Kaskinen wrote:
> One possibility would be CARD_PROFILE_ACTIVATING. I think that would
> imply that it's fired prior to the actual activation. That's my vote
> currently :)
I've changed my vote again. Now I vote for CARD_PROVILE_ACTIVATE_START.
I don't perso
On Wed, 2011-10-19 at 13:20 +0300, Colin Guthrie wrote:
> Hi,
>
> As a general comment, I'd rather avoid introducing a new naming
> convension with the "ABOUT_TO_ACTIVATE" suffix.
>
> We already have _POST, _START and _FINISH suffixes on some hooks, so I'd
> suggest either a _PRE suffix to match
Hi,
As a general comment, I'd rather avoid introducing a new naming
convension with the "ABOUT_TO_ACTIVATE" suffix.
We already have _POST, _START and _FINISH suffixes on some hooks, so I'd
suggest either a _PRE suffix to match _POST or perhaps just reusing
_START (tho' _START does seem to imply t
The hook users probably want access to the card object as well,
so a pa_card pointer was added to pa_card_profile.
---
src/pulsecore/card.c | 17 +
src/pulsecore/card.h |6 ++
src/pulsecore/core.h |1 +
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/s
