| Message ID | 20221212133235.79657-1-arthur@marmottus.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Expose the disconnect reason over D-Bus | expand |
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?
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.
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
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.