[agl-discussions] Potential Disagreement Between AMB and Qt 5.5.1

Avila Risto risto.avila at theqtcompany.com
Tue Dec 15 06:56:06 UTC 2015


Hi,


Can you share the test code and the log you are getting?

I could take a quick look and create bug report for Qt.


Best regards,

Risto Avila

Senior Software Engineer | The Qt Company
qt.io | blog.qt.io

________________________________
From: automotive-discussions-bounces at lists.linuxfoundation.org <automotive-discussions-bounces at lists.linuxfoundation.org> on behalf of Vick, Matthew <mvick at jaguarlandrover.com>
Sent: Monday, December 14, 2015 10:50 PM
To: automotive-discussions at lists.linuxfoundation.org
Subject: [agl-discussions] Potential Disagreement Between AMB and Qt 5.5.1

All,

As I've been developing the HVAC QML plugin, I've hit a roadblock where I can only either access AMB's TargetTemperature property or its FanSpeedLevel property, but never both. I am only able to read/write the first property I access.

For those unfamiliar with AMB, properties are discovered through a Manager object on the D-Bus to protect applications from properties moving. The basic flow is:
1. Tell the Manager interface the object you are interested in.
2. Store/parse the response from the Manager interface to get the path to the object. (Currently, it is of the form /(Unique Identifier)/(Zone)/(Object), e.g. /ABCD1234/0/FanSpeedLevel.)
3. Now that you have the path, you may read/write properties within the object as desired.

To help debug this, I wrote myself a simple Qt application that does nothing more than read and print the AMB properties. Running this program with Qt's D-Bus debugging functionality turned on yielded an interesting result: it appears that Qt is failing to do the D-Bus introspection on the second path provided. What this means is that Qt is erroring out internally, so we cannot access more than one zone of the vehicle. Based on what I'm seeing, my guess is that Qt is not properly parsing the full path AMB is providing. For example, it seems to view "/ABCD1234/0" as the same path as "/ABCD1234/5".

It appears that I can work around the problem by having my basic Qt application call another Qt application to perform the D-Bus access. It's hacky, but it at least seems functional.

As always, there is a chance it's just a case of PEBKAC, in which case I welcome any and all suggestions as to what I may have overlooked. In the interest of time for the CES demo, I'll proceed with the application-calling-application approach, but longer term for AGL I think we need to gain a better understanding of what's happening. Does anyone have any ideas?

Cheers,
Matthew

--
Matthew Vick
Linux C++ Developer

[http://www.jaguarlandrover.com/email/jlr.jpg]

Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
JaguarUSA.com<http://www.jaguarusa.com/index.html>  |  LandRoverUSA.com<http://www.landrover.com/us/en/lr/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20151215/9d8e2f71/attachment.html>


More information about the automotive-discussions mailing list