> -----Original Message-----
> From: interest-bounces+alexander.blasche=theqtcompany....@qt-project.org
> [mailto:interest-bounces+alexander.blasche=theqtcompany.com@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@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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to