From: Marcel Holtmann <marcel@holtmann.org>
To: Manish Mandlik <mmandlik@google.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth <linux-bluetooth@vger.kernel.org>,
CrosBT Upstreaming <chromeos-bluetooth-upstreaming@chromium.org>,
Miao-chen Chou <mcchou@google.com>,
Yun-Hao Chung <howardchung@google.com>,
Alain Michaud <alainmichaud@google.com>
Subject: Re: [BlueZ PATCH v1 1/3] doc: Add Advertisement Monitor Device Tracking event
Date: Wed, 29 Sep 2021 15:26:32 +0200 [thread overview]
Message-ID: <C5279A3F-990B-4554-9236-CBE60E4E1181@holtmann.org> (raw)
In-Reply-To: <CAGPPCLB9j4Bgb=rraxdOBK+iACVO7+jJAHsPRn7B4JpTr3v-cQ@mail.gmail.com>
Hi Manish,
can we please stop top-posting and follow the general rules of this mailing list.
> The controller sends advertising reports in addition to this event. This event is reported only when there are active and matched advertisement monitors.
>
> Whenever an advertisement matches a Monitor, the controller sends this event with Monitor_state set to 1, indicating that it has started monitoring that particular device. After that it may send one or more advertising reports based on the configured Sampling_period for that Monitor. Once the controller stops monitoring that device, it sends the same event again with Monitor_state set to 0 to notify the host that it has stopped monitoring that particular device.
>
> Since this event is sent only twice (at start and end of monitoring) per monitoring period [1], combining this with the Sampling_period - 0xFF (send only one advertisement report per monitoring period) [2], we can drastically reduce the number of events generated by the controller during background scanning but still have the DeviceFound/DeviceLost functionality in bluetoothd.
>
> So, it will be better to keep this event separate than the Device Found event as it is triggered only during monitoring. Please let me know what you think about this.
> [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_device_event
> [2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_advertisement
This is what I was thinking:
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 97d33e30a15d..fa9121c3bc87 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -4263,6 +4263,7 @@ Device Found Event
1 Legacy Pairing
2 Not Connectable
3 Reserved (not in use)
+ 4 Device Tracked
For the RSSI field a value of 127 indicates that the RSSI is
not available. That can happen with Bluetooth 1.1 and earlier
@@ -4910,3 +4911,19 @@ Controller Resume Event
Address_Type. Otherwise, Address and Address_Type will both be zero.
This event will be sent to all management sockets.
+
+Device Lost Event
+=================
+
+ Event Code: 0x002f
+ Controller Index: <controller id>
+ Event Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This event indicates that a tracked device was no longer found
+ during monitoring.
+
+ Possible values for the Address_Type parameter:
+ 0 BR/EDR
+ 1 LE Public
+ 2 LE Random
I really don’t get why we would make it more complicated for mgmt-api and thus bluetoothd.
Regards
Marcel
next prev parent reply other threads:[~2021-09-29 13:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 20:16 [BlueZ PATCH v1 0/3] Introduce Advertisement Monitor Device Tracking event Manish Mandlik
2021-09-27 20:16 ` [BlueZ PATCH v1 1/3] doc: Add " Manish Mandlik
2021-09-27 20:23 ` Luiz Augusto von Dentz
2021-09-27 20:38 ` Introduce " bluez.test.bot
2021-09-28 8:09 ` [BlueZ PATCH v1 1/3] doc: Add " Marcel Holtmann
[not found] ` <CAGPPCLB9j4Bgb=rraxdOBK+iACVO7+jJAHsPRn7B4JpTr3v-cQ@mail.gmail.com>
2021-09-29 13:26 ` Marcel Holtmann [this message]
2021-09-27 20:16 ` [BlueZ PATCH v1 2/3] lib: Add definition of AdvMonitor " Manish Mandlik
2021-09-27 20:16 ` [BlueZ PATCH v1 3/3] adv_monitor: Receive Device " Manish Mandlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C5279A3F-990B-4554-9236-CBE60E4E1181@holtmann.org \
--to=marcel@holtmann.org \
--cc=alainmichaud@google.com \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=howardchung@google.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=mcchou@google.com \
--cc=mmandlik@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).