Hi Arik, > >> This command reads the Tx power level for a given connected device > >> --- > >> doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++ > >> 1 files changed, 28 insertions(+), 0 deletions(-) > >> > >> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > >> index 4ede43d..8dae2b4 100644 > >> --- a/doc/mgmt-api.txt > >> +++ b/doc/mgmt-api.txt > >> @@ -815,6 +815,34 @@ Unblock Device Command > >> or failure. > >> > >> > >> +Read Tx Power Level Command > >> +====================== > >> + > >> + Command Code: 0x0028 > > > > how is this suppose to work. This command and Set Device ID are suppose > > to have the same command code? > > Ah you're right I missed that. I'll put 0x29 then. > > > > >> + Controller Index: <controller id> > >> + Command Parameters: Address (6 Octets) > >> + Address_Type (1 Octet) > >> + Type (1 Octet) > >> + Return Parameters: Address (6 Octets) > >> + Address_Type (1 Octet) > >> + Status (1 Octet) > >> + Level (1 Octet) > >> + > >> + Possible values for the Address_Type parameter: > >> + 0 BR/EDR > >> + 1 LE Public > >> + 2 LE Random > >> + > >> + Possible values for the Type parameter: > >> + 0 Current Transmit Power Level > >> + 1 Maximum Transmit Power Level > > > > Which ones do you care about? And why not just read both and return both > > at the same time. > > > > I think that I made this pretty clear multiple times already. The mgmt > > API is not for stuffing random HCI commands into it. Please explain your > > usage pattern of the results clearly. > > > > Who is triggering this command and who is consuming the results? > > Well the proximity reporter and proximity monitor profiles are the > ones using this (with LE connections only). The proximity monitor can > query the reporter for the Tx power level. The spec claims there's no > point in polling for this, as the value doesn't change during an LE > connection. so why are we not just reading that value when creating a LE connection? What is the penalty for doing it on every LE connection? > Both profiles only care about the current Tx power level. I added the > type for flexibility. It can be removed of course. > > In the proposed implementation the reporter reads this value when a > device connects and caches it. When a remote device asks for this > value (via an ATT read as part of the TPS profile), we return the > cached value. So it gets always read anyway. Regards Marcel -- 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
