[pulseaudio-discuss] [PATCH] core: New hook: PA_CORE_HOOK_CARD_PROFILE_ABOUT_TO_ACTIVATE.

[Tanu Kaskinen]

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 _POST or perhaps just reusing
> _START (tho' _START does seem to imply there will be a corresponding
> _FINISH so maybe _PRE is better?)
> 
> Or maybe we should just rename PA_CORE_HOOK_CARD_PROFILE_CHANGED to
> PA_CORE_HOOK_CARD_PROFILE_CHANGE_FINISH and then call the new one
> _START? Opinions welcome here.
> 
> Other than that, provided this doesn't conflict in any major way with
> anything David's been doing, this seems fine.

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'd like to keep profile change and profile activation as separate
concepts - I think profile change is an operation done on the card,
while profile activation is an operation done on the card profile. With
the current code there is no practical distinction, however, because the
profile changing is not divided to separate phases for deactivation of
the old profile and activation of the new profile. From that point of
view it would be sufficient and fine to have eg.
CARD_PROFILE_CHANGE_START and CARD_PROFILE_CHANGE_FINISH. But in the
long term I hope the profile change process will be divided to separate
deactivation and activation phases, so that the card will enter an
intermediate state for the duration of the profile change. By
"intermediate state" I mean a state that will be visible also to the
clients etc. That intermediate state is needed, because the profile
change may require waiting for some external component, and it would be
good if the execution could return to the event loop for the duration of
that wait. The module that I'm working on will have to wait for a reply
from bluetoothd before the profile activation can continue, so the main
thread will be blocked while waiting for a reply. This is currently
unavoidable with the "atomic" profile changing logic. This is not a new
problem - I believe there is similar stuff (synchronous D-Bus calls)
happening in the bluetooth modules already now (I don't know or remember
the details, but I have had some discussion about this with Luiz).

-- 
Tanu