The current idea is to have a single set_powered management command
which for the switching on case would leave the controller in a
non-connectable, non-pairable and non-discoverable state.
Now GATT client should be able to make LE connections. The information
used to determine if we should make a LE connection is the psm stored
in the gatt_service structure.
This adds a way to remove the information about the device type and its
primary services when the device is going to be removed from the permanent
storage.
As the primary services were discovered by the core bluetoothd, we need
a way to export that information.
The service discovery uses the same primary list as the device, there's no
need to free that list when the discovery finishes. That list will be removed
when the device is free'd.
A2DP spec allow bitpool changes midstream which is why sbc configuration
has a range of values for bitpool that the encoder can use and decoder
must support.
Bitpool changes do not affect the state of encoder/decoder so they don't
need to be reinitialize when this happens, so the impact is fairly small,
what it does change is the frame length so encoders may change the
bitpool to use the link more efficiently.
Because we need to know the device type (LE, Basic Rate or Dual Mode)
to be able to fully restore the device from storage, we have to store
and load this information to permanent storage.
Note: due to "device_type_t" usage in storage.h, some header includes
needed to be reordered in files which include storage.h.
As the comparison method used for find what to de-register was
wrong, it was causing the btd_device reference that the attrib
plugin was keeping never to be dropped.
HFP/HSP can be connected when registering an endpoint which is different
than on a2dp where the sep cannot be configured already since it wasn't
available before.
There's no need for the core daemon to have special handling for debug
keys anymore as long as it tells adapter_ops if they are enabled or not
(new parameter added to adapter_ops->load_keys).
hciconfig: warrning user on unknown commands
hcitool: return error on unknown command in hcitool
fix length size in comparision to avoid ambiguity commands
check if command number of arguments is correct
In most cases it's more convenient to use the adapter index when looking
up the adapter object since the index is always available in the
adapter_ops callbacks.
Currently, EIR parsing (name, UUIDs, flags etc.) is done in various
places. This leads to duplicated checks and does not support parsing
multiple AD/EIR structures on a single transfer.
These changes modify get_eir_uuids() to parse other EIR data types and
avoid passing raw EIR data to higher layers.
To accomplish this, get_eir_uuids() was renamed to parse_eir_data(), and
a new (internal) "struct eir_data" was introduced to store the parsed
data.
This first commit only handles the services UUIDs, following patches
will move other EIR parsing to it until everything is done inside
parse_eir_data().
Moving get_eir_uuids() to src/event.c removes the need to pass the raw
EIR data to higher layers. Now it is not necessary to pass the original
GSList of service UUIDs, because the list is concatenated (with
verification of duplicate entries) on adapter_update_device_from_info()
(for LE) and adapter_update_found_devices() (for BR/EDR).
