Re: [RFC 7/7] Update Management API documentation

Hi Anderson,

quoted

so why are these two separate commands. Just reading them in one kernel
call might be a lot better. Including everything else you need to know
about the connection. Also TX power can be local and remote TX power if
I remember this correctly.

The issue I see with your proposal is that for Proximity (currently
the only user of this information) we read TX power from server
(reporter) using GATT, while RSSI is read on client (monitor) side. By
reading both, we would need to issue two separate HCI commands (and
wait for both responses), but will always use only one value,
depending on local BlueZ role.

Also note that on latest Proximity profile drafts, it is mentioned
that the TX power on reporter will never change during a connection,
and thus it should be read only once when the connection is
established. RSSI (which is read "locally" on monitor side), on the
other hand, should be read periodically for path loss calculation.

if TX power is only read once than the kernel should just do it once and
be done with it.

And for RSSI, it would be better if the kernel read this periodically
based on current sniff mode etc. Userspace can not trigger this with
proper timing anyway. And it will potentially at some point start
blocking the controller. Only the kernel really knows when it is
acceptable to read the RSSI value.

Regards

Marcel