Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

["Arthur Crepin-Leblond" <arthur@marmottus.net>]

On Tuesday, December 13, 2022 21:45 CET, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> 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

 Hi Luiz,

No, nothing to do with the reconnect policy.
My device (a Raspberry Pi) is acting as a central and is losing randomly
the connection with a device.
So, the use case is purely to be able to have information about the
disconnection.

--
Arthur Crepin-Leblond