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: <988dc1f9add28a70ba18ce2f3042aac0bea04b5b.camel@hadess.net> <7dc4-63974a80-14d-24592140@246924754>
In-Reply-To: <7dc4-63974a80-14d-24592140@246924754>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Tue, 13 Dec 2022 12:45:24 -0800
Message-ID: <CABBYNZ+qY1H5TFYGAuM4iLRqgBHAaip1F23=GtaajqRqg-d66Q@mail.gmail.com>
Subject: Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus
To:     Arthur Crepin-Leblond <arthur@marmottus.net>
Cc:     Bastien Nocera <hadess@hadess.net>, linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Arthur,

On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond
<arthur@marmottus.net> wrote:
>
> On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@hadess.net> 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 the
> > > 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 properties
> 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.

Can you explain what is the use case here? I hope it is not to
reimplement something like the reconnect policy:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n281


-- 
Luiz Augusto von Dentz