| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The fact that each client can start its own discovery wasn't clear from
the documentation and only becomes obvious when reading the sources.
|
|
|
|
|
| |
This adds ExperimentalFeatures property which indicates what
experimental features are currently enabled.
|
| |
|
|
|
|
|
|
|
| |
This change adds a new property to indicate the support for concurrent
roles which means that the controller has reported the appropriate
LE_Supported_States (hdev->le_states) and that the controller's driver
has reported correctly handling the various reported states.
|
|
|
|
|
|
| |
This adds a pattern filter which can be used to filter devices by
address or name prefix which is quite convenient on a crowded
environment.
|
| |
|
|
|
|
|
|
|
|
| |
This enables the client to set its discoverable setting while
discovering which is very typical situation as usually the setings
application would allow incoming pairing request while scanning, so
this would reduce the number of calls setting Discoverable and
DiscoverableTimeout and restoring after done with discovery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to connect device without doing general discovery. This is
needed for some of qualification tests where there is no general
discovery upfront and we need to do connection to device with provided
address.
Another usecase is for scenario where scanning happen on one controller
but connection handling on another.
New device object is announced only if physical connection was
successful. On success this method returns path to created device
object. After ConnectProfile return bluetoothd continue with
services discovery and profile connection.
This patch implements bare minimum properties needed for connection -
address and address type. If needed eg. for non-NFC based OOB it could
be extended with more options.
|
|
|
|
|
| |
This provides information about address type being used. It is needed
for L2CAP sockets and PTS testing purposes.
|
|
|
|
|
|
|
|
| |
Since essencially what this filter would be doing is disable duplicate
for data use it instead of ResetData.
Also inline the documentation of each filter option to make it easier to
read what each option does.
|
|
|
|
|
| |
In order to extend SetDiscoveryFilter with more filters the application
might have to query what filters are available.
|
|
|
|
|
| |
Reset service/manufactorer data so the application can see each and
every instance of them.
|
|
|
|
| |
The method is not set as experimental for while.
|
|
|
|
|
|
|
| |
This makes it possible to use SetDiscoveryFilter to disable checking
discoverable flags making it possible to see beacons such as the ones
create by tools/eddystone that doesn't show on regular discovery sessions
since they are not discoverable/connectable.
|
| |
|
| |
|
|
|
|
|
|
| |
This patch proposes new method, SetDiscoveryFilter to D-Bus Adapter
API for desktop bluetoothd. It will allow to set per-client discovery
filter that would limit devices being discovered.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
ObjectManager reports the D-Bus interfaces of all known devices,
including the ones detected during discovery. Therefore this signal is
not required.
|
| |
|
|
|
|
|
| |
Sessions is no longer used by obexd and the concept is probably not
relevant anymore since BlueZ 5 don't remember powered state anymore.
|
|
|
|
|
| |
Trivially add the numbering suffix to org.bluez.Adapter according to
the proposal for BlueZ 5.
|
|
|
|
|
| |
Trivially add the numbering suffix to org.bluez.Device according to
the proposal for BlueZ 5.
|
|
|
|
|
|
|
| |
ObjectManager.GetManagedObjects() returns all devices and their
corresponding properties to any interested client. The device address is
included in the property dictionary and therefore having such a
FindDevice method is an unnecessary duplication.
|
|
|
|
|
| |
The ObjectManager interface already reports the list of devices, so the
the property can be entirely removed.
|
|
|
|
|
| |
The Adapter interface already reports changes in the device list in form
of property changes, so there is no need to keep these two signals.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Applications that want to be Observers of certain Advertising data type
(e.g. Manufacturer Specific Data or Service Data) will use new Observer
D-Bus API to monitor these AD types. Therefore, the old Broadcaster
device property is unnecessary.
|
|
|
|
|
| |
CreatePairedDevice and CreateDevice trigger GATT discover all primary
services procedure if the device is Bluetooth Low Energy.
|
| |
|
|
|
|
| |
This patch fix simple typo in documentation of API.
|
| |
|
| |
|
|
|
|
| |
This patch fixes incorrect spelling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Accounting of misspelled words, as detected by codespell:
acording 2
ancilliary 1
appropiate 1
atribute 1
cant 1
comming 2
gracefull 1
lenght 1
mispelled 1
occured 1
occurences 1
ocurred 3
prefered 1
presense 1
reponse 1
seperate 1
succesful 1
successully 1
sucessfull 1
sucessfully 1
|
|
|
|
|
| |
RequestSession and ReleaseSession description is updated in adapter
API.
|
|
|
|
|
|
|
|
|
| |
Broadcaster property is required to distinguish the device role. If the
remote is sending an advertising event, two possible roles are possible:
Peripheral or Broadcaster.
This change is required to pass on qualification tests which require
filtering Broadcasting devices during General Discovery Procedure.
|
| |
|
| |
|
|
|
|
|
|
| |
Some possible errors returned by GetProperty and SetProperty are not
applied anymore. GetProperty returns NotReady only. SetProperty returns
InvalidArguments only.
|
|
|
|
|
|
|
|
| |
* Include UUIDs field to method GetProperties(org.bluez.Adapter).
Applications can get local services(UUIDs) available through D-Bus.
* UUIDs per-adapter stored at btd_adapter to prevent some searches not
necessary regarding it requires information from access_db and service_db.
* Emit Adapter.PropertyChanged signal when UUIDs change.
|