[PATCH BlueZ 0/1] Adapter1.ConnectDevice

[PATCH BlueZ 0/1] Adapter1.ConnectDevice

[Simon Mikuda]

I added some minor addition to documentation and also I tested calling
function via DBus in parallel to same device.

In both case of BR/EDR both DBus calls will be pending and they will
finish at same time when Page Timeout arrives or connection. I think
this can be considered as correct behaviour.

In case of LE first one will be pending and second one will get
"org.bluez.Error.Failed: Connect failed" immediately. Later first
one will timeout.

Simon Mikuda (1):
  adapter: Be able to use ConnectDevice for discovered devices

 doc/adapter-api.txt | 2 +-
 src/adapter.c       | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

-- 
2.34.1

[PATCH BlueZ 1/1] adapter: Be able to use ConnectDevice for discovered devices

[Simon Mikuda]

This can be useful when you want to specify trasport type for already
paired device (e.g. use LE transport for dual mode device).
---
 doc/adapter-api.txt | 2 +-
 src/adapter.c       | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 9b2721c1b..239d9463d 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -182,7 +182,7 @@ Methods		void StartDiscovery()
 			profile will be connected. There is no need for calling
 			Connect on Device1 after this call. If connection was
 			successful this method returns object path to created
-			device object.
+			device object or device that already exist.
 
 			Parameters that may be set in the filter dictionary
 			include the following:
diff --git a/src/adapter.c b/src/adapter.c
index 2679d4302..17f4a637d 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3763,9 +3763,6 @@ static DBusMessage *connect_device(DBusConnection *conn,
 	if (!bacmp(&addr, BDADDR_ANY))
 		return btd_error_invalid_args(msg);
 
-	if (btd_adapter_find_device(adapter, &addr, addr_type))
-		return btd_error_already_exists(msg);
-
 	device_connect(adapter, &addr, addr_type, msg);
 	return NULL;
 }
-- 
2.34.1

RE: Adapter1.ConnectDevice

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=770400

---Test result---

Test Summary:
CheckPatch                    PASS      0.38 seconds
GitLint                       PASS      0.29 seconds
BuildEll                      PASS      27.01 seconds
BluezMake                     PASS      793.15 seconds
MakeCheck                     PASS      12.10 seconds
MakeDistcheck                 PASS      159.63 seconds
CheckValgrind                 PASS      252.47 seconds
CheckSmatch                   PASS      338.10 seconds
bluezmakeextell               PASS      102.34 seconds
IncrementalBuild              PASS      657.82 seconds
ScanBuild                     PASS      1022.18 seconds



---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ 1/1] adapter: Be able to use ConnectDevice for discovered devices

[Luiz Augusto von Dentz]

Hi Simon,

On Thu, Jul 27, 2023 at 10:46 PM Simon Mikuda
<simon.mikuda@streamunlimited.com> wrote:
>
> This can be useful when you want to specify trasport type for already
> paired device (e.g. use LE transport for dual mode device).
> ---
>  doc/adapter-api.txt | 2 +-
>  src/adapter.c       | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
> index 9b2721c1b..239d9463d 100644
> --- a/doc/adapter-api.txt
> +++ b/doc/adapter-api.txt
> @@ -182,7 +182,7 @@ Methods             void StartDiscovery()
>                         profile will be connected. There is no need for calling
>                         Connect on Device1 after this call. If connection was
>                         successful this method returns object path to created
> -                       device object.
> +                       device object or device that already exist.

Perhaps we should mention the intent here is to allow applications to
specify what bearer to connect as opposed to Device.Connect that
connects on the last seen bearer first.

>
>                         Parameters that may be set in the filter dictionary
>                         include the following:
> diff --git a/src/adapter.c b/src/adapter.c
> index 2679d4302..17f4a637d 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -3763,9 +3763,6 @@ static DBusMessage *connect_device(DBusConnection *conn,
>         if (!bacmp(&addr, BDADDR_ANY))
>                 return btd_error_invalid_args(msg);
>
> -       if (btd_adapter_find_device(adapter, &addr, addr_type))
> -               return btd_error_already_exists(msg);
> -
>         device_connect(adapter, &addr, addr_type, msg);
>         return NULL;
>  }
> --
> 2.34.1
>


