Re: [PATCH BlueZ 1/1] Refactor btd_device_is_connected

[Dimitris <dimitris.on.linux@gmail.com>]

Hi Luiz,

On 4/4/24 09:16, Luiz Augusto von Dentz wrote:

>>> I guess the problem is that some service is indicating it is still
>>> connected though?
>>
>> Newbie question for sure, but: As this is happening in the code path for
>> "disabling bluetooth", shouldn't services already be disconnected here?
> 
> That is exactly what I would like to know, why is there a service
> still indicating it is connected if the controller is rfkilled, so
> while this should break it back to the old behavior we still need to
> fix the service that is causing the problem so perhaps we need to
> print its profile/drive name and figure out what is the driver that is
> causing it.
> 

I added a debug kludge:


> diff --git a/src/device.c b/src/device.c
> index 74dd67a09..c461a6a3a 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -344,7 +344,15 @@ static GSList *find_service_with_state(GSList *list,
>                 struct btd_service *service = l->data;
>  
>                 if (btd_service_get_state(service) == state)
> +               {
> +                       char name[256];
> +                       device_get_name(btd_service_get_device(service), name, 256);
> +                       info("Found service: err: %d, device: %s",
> +                               btd_service_get_error(service),
> +                               name
> +                       );
>                         return l;
> +               }
>         }
>  
>         return NULL;
> @@ -3282,7 +3290,12 @@ bool btd_device_is_connected(struct btd_device *dev)
>  
>  bool btd_device_bearer_is_connected(struct btd_device *dev)
>  {
> -       return dev->bredr_state.connected || dev->le_state.connected;
> +       if(dev->bredr_state.connected || dev->le_state.connected)
> +               return true;
> +       else {
> +               find_service_with_state(dev->services, BTD_SERVICE_STATE_CONNECTED);
> +               return false;
> +       };
>  }
>  
>  static void clear_temporary_timer(struct btd_device *dev)

And it seems that every device I have available triggers this:  MX 
Master 3 mouse, Google Pixel Buds Pro, Google Pixel 7.  Ran experiments 
with each one of the devices being connected when running rfkill block:

> Apr 04 11:06:31 bluetoothd[331222]: Found service: err: 0, device: MX Master 3
> Apr 04 11:06:46 bluetoothd[331222]: Found service: err: 0, device: MX Master 3
> Apr 04 11:06:58 bluetoothd[331222]: Found service: err: 0, device: MX Master 3
> Apr 04 11:07:28 bluetoothd[331222]: Found service: err: 0, device: coral buds
> Apr 04 11:07:29 bluetoothd[331222]: Found service: err: 0, device: coral buds
> Apr 04 11:07:29 bluetoothd[331222]: Found service: err: 0, device: coral buds
> Apr 04 11:07:29 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
> Apr 04 11:08:01 bluetoothd[331222]: Found service: err: 0, device: coral buds
> Apr 04 11:08:01 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
> Apr 04 11:08:40 bluetoothd[331222]: Found service: err: 0, device: coral buds
> Apr 04 11:08:40 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
> Apr 04 11:09:47 bluetoothd[331222]: Found service: err: 0, device: p7
> Apr 04 11:09:47 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free unit: getpeername: Transport endpoint is not connected (107)

The BT adapter is a Mediatek MT7922 WiFi/BT M2 adapter, seems to be 
using the btmtk driver.

In parallel, I've sent a V3 of the "bring back previous behavior" patch 
with the new function named btd_device_bearer_is_connected.

D.