This adds some valuable piece of information from the Bluetooth spec.

Change-Id: Idb0211e23a3fc03674f7878eaebea9c529dbd69d
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>

At the same time we fix up some cases where the ProtocolDescriptorList
was not a list within a list.

Change-Id: If0ec6cf6374902a47a905edd08523906be9fd86b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

There is no need for this class anymore as QBluetoothServiceInfo
covers the same information.

Change-Id: I411a8abb68b34a3a4893a67ee9fac096f44bbd62
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Change-Id: I87575fb7b5115a536e12c0a00374cc0e67428706
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

The previous characteristicChanged() signal was emitted when the
characteristic was updated due to a notification and when the value was
changed using writeCharacteristic(). This meant that it was not possible
to distinguish the two use cases. The new signal is only
emitted in response to writeCharacteristic() whereas the old signal is
only emitted when the peripheral indicates a change.

Change-Id: Ie8797090f9463ae0e7fb053a42a79afa6829ca75
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

This is the part of a change to be able to distinguish
characteristic write confirmations from characteristic
change notifications. Since descriptors
cannot receive notifications they won't have a
changed() signal and all existing
descriptorChanged() signals become descriptorWritten()
signals.

The changed() signal is emitted when a value notification
is received from the device. The written() signal is emitted
when a write request from the API user was successful.

Change-Id: Ief2491ead4723eaa1bca65a09a09c34458f33630
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

So far, we only supported write requests which reply with write
responses.

Change-Id: Ibdad36dcf18dec23260f003911b9361cc4ab1e3d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Change-Id: Ie3146c136461ad4ecde4169f3b30dda0c814ca7b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Change-Id: I963f47f0089d072249b73bdfb0c715d43186b08d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

This is required to be able to connect to devices which use random device
addresses. Some platforms can determine this flag based on their last
device scan. The flag is likely to be provided as part of
QBluetoothDeviceInfo once the information is available.

Unfortunately non-le scan on BLuez doesn't inform about the
flag. The LE device scan is currently not implemented and, even worse,
requires root privileges on Linux. The new API element permits the
selection of the correct type when the scan doesn't detect the type
properly.

Change-Id: I8e7118658a7c927e0ea07b0d639d57f9483cb33c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Bluetooth byte order is little endian. htbos ensures the psm is
converted to the required byte order.

Change-Id: I22362d1f1fe3978df7855eab14154644a1d60a0d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Conflicts:
	src/bluetooth/qbluetoothdevicediscoveryagent_p.cpp

Change-Id: Ie8bf1903f9c7c1ccd5b05a3f97049ae0882b88b8

L2CP's psm (the RFCOMM port equivalent) was never published via SDP.
Therefore the service client could not get the required information
to connect to the server. After this patch Qt properly publishes
the psm.

Also, QBluetoothSocket::connect() initiated a service
discovery to obtain the missing psm. Since the published SDP
entry didn't contain one, protocolServiceMultiplexer() always returned
0 and another service discovery was initiated. This caused a crash
inside QBluetoothSocket because the 1st QBluetoothServiceDiscoveryAgent
instance was deleted in favor of the 2nd.

The patch changes the client behavior such that it doesn't crash
if the service discovery didn't turn up a valid psm/port.
It improves the robustness in case of an error and avoids
a second service discovery (which wouldn't turn up more information
anyway).

The bug only affected Bluez as it is the only platform supporting
pure L2CP sockets.

Last but not least a capability to test L2CP sockets was added to
b...

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>

Change-Id: I0f079a9b1b45bd2d2e946e06d7688f299a9c3fc3
Reviewed-by: Alex Blasche <alexander.blasche@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

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>

Change-Id: Id21197134f525d6835664a2b2f27ca48d405406c
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>

Change-Id: Ieecf341918ffdc51c359fed4969ef6c3998d83b8
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@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>

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>