Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAO271mmuMDoqNdXUUuPpyz3VyuLWrZUr1K=Jry+H9mGEtz-Z4Q@mail.gmail.com>
In-Reply-To: <CAO271mmuMDoqNdXUUuPpyz3VyuLWrZUr1K=Jry+H9mGEtz-Z4Q@mail.gmail.com>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Thu, 10 Feb 2022 10:40:12 -0800
Message-ID: <CAO271m=vQsGwRvpe2tUUMuqB7r2z2cAut27U1LY6bQ_sHAk3NA@mail.gmail.com>
Subject: Re: Question about Trusted property
To:     BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Dear maintainers,

Friendly ping on this question. Does adding "Bonded" property to
org.bluez.Device1 make sense?

On Fri, Feb 4, 2022 at 4:02 PM Sonny Sasaka <sonnysasaka@chromium.org> wrote:
>
> Hi Luiz/BlueZ maintainers,
>
> What is the purpose of the Trusted property on org.bluez.Device1
> interface? Does it mean whether the device is bonded? My experiment
> with BlueZ shows that sometimes a device with "Trusted" property set
> is not bonded (does not have pairing key stored) and also vice versa,
> so I am assuming that the Trusted property means something else. What
> is an example use case of the Trusted property?
>
> Eventually, what I am trying to achieve is for BlueZ clients to find
> out whether a device is Bonded or not. Using the Paired property is
> not very accurate because it is set to true during connection although
> the device is not bonded (pairing key does not persist after
> disconnection). For this purpose, I am about to propose adding
> "Bonded" property to org.bluez.Device1. Some use cases include when
> there is a temporary pairing with a peer device we don't want UI to
> show that the device is in the Bonded device list. What do you think
> about exposing the Bonded state via D-Bus? I will do the
> implementation if this idea makes sense.
>
> Thanks!