That one's clear enough from the earlier log snippet and source:
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_connect() Headset Voice gateway connected to FC:58:FA:7F:E5:18
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: disconnected -> connecting (0)
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: connecting -> connected (0)
This ext_connect() seems to be called whenever a profile connection is completed, whether successfully or not, whether locally or remotely initiated. Above, we see the state changes it orchestrated -- it first transitions the HFP "service" to CONNECTING and then to CONNECTED pretty quickly:
if (conn->service && service_set_connecting(conn->service) < 0)
goto drop;
...
if (conn->service)
btd_service_connecting_complete(conn->service,
err ? -err->code : -EIO);
Each of these state changes gets propagated to a bunch of listeners -- one of which is policy.c.
=========================
I think that first transition (to CONNECTING) should not have happened, because it takes away the ability of any listeners to judge whether a connection was locally or remotely initiated, and act accordingly. The HFP service should've simply gone from DISCONNECTED to CONNECTED -- that first IF block should be removed entirely.
=========================
If a connection were indeed locally initiated, the service's state would've been set to CONNECTING way back, by btd_service_connect() probably since it looks to be the one that kicks off the connection. ext_connect() only has enough info to make that final jump to CONNECTED.
That one's clear enough from the earlier log snippet and source:
Aug 29 00:54:47 RhoPC bluetoothd[ 4046739] : src/profile. c:ext_connect( ) Headset Voice gateway connected to FC:58:FA:7F:E5:18 4046739] : src/service. c:change_ state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: disconnected -> connecting (0) 4046739] : src/service. c:change_ state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: connecting -> connected (0)
Aug 29 00:54:47 RhoPC bluetoothd[
Aug 29 00:54:47 RhoPC bluetoothd[
This ext_connect() seems to be called whenever a profile connection is completed, whether successfully or not, whether locally or remotely initiated. Above, we see the state changes it orchestrated -- it first transitions the HFP "service" to CONNECTING and then to CONNECTED pretty quickly:
if (conn->service && service_ set_connecting( conn->service) < 0) connecting_ complete( conn->service,
goto drop;
...
if (conn->service)
btd_service_
err ? -err->code : -EIO);
Each of these state changes gets propagated to a bunch of listeners -- one of which is policy.c.
======= ======= ======= ==== ======= ======= ====
I think that first transition (to CONNECTING) should not have happened, because it takes away the ability of any listeners to judge whether a connection was locally or remotely initiated, and act accordingly. The HFP service should've simply gone from DISCONNECTED to CONNECTED -- that first IF block should be removed entirely.
=======
If a connection were indeed locally initiated, the service's state would've been set to CONNECTING way back, by btd_service_ connect( ) probably since it looks to be the one that kicks off the connection. ext_connect() only has enough info to make that final jump to CONNECTED.