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;
From:   "Arthur Crepin-Leblond" <arthur@marmottus.net>
In-Reply-To: <988dc1f9add28a70ba18ce2f3042aac0bea04b5b.camel@hadess.net>
Content-Type: text/plain; charset="utf-8"
Date:   Mon, 12 Dec 2022 16:36:42 +0100
Cc:     linux-bluetooth@vger.kernel.org
To:     "Bastien Nocera" <hadess@hadess.net>
MIME-Version: 1.0
Message-ID: <7dc4-63974a80-14d-24592140@246924754>
Subject: =?utf-8?q?Re=3A?= [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus
User-Agent: SOGoMail 5.5.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@hadess.n=
et> wrote: 
 
> On Mon, 2022-12-12 at 14:32 +0100, Arthur Crepin-Leblond wrote:
> > Hello,
> > 
> > I am trying to expose the device disconnect reason over D-Bus and t=
he
> > most elegant way I found was to subscribe to the adapter notify
> > callback that gives the reason as an argument.
> 
> Any reason why this can't be a signal with the reason as an argument?=


I chose the easy path by copying the existing code for the device prope=
rties
that get updated like the "Connected" or "ServicesResolved". 
I am not too familiar with BlueZ signals other than PropertiesChanged, =

InterfacesRemoved/Added. What would you have in mind?

And apologies in advance, it's my first time submitting here, I do not =
have
an advanced knowledge of the BlueZ internals.