| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| | |
Change-Id: Id21197134f525d6835664a2b2f27ca48d405406c
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously the remote rfcomm channel was fixed to 1 which may not
always match the correct rfcomm port.
At the end of the day this is still a workaround for failure to connect
when socket creation via UUID fails. We assume that the remote rfcomm
service can be reached via the channel number.
There is the remote chance that we connect to the wrong remote channel
because getServiceChannel() fails and we attempt to connect to the
hardcoded channel 1. However the workaround significantly reduces the
chance of failure as a few devices (especially on the low end margin)
cannot successfully connect via the UUID.
The patch improves code readability and formatting too.
Task-number: QTBUG-40172
Change-Id: Iae90252c877ca13953a81ea1ed83cc2c73abdf2a
Reviewed-by: firatagdas <firatagdas@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Ibc4c835a9778bfa220ad6553f2c0140a7727d75d
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is the default backend and Bluez is not a default backend. Hence
the default backend can never build Bluez specific sections.
Change-Id: I66f4ce9f4b7b4c4d222138ac2e56640d2bc08808
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| |
| |
| | |
The change improves the performance between 8-10%.
Change-Id: I342e669d3f18cd2179b65f1af172db52303ff44c
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| |
| |
| | |
It continues to live in the development branches
Change-Id: I13f140f78b26e4f1bf23d8e023834038812190c6
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The invalid service error is essentially the same as the operation
error. The OperationError remains and the ServiceNotValidError is
removed.
Remove an unrelated but obsolete TODO from the source code. We can read
larger than MTU values already. That's what the Blob requests are for.
Change-Id: I3ed496194d55cd05f8e9e09680e962a2b7638702
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These two functions are really only needed by Linux style socket code.
There is no need for other platforms to implement them as dummy too.
It simplifies the code somewhat.
Change-Id: I3e0aced8d9f7b590d1c6aaa60f97bd060ee8f4b4
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several bugs prevented QBLuetoothServiceDiscoveryAgent from properly
working on Bluez5
1.) If parseSDPRecord returned an empty QByteArray we continued the
parse loop without further advancing the sdpResult list.
2.) Each sdp result was individually base64 encoded but the library
side decoded the entire list of items in one go. The item separation
gets lost during the transfer. As a result only every second item was
properly decoded. Therefore only every second sdp record was properly
recognized. Now we encode the entire result and transfer it in one go.
3.) Don't separate the xml items based on their size anymore. Although
this is possibly slower it is a lot simpler to understand
and debug. In combination with the above two problems the previous
pointer based logic was leading to crashes too.
4.) QProcess::readAll() seems to loose data when the process
finished and the output was very large. After this patch we start
reading right after the start of the sdpscanner.
Change-Id: I84a0be9d68e86c851945751c576a3ccf755db883
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| | |
Change-Id: I0be30191cbceb963c7e1bfd7e55a1f2f38772d5f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove old and obsolte code description. Later this will be readded
based on the Bluetooth-le-overview documentation which describes the
same thing.
Improve screenshot section of the example.
Change-Id: I499809fa0afdb27f09844678a52d0ce5a492b3c0
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I252c085f5b3ea6ccc2820a1f59d9228745ae2900
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I7a8b8b787fcae9a178794364efdefe1021d10b1b
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I65d28f43862e95258c3115b79de839b884966119
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I9f8a2cc1b833e91f05434e68ad3b5b4757eac786
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This class is part of the new Bluetooth Low Energy feature in Qt 5.4
Change-Id: If10cac1ac1312cb63137c854a4456bf2d646f630
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This class is part of the new Bluetooth Low Energy feature in Qt 5.4
Change-Id: Ib1a8000b4ad256400f18e241a296fe1ffa97414a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I493a7087e29399c1d32116a07e51ce7aa18becc0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
|\ \
| | |
| | |
| | | |
Change-Id: I6786b50e3f302c6027255dc2393b3e7923705a1d
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I44c2ba2308a786b1ed67a9f89701c2d18fe64f6b
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
|
| |\ \
| |/ /
|/| |
| | | |
Change-Id: I1e79c96602d0da2c2d36d6217bdfe7ff183e6df9
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ieecf341918ffdc51c359fed4969ef6c3998d83b8
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is required to avoid tainting of QtBluetooth with GPL code from
Bluez.
Subsequent patches will remove GPL code from the new Bluez5 backend
in the library and call this binary instead.
Change-Id: Iff62ecb430d4a486a2d1f7382ba5dc48b229fea5
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/bluetooth/bluez/bluez.pri
src/bluetooth/qbluetoothsocket_bluez.cpp
Change-Id: Ieca8f2a327bf54b42403ddab88f8b9c3ff6b4a95
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I52ac33b4864d6bfca248ff3fad5a069154a9c756
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I548d17928fb371ba7dbf2010efb6995bc6f5ff2d
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It seems not all devices reliably return the correct value when calling
isConnected(). connect() succeeds but isConnected() is still false.
On the positive side it is not really needed either.
Calling connect() returns an exception if it fails and close() can be
safely called multiple times. Therefore we only have to check for ocurring
exceptions.
Furthermore isConnected() is API lvl 14 and was not guarded. Removing
the call resolves this problem too.
Task-number: QTBUG-39815
Change-Id: Idf8472c268231a2cfac0f5cd87294384ff779c3f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This equalizes the behavior of the Close and Abort button. Abort will
disconnect the local client socket as well as all sockets which were
established via the listening server socket.
Change-Id: I68d3d7190641aab44612fa3fc00b38fdc31799a3
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
-url inherited from the url variable set in qtbase/doc/global
Change-Id: Iff25abdbdbddd862cfc24d31aa12e103955bb5d2
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Device discovery of BTLE devices fails once the second device discovery
is performed in the current process. The first discovery always succeeds.
BTLE devices are advertised right after the start of the device discovery
session. However the discovery session never seems to stop once it is
done for the first time. This can be seen by the fact that the
Discovering property of the adapter constantly toggles between true
and false. As a consequence the second device discovery won't find
a BTLE device in 99% of all cases. The odds that the API user initiates
the second discovery right between two continues adapter searches
is rather slim.
The fix is to extend the device discovery process beyond
a toggle of a single device discovery cycle. We ignore the
end signal of the first cycle and continue to the end of the second
cycle. At the same time we rely on the perceived bug which restarts
the second cycle automatically. Just for the case that the second cycle
doesn't start automatically we utilize a timer to manually force
an end of the device discovery.
The problem is likely to be a bug in Bluez4. A negative side effect
of this workaround is a longer device discovery process.
Change-Id: I986c8d6498b2cc9ed51f4457267c53813132cf8e
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I49945b13f9b2ee025541c7f689b55fa994c8057d
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Id11d2dcb06bd04bc1d911d746002fbbc53326ffa
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
QLowEnergyService::ServiceState was converted to a flag because a
primary and secondary service can be included by other services.
Change-Id: I425ce8e3f39ee07cccee2763b57a049a624f6178
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There is no point converting the data to its hex representation. The
use case at hand will decide it in the current application context.
The returned QByteArray is the raw byte array as it comes from the
device.
This behavior was legacy (introduced by the previous API) and
subsequently it was simply adopted.
Change-Id: If662c02a5e3c3d37cccb374add02e75522352894
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Services cannot always discovered via SDP. Therefore we can only run
a device discovery and let QLEController do the service discovery.
In addition we add the missing Connection Control service to
the QLEController unit test. This service was introduced by a firmware
update on the TI SensorTag.
Change-Id: I52f172c0c4968c393779cd42275c548998dde8ce
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Moves the new API into its place and completes the removal of the old
API.
Change-Id: I10a285e24e288aeb747cb1606574e27a4bf57308
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It never worked and was not used. In the future there might be a new
GATT DBUS API offered by Bluez.
Change-Id: If4c05d37e330ff3cdcda3ef3458938e2bce30725
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Removes obsolte code from the previos GATT API and other API elements
which do not make any sense under the new API anymore.
The entire purpose of QLowEnergyServiceInfo is also in question
as it doesn't really contain BTLE specifics when compared
to QBluetoothServiceInfo. This requires further API evaluation.
Change-Id: Idfce724bb58150839f756745b87864054909dedb
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The subsequent patches will rename QLowEnergyControllerNew to
QLowEnergyController and fix up the documentation fragments which still
point to the old API.
Change-Id: I084e6b1a85a17f424702018f3ad7047bda35d46a
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This seems to be optional for Bluez4 but mandatory for Bluez5 to
establish a connection at all.
Change-Id: Ia99b6e6623fc63f3d0abe37a87808a59cbd889f1
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ia83faca0a48174e1faf47491b22db636200f5ea8
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Idc04620c3941ec92c7ea81e1ba4ec521cf000720
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ieaa5f3bc5bcba73552deb60b807f27acc11c4602
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Between Bluez v5.0 and 5.1 this header was removed from libbluetooth.
While the reason is not obvious we didn't really need the header and
its related symbols anyway. Hence we can safely remove it.
Change-Id: I628124f19104bd2d3750072897f1cde21de04185
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1.) Improves UI flow
2.) Improves error behavior (e.g. device disconnects)
3.) Adds missing signal/model updates whcih caused unexpected UI flow
Change-Id: Icc7edf4945df0e964b5c91b407ce5976a1585b81
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The discovery of the service details immediately stops as no
characteristic means no descriptor, no descriptor value and no
characteristic value.
Change-Id: Ifca5529369d09d67d3840126081b32210102dbde
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some BTLE servers (e.g. the tested CSR development kit) send requests
to the BTLE client although they shouldn't according to the spec.
Most likely they are due to firmware bugs. Too avoid that those messages
confuse the message handlers they are being filtered out (ignored).
Change-Id: I60c75ef9c5316d680ce7119aada2fb1ab6161eba
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The MTU is still being ignored during the read/write operations. This
will change in later commits.
Change-Id: If13cf949e5258159ec59678e9235de4d248af446
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is in accordence with the maximal possible handle size
of 0xffff as per Bluetooth spec.
As a side effect processReply() had to be modified since
endHandle (0xffff) + 1 caused a type overrun.
Change-Id: Ibdd0ec49f6f5fba7cf875f92a52659c6961076e9
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This new API is mostly syntactic sugar and reduces the amount of code
to be written by API users.
Change-Id: I51ff1ea706ac97199646d211e39e79c8140ee74b
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|