-- 
Luiz Augusto von Dentz

[PATCH BlueZ 1/2] adapter: Be able to use ConnectDevice for discovered devices

[Simon Mikuda]

This can be useful when you want to specify trasport type for already
paired device (e.g. use LE transport for dual mode device).
---
 src/adapter.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/adapter.c b/src/adapter.c
index 2679d4302..17f4a637d 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3763,9 +3763,6 @@ static DBusMessage *connect_device(DBusConnection *conn,
 	if (!bacmp(&addr, BDADDR_ANY))
 		return btd_error_invalid_args(msg);
 
-	if (btd_adapter_find_device(adapter, &addr, addr_type))
-		return btd_error_already_exists(msg);
-
 	device_connect(adapter, &addr, addr_type, msg);
 	return NULL;
 }
-- 
2.34.1

[PATCH BlueZ 2/2] adapter: Update ConnectDevice documentation

[Simon Mikuda]

---
 doc/adapter-api.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 9b2721c1b..d38ce7171 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -177,12 +177,13 @@ Methods		void StartDiscovery()
 			performing General Discovery. Connection mechanism is
 			similar to Connect method from Device1 interface with
 			exception that this method returns success when physical
-			connection is established. After this method returns,
+			connection is established and you can specify bearer to
+			connect with parameter. After this method returns,
 			services discovery will continue and any supported
 			profile will be connected. There is no need for calling
 			Connect on Device1 after this call. If connection was
 			successful this method returns object path to created
-			device object.
+			device object or device that already exist.
 
 			Parameters that may be set in the filter dictionary
 			include the following:
-- 
2.34.1

Re: [PATCH BlueZ 1/2] adapter: Be able to use ConnectDevice for discovered devices

[Paul Menzel]

[Cc: +Szymon]

Dear Simon,


Thank you for your patch. In the commit summary, an alternative to “Be 
able” could be “Allow”.

Am 31.07.23 um 06:12 schrieb Simon Mikuda:
> This can be useful when you want to specify trasport type for already

tra*n*sport

> paired device (e.g. use LE transport for dual mode device).

Could you please elaborate a little more? Maybe even give an example, 
how this can be tested?

> ---
>   src/adapter.c | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/src/adapter.c b/src/adapter.c
> index 2679d4302..17f4a637d 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -3763,9 +3763,6 @@ static DBusMessage *connect_device(DBusConnection *conn,
>   	if (!bacmp(&addr, BDADDR_ANY))
>   		return btd_error_invalid_args(msg);
>   
> -	if (btd_adapter_find_device(adapter, &addr, addr_type))
> -		return btd_error_already_exists(msg);
> -
>   	device_connect(adapter, &addr, addr_type, msg);
>   	return NULL;
>   }

Re: [PATCH BlueZ 1/2] adapter: Be able to use ConnectDevice for discovered devices

[Simon Mikuda]

Hi Paul.

Should I submit new patch with fixed commit message text?

For the testing part:

Precondition: have the linux BT adapter (DUT) ready and some remote 
device you want to connect to

Steps:

- make remote device discoverable
- scan for devices on DUT: bluetoothctl --> scan on
- wait until the remote device pops out on dbus interface
- connect to the remote device using Adapter1.ConnectDevice

To do this you can use these commands:

LE: gdbus call --system --dest org.bluez --object-path /org/bluez/hci0 
--method org.bluez.Adapter1.ConnectDevice "{'Address': 
<'00:00:00:00:00:00'>, 'AddressType': <'public'>}"
BR/EDR: gdbus call --system --dest org.bluez --object-path 
/org/bluez/hci0 --method org.bluez.Adapter1.ConnectDevice "{'Address': 
<'00:00:00:00:00:00'>}"

For example if remote device emits LE advertisements with general 
discoverable flag set and the flag "BR/EDR not supported" is NOT set 
calling reqeuset Device1.Connect would result connecting on BR/EDR 
transport bearer.

BR,

Simon

On 31. 7. 2023 7:43, Paul Menzel wrote:
> [Cc: +Szymon]
>
> Dear Simon,
>
>
> Thank you for your patch. In the commit summary, an alternative to “Be 
> able” could be “Allow”.
>
> Am 31.07.23 um 06:12 schrieb Simon Mikuda:
>> This can be useful when you want to specify trasport type for already
>
> tra*n*sport
>
>> paired device (e.g. use LE transport for dual mode device).
>
> Could you please elaborate a little more? Maybe even give an example, 
> how this can be tested?
>
>> ---
>>   src/adapter.c | 3 ---
>>   1 file changed, 3 deletions(-)
>>
>> diff --git a/src/adapter.c b/src/adapter.c
>> index 2679d4302..17f4a637d 100644
>> --- a/src/adapter.c
>> +++ b/src/adapter.c
>> @@ -3763,9 +3763,6 @@ static DBusMessage 
>> *connect_device(DBusConnection *conn,
>>       if (!bacmp(&addr, BDADDR_ANY))
>>           return btd_error_invalid_args(msg);
>>   -    if (btd_adapter_find_device(adapter, &addr, addr_type))
>> -        return btd_error_already_exists(msg);
>> -
>>       device_connect(adapter, &addr, addr_type, msg);
>>       return NULL;
>>   }

RE: [BlueZ,1/2] adapter: Be able to use ConnectDevice for discovered devices

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=771001

---Test result---

Test Summary:
CheckPatch                    PASS      0.82 seconds
GitLint                       PASS      0.57 seconds
BuildEll                      PASS      28.69 seconds
BluezMake                     PASS      1057.60 seconds
MakeCheck                     PASS      11.91 seconds
MakeDistcheck                 PASS      164.87 seconds
CheckValgrind                 PASS      267.45 seconds
CheckSmatch                   PASS      397.75 seconds
bluezmakeextell               PASS      118.45 seconds
IncrementalBuild              PASS      1912.31 seconds
ScanBuild                     PASS      1276.43 seconds



---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ 1/2] adapter: Be able to use ConnectDevice for discovered devices

[patchwork-bot+bluetooth]

Hello:

This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon, 31 Jul 2023 06:12:28 +0200 you wrote:
> This can be useful when you want to specify trasport type for already
> paired device (e.g. use LE transport for dual mode device).
> ---
>  src/adapter.c | 3 ---
>  1 file changed, 3 deletions(-)

Here is the summary with links:
  - [BlueZ,1/2] adapter: Be able to use ConnectDevice for discovered devices
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=caf7db313e9d
  - [BlueZ,2/2] adapter: Update ConnectDevice documentation
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=255ef572ca76

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH BlueZ 0/1] Adapter1.ConnectDevice

[Luiz Augusto von Dentz]

Hi Simon,

On Thu, Jul 27, 2023 at 11:00 PM Simon Mikuda
<simon.mikuda@streamunlimited.com> wrote:
>
> I added some minor addition to documentation and also I tested calling
> function via DBus in parallel to same device.
>
> In both case of BR/EDR both DBus calls will be pending and they will
> finish at same time when Page Timeout arrives or connection. I think
> this can be considered as correct behaviour.
>
> In case of LE first one will be pending and second one will get
> "org.bluez.Error.Failed: Connect failed" immediately. Later first
> one will timeout.
>
> Simon Mikuda (1):
>   adapter: Be able to use ConnectDevice for discovered devices
>
>  doc/adapter-api.txt | 2 +-
>  src/adapter.c       | 3 ---

Please split the documentation changes from the code changes.

>  2 files changed, 1 insertion(+), 4 deletions(-)
>
> --
> 2.34.1
>


-- 
Luiz Augusto von Dentz