Hi Luiz, * Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2013-06-06 23:06:36 +0700]: > Hi Gustavo, > > On Thu, Jun 6, 2013 at 10:59 PM, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote: > > Hi Luiz, > > > > * Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2013-06-06 22:50:32 +0700]: > > > >> Hi Gustavo, > >> > >> On Thu, Jun 6, 2013 at 9:18 PM, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote: > >> > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > >> > > >> > With those two methods BlueZ is now aware of client lifetime and can set > >> > Discoverable back to False if all clients exit or call > >> > ReleaseDiscoverable() > >> > --- > >> > >> This probably should be handled int the component controlling the > >> powered state like we used to have with RequestSession or we can have > >> an agent to the power/policy manager asking if it is ok to power on > >> the adapter. > > > > Not sure if it makes sense to put this in the component that handles power > > state (you mean ConnMan here, for example?). How an agent for this can help > > us. The problem I'm trying to solve here is, do not let the Discoverable True > > for infinite time if the who is using crashes. > > There is the exact same problem with Powered isn't it? If the > application crashes will stay on, actually with an agent we can always > request the component controlling it e.g. ConnMan to confirm the > action. Yes, Powered has the same problem, but didn't ConnMan itself would need to register "Powered session" on BlueZ as well. The I see it BlueZ is the session manager, not ConnMan. In your mind ConnMan would also control things like Discoverable or Pairable? Gustavo -- 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
