On Tuesday, December 13, 2022 21:45 CET, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Arthur, > > On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond > <arthur@xxxxxxxxxxxxx> wrote: > > > > On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@xxxxxxxxxx> 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
