Merge lp://staging/~kzapalowicz/ubuntu-system-settings/fix-1539158 into lp://staging/ubuntu-system-settings
| Status: | Merged |
|---|---|
| Approved by: | Ken VanDine |
| Approved revision: | 1636 |
| Merged at revision: | 1665 |
| Proposed branch: | lp://staging/~kzapalowicz/ubuntu-system-settings/fix-1539158 |
| Merge into: | lp://staging/ubuntu-system-settings |
| Diff against target: |
42 lines (+26/-0) 1 file modified
plugins/bluetooth/devicemodel.cpp (+26/-0) |
| To merge this branch: | bzr merge lp://staging/~kzapalowicz/ubuntu-system-settings/fix-1539158 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Simon Fels (community) | Approve | ||
| Jim Hodapp (community) | code | Approve | |
| Ken VanDine | Approve | ||
|
Review via email:
|
|||
Commit message
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.
Description of the change
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.
| Michał Sawicz (saviq) wrote | # |
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.