[Interest] [QtBluetooth] Basic tests

[Blasche Alexander]

> -----Original Message-----
> From: interest-bounces+alexander.blasche=theqtcompany.com at qt-project.org
> [mailto:interest-bounces+alexander.blasche=theqtcompany.com at qt-
> project.org] On Behalf Of Claudiu Olteanu

> The tests passed on all combinations. I hope this is good
> news for Qt team :-) .

Indeed. Thank you.

 
> The only problem I encountered was when I tried to remove
> the BlueZ 5.23-1.1 and to install the BlueZ 4.101 from the sources.
> After the installation, the configuration file  (/etc/dbus-
> 1/system.d/bluetooth.conf)
> which specifies the required security policies for Bluetooth core daemon
> was missing. This gave me some headaches.
> 
> First I used the one from Bluez4.101 package but the
> Scan test (#4) didn't work. I decided to use the configuration
> file from Bluez 5.30 package and to run the test again. I was a little
> surprised but it worked.

That's very strange. As a first reaction I would argue that you didn't properly shut down your 5.x daemon. The interfaces are so different that it should not have worked. The Qt app uses whichever Bluez it finds at runtime. If 5.x continued to run due to improper shutdown then the 4.101 policy would have no effect and the install from 5.30 would have worked again.

> You can find below the differences between the two files:
> 
> claudiu at linux-qpot:~/Downloads/bluez-5.30/src>  diff bluetooth.conf ../../bluez-
> 4.101/src/bluetooth.conf
> <     <allow send_interface="org.bluez.Agent1"/>
> <     <allow send_interface="org.bluez.MediaEndpoint1"/>
> <     <allow send_interface="org.bluez.MediaPlayer1"/>
> <     <allow send_interface="org.bluez.ThermometerWatcher1"/>
> <     <allow send_interface="org.bluez.AlertAgent1"/>
> <     <allow send_interface="org.bluez.Profile1"/>
> <     <allow send_interface="org.bluez.HeartRateWatcher1"/>
> <     <allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
> <     <allow send_interface="org.bluez.GattCharacteristic1"/>
> <     <allow send_interface="org.bluez.GattDescriptor1"/>
> <     <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
> <     <allow send_interface="org.freedesktop.DBus.Properties"/>
> ---
> >     <allow send_interface="org.bluez.Agent"/>
> >     <allow send_interface="org.bluez.HandsfreeAgent"/>
> >     <allow send_interface="org.bluez.MediaEndpoint"/>
> >     <allow send_interface="org.bluez.MediaPlayer"/>
> >     <allow send_interface="org.bluez.Watcher"/>
> >     <allow send_interface="org.bluez.ThermometerWatcher"/>

The above changes are pretty much due to the API changes between Bluez 4 and 5. It is more or less in line with what I would expect.

> I added a new policy <allow send_interface="org.bluez.Manager1"/> to Bluez
> 4.101
> configuration file and decided to try again. It worked.

Do you get any output in the case of a failure without the above addition (especially when debugging output is used - for details see further below)?

To the best of my knowledge there is no such interface as org.bluez.Manager1 (not in 4.101 nor in 5.x). The "1" prefix usually is an indication of Bluez 5 API but the interfaces are more precise in their naming (e.g. ProfileManager1, AgentManager1 etc).  
 
> For the Scanning test with Bluez.4.101 this error was printed to stderr:
> qt.bluetooth.bluez: OrgBluezDeviceInterface* getDevice(const
> QBluetoothAddress&, QBluetoothLocalDevicePrivate*) reply failed
> QDBusError("org.bluez.Error.DoesNotExist", "Does Not Exist")
> 
> I don't know why because the remote devices were discovered.
> Maybe something is missing from my Bluetooth configuration file.

The above getDevice() function is related to Pairing and Bluez 4.x and involved in device discovery at all. This would explain why you still get a list of discovered devices and it also tells me that QtBluetooth jumps into the correct Bluez 4 code paths.

I can only speculate as to the nature of the problem. The most likely guess is along the line of not replacing the existing bluez installation properly. It is not just a matter of reinstall. I would check that the old daemon is properly shut down and no other process in the system is  offering some pairing related agent which may continue to run. I would suggest to turn on more verbose debugging in QtBluetooth. 

QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true"));

Adding the above line to your main() should do the trick and then run the 4.101 setup which fails without the manual policy change. Warning, this causes rather verbose debugging output. Maybe it provides further hints.

Personally, I have never replaced Bluez in a system which involved a major version jump. I have done 5.a to 5.b replacements though which seem pretty straight forward. For 4.101 testing I use Ubuntu 14.04 (even 15.04 is possible) and Fedora to get the latest 5.x versions.