Hi Abhishek, >>> Add docs for new management operation to mark a device as wake capable. >>> >>> --- >>> >>> Changes in v3: None >>> Changes in v2: >>> * Separated docs/mgmt-api.txt into its own patch >>> >>> doc/mgmt-api.txt | 19 +++++++++++++++++++ >>> 1 file changed, 19 insertions(+) >>> >>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt >>> index 1e59acc54..8a73a9bb9 100644 >>> --- a/doc/mgmt-api.txt >>> +++ b/doc/mgmt-api.txt >>> @@ -3047,6 +3047,25 @@ Load Blocked Keys Command >>> Possible errors: Invalid Parameters >>> Invalid Index >>> >>> +Set Wake Capable Command >>> +=========================== >>> + >>> + Command Code: 0x0047 >>> + Controller Index: <controller id> >>> + Command Parameters: Address (6 Octets) >>> + Address_Type (1 Octet) >>> + Wake Capable (1 Octet) >>> + Return Parameters: Address (6 Octets) >>> + Address_Type (1 Octet) >>> + Wake Capable (1 Octet) >>> + >>> + This command sets whether a bluetooth device is capable of waking the >>> + system from suspend. This property is used to set the event filter and >>> + LE whitelist when the system enters suspend. >>> + >>> + Possible errors: Failed >>> + Invalid Parameters >>> + Invalid Index >>> >> >> my current thinking goes into this API addition: >> >> --- a/doc/mgmt-api.txt >> +++ b/doc/mgmt-api.txt >> @@ -2003,6 +2003,7 @@ Add Device Command >> 0 Background scan for device >> 1 Allow incoming connection >> 2 Auto-connect remote device >> + 3 Allow incoming connection to wake up the system >> >> With the Action 0, when the device is found, a new Device Found >> event will be sent indicating this device is available. This >> @@ -2018,6 +2019,9 @@ Add Device Command >> and if successful a Device Connected event will be sent. This >> action is only valid for LE Public and LE Random address types. >> >> + With the Action 3, the device is allowed to connect the same way >> + as with Action 1, but allows to wake up the system from suspend. >> + >> When a device is blocked using Block Device command, then it is >> valid to add the device here, but all actions will be ignored >> until the device is unblocked. >> >> Since we are really talking about incoming connections, then the Add Device command is the one that handles this. Giving a device the option to wake us up that is not set up for incoming connections makes no sense. We can discuss if certain LE advertising packets should wake us up, but that is a total different API in my book. > > I originally tried implementing this with the Add Device api as you > suggested in the RFC email back in November (when we first talked > about this). I had trouble figuring out when/where in bluez to > actually send the Add Device command. > > Whether a device supports wake-up is a profile level setting (i.e. HID > only so far). As far as I can tell, Add Device is called before the > profile connection is established. Bluez has two apis that call > MGMT_OP_ADD_DEVICE: > * adapter_auto_connect_add (this seems to be LE) > * adapter_whitelist_add (this seems to be BR/EDR) > > Both seem to be called BEFORE the registered profiles have a chance to > accept the connection. this is something for Luiz or Johan to comment on. Maybe our code is not as good as I was thinking in this regard. Or maybe this is actually legacy code that I am trying to rid of by requiring a mgmt API revision that has Add Device support. In general once we bonded with a device, we should be able to assign certain properties to it that are kept persistently. Regards Marcel
