Merge lp:~kzapalowicz/ubuntu-system-settings/fix-1539158 into lp:ubuntu-system-settings

[Konrad Zapałowicz]

Fix pin code request is rejected because device is not valid

When the new device is created either almost or at the same time as the
pin code request is requested there is a race between pin code request
handler and the device initialization code. The pin code request handler
works only with devices which are valid. On the other hand the device is
valid only when it's type is updated. This happens when the properties
are gathered which is done in an asynchronous way. Because of this
asynchronousity it happens too late and by that time the pin code request
is rejected which denies the bonding.

This commit works around this issue by implementing a wait for device to
become valid. In order not to stall the wait is not infinite and the
nullptr is returned when the device cannot be set to valid. This has an
effect only when the addDevice is called from the FindOrCreateDevice
context as in any other case the properties are known by that point.

Fix pin code request is rejected because device is not valid

When the new device is created either almost or at the same time as the
pin code request is requested there is a race between pin code request
handler and the device initialization code. The pin code request handler
works only with devices which are valid. On the other hand the device is
valid only when it's type is updated. This happens when the properties
are gathered which is done in an asynchronous way. Because of this
asynchronousity it happens too late and by that time the pin code request
is rejected which denies the bonding.

This commit works around this issue by implementing a wait for device to
become valid. In order not to stall the wait is not infinite and the
nullptr is returned when the device cannot be set to valid. This has an
effect only when the addDevice is called from the FindOrCreateDevice
context as in any other case the properties are known by that point.

[Ken VanDine (ken-vandine)]

The code looks fine, besides a typo in your comment. Could you please fix "oly" in the comment?

I'm not sure how I can test it though, my car doesn't require a pin.

review: Needs Fixing

[lp:~kzapalowicz/ubuntu-system-settings/fix-1539158]

1634. By Konrad Zapałowicz on 2016-05-06

Fix typo in the comment

[Ken VanDine (ken-vandine)]

Thanks, looks good

review: Approve

[Jim Hodapp (jhodapp)]

A few comments inline.

review: Needs Fixing (code)

[lp:~kzapalowicz/ubuntu-system-settings/fix-1539158]

1635. By Konrad Zapałowicz on 2016-05-10

Improve the documentation and add const correctness

[Jim Hodapp (jhodapp)]

One minor grammar change in a comment.

review: Needs Fixing

[lp:~kzapalowicz/ubuntu-system-settings/fix-1539158]

1636. By Konrad Zapałowicz on 2016-05-10

Fix a typo in the documentation

[Jim Hodapp (jhodapp)]

LGTM

review: Approve (code)

[Simon Fels (morphis)]

LGTM

review: Approve

[Michał Sawicz (saviq)]

FWIW this didn't help in my car, will come up with logs again in a bit.

=== modified file 'plugins/bluetooth/devicemodel.cpp'
--- plugins/bluetooth/devicemodel.cpp	2016-03-15 14:44:34 +0000
+++ plugins/bluetooth/devicemodel.cpp	2016-05-10 13:05:23 +0000
@@ -22,6 +22,8 @@
 
 #include <QDBusReply>
 #include <QDebug>
+#include <QTime>
+#include <QCoreApplication>
 
 #include "dbus-shared.h"
 
@@ -499,6 +501,30 @@
     QSharedPointer<Device> device(new Device(path, m_dbus));
     device->setProperties(properties);
 
+    // The device is valid when the right properties are set for it. The
+    // code below makes sure that the right properties are set as in certain
+    // situations it happens with a delay.
+    //
+    // In case this function is called from FindOrCreateDevice() context
+    // the properties are not yet known. Of course the device will become
+    // valid once the device properties are gathered however this is done
+    // asynchronously, in the Device class constructor, and it takes a
+    // while. This is a problem in certain situations and as a consequence
+    // the pin code request is rejected and the pairing denied. To
+    // workaround this unwanted behavior we assume that at this point it is
+    // just a matter of time for the device to become valid and we wait a
+    // bit here. This is safe because in any other case the properties are
+    // already updated.
+    uint8_t tries = 0;
+    while (!device->isValid() && tries < 10) {
+        const QTime timeout = QTime::currentTime().addMSecs(100);
+        while (QTime::currentTime() < timeout)
+            QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
+        tries++;
+    }
+
+    // However if the above fails there is nothing else that can be done
+    // than returning the nullptr.
     if (!device->isValid())
         return QSharedPointer<Device>(nullptr);