diff options
author | Hans de Goede <hdegoede@redhat.com> | 2023-03-31 22:03:29 +0200 |
---|---|---|
committer | Luiz Augusto von Dentz <luiz.von.dentz@intel.com> | 2023-03-31 15:09:48 -0700 |
commit | de8e7cfce25b8d717f5ee60ee3b79d426fdcc681 (patch) | |
tree | a582187f73ca9438b75beba9b7ae72dd35f05176 /mesh | |
parent | c4d9b99db5a6b8efb7b710818a5261634086824b (diff) | |
download | bluez-de8e7cfce25b8d717f5ee60ee3b79d426fdcc681.tar.gz |
adapter: Use regular discovery for filters which only have discoverable set
discovery_filter_to_mgmt_cp() does not add discovery_filter.discoverable
to the created mgmt_cp_start_service_discovery struct.
Instead update_discovery_filter() separately checks
client->discovery_filter->discoverable for all clients.
This means that for discovery-filters which only have the discoverable
flag set, to put the adapter in discoverable mode while discovering,
the created mgmt_cp_start_service_discovery struct is empty.
This empty mgmt_cp_start_service_discovery struct then gets sent
to the kernel as part of a MGMT_OP_START_SERVICE_DISCOVERY msg
by start_discovery_timeout().
This use of an empty filter with MGMT_OP_START_SERVICE_DISCOVERY
causes some bluetooth devices to not get seen with some (most?)
Broadcom bluetooth adapters. This problem has been observed with
the following Broadcom models: BCM4343A0, BCM43430A1, BCM43341B0 .
On these models the following 2 devices were not being discovered
when starting a scan with a filter with just discoverable set
in the filter (as gnome-bluetooth does):
Device 09:02:01:03:0F:87 (public)
Name: Bluetooth 3.0 Keyboard
Alias: Bluetooth 3.0 Keyboard
Class: 0x00000540
Icon: input-keyboard
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: yes
UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v05ACp022Cd011B
Device 00:60:D1:00:00:34 (public)
Name: Bluetooth Mouse
Alias: Bluetooth Mouse
Class: 0x00002580
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: usb:v0103p0204d001E
Since setting the discoverable flag on a filter only is a way to
automatically put the adapter in discoverable mode itself while
it is discovering; and since this does not any device filtering
at all; modify merge_discovery_filters() to treat discovery with
such filters as regular unfiltered discovery.
This results in start_discovery_timeout() starting regular
discovery through a MGMT_OP_START_DISCOVERY message and this
fixes these 2 example devices not getting discovered by the
mentioned Broadcom BT adapter models.
Link: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/163
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Diffstat (limited to 'mesh')
0 files changed, 0 insertions, 0 deletions