On Thu, Mar 8, 2012 at 6:09 PM, Mike <puffy.taco@xxxxxxxxx> wrote: > In order to act like a better headset in the HFP HF role, I am in need > of the reason code from the disconnection event. This is so that I > can detect when a disconnect occurs as a result of the units moving > out of range of each other, rather than an intentional disconnect. In > the event of a disconnection based on connection loss, I can then > periodically re-attempt the connection. I have not seen any D-Bus > messages that would indicate such an event. > > Any ideas on how to obtain this? I can see that in the hciops version > of bluez, the reason code makes it into bluetoothd just because the > entire disconnect event is transferred. This is not the case in the > mgmtops version. It looks like the reason code also hops along the > L2CAP path, but I haven't yet tracked down where it ends up. I think > ideally it would end up somewhere that Ofono would be able to obtain > it. > > Thanks, > Mike Alright, looks like the value shows up if I query SO_ERROR in Ofono when I get POLLERR/POLLHUP in the RFCOMM socket's poll routine. That leaves it as an Ofono implementation task then; the bluez side is good to go. I'll keep playing with it. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
