From: "github-actions[bot]" <noreply@github.com>
To: linux-bluetooth@vger.kernel.org
Subject: [bluez/bluez] e5cd97: adapter: restrict delta=0 RSSI to proximity filters
Date: Wed, 15 Jul 2026 02:31:25 -0700 [thread overview]
Message-ID: <bluez/bluez/push/refs/heads/1128034/000000-e5cd97@github.com> (raw)
Branch: refs/heads/1128034
Home: https://github.com/bluez/bluez
Commit: e5cd975f28413ecac5c4fb4702c24149525007d6
https://github.com/bluez/bluez/commit/e5cd975f28413ecac5c4fb4702c24149525007d6
Author: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
Date: 2026-07-15 (Wed, 15 Jul 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: restrict delta=0 RSSI to proximity filters
When a discovery filter is active (filtered_discovery=true), BlueZ
unconditionally calls device_set_rssi_with_delta(..., delta=0),
causing every BLE advertisement to emit a PropertiesChanged(RSSI)
signal regardless of whether the RSSI value changed.
delta=0 is only needed when a client has expressed explicit proximity
interest by setting an RSSI or pathloss threshold in its discovery
filter. Filters that specify only transport type or UUIDs do not
require per-packet RSSI precision; for those, the standard
RSSI_THRESHOLD=8 rate-limiting is both correct and desirable.
The problem is triggered on dual-mode adapters by a transport-only
filter (e.g. Transport=le). In merge_discovery_filters(), the
transport-specific scan type (SCAN_TYPE_LE=6) does not equal the
adapter scan type (SCAN_TYPE_DUAL=7), so has_filtered_discovery is
set, filtered_discovery becomes true, and delta=0 is applied even
though no proximity condition was requested. With hundreds of BLE
devices advertising simultaneously this generates hundreds of
unnecessary PropertiesChanged(RSSI) signals per second.
Confirmed on QCS6490 (BlueZ 5.72) with Transport=le filter:
adapter.c: filtered_discovery=1 (current_discovery_filter=set)
device.c: device_set_rssi_with_delta() rssi=-86 delta_threshold=0
device.c: device_set_rssi_with_delta() rssi=-79 delta_threshold=0
Add discovery_filter_has_proximity() which walks discovery_list and
returns true only when at least one active filter carries a real
proximity condition (rssi != DISTANCE_VAL_INVALID or pathloss !=
DISTANCE_VAL_INVALID). Use this to gate the delta=0 path.
Other filter fields (transport, uuids, duplicate, discoverable)
express capability or content criteria and carry no proximity
implication, so they are intentionally excluded from the check.
Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
reply other threads:[~2026-07-15 9:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bluez/bluez/push/refs/heads/1128034/000000-e5cd97@github.com \
--to=noreply@github.com \
--cc=linux-bluetooth@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.