Age | Commit message (Collapse) | Author | Files | Lines |
|
Import the patches for the demo applications into the app repos.
Bug-AGL: SPEC-5294
Change-Id: I516a951cdd49dbfb1729bf4e49360333b951bad3
Signed-off-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
|
|
Rework the VehicleSignals class and its use in the Navigation and
Hvac classes to switch from using the original KUKSA.val server
via WebSockets to the KUKSA.val databroker's gRPC "VAL" API.
Notable changes:
- The VehicleSignals API has changed a bit with respect to setting
signals, callers now need to pass the new value as the type that
matches the signal as opposed to always passing a string, and
optionally indicate if an actuator's target or value is being set.
Subscribe operations now also allow subscribing for either
actuator targets or values.
- It is possible that the values returned by get and subscribe
operations will be changed to using QVariant instead of QStrings
in a future follow up, but that has not been done in these changes.
- The connected signal from VehicleSignals still has roughly the
same meaning, but the authorize function and authorized signals
are to some degree redundant now. They have been kept for
compatibility, but may be removed in a follow up set of changes.
- The section header in the .ini files expected by the
VehicleSignalsConfig class has been changed from "vis-client" to
"kuksa-client" since the databroker is not a VIS server, and to
some degree forcing an update on the part of clients is useful
since their authorization tokens also need to change.
- The client key and certificate support has been removed from the
VehicleSignalsConfig class, as they are no longer used in either
the server or databroker as of KUKSA.val 0.4.0. A new optional
parameter, "tls-server-name", has been added to work with the new
TLS support behavior. It can be used to override the expected
host name for connecting to a non-local databroker instance.
- The Navigation constructor now takes an additional parameter to
indicate whether the instance acts as a router or a client.
The underlying need for this stems from an application acting as
a router needing to subscribe to the destination setting actuator
targets.
Bug-AGL: SPEC-4762
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: I253480ae2abf068dc6e41a495454960ed5c0feaf
|
|
The code for double values for VSS signals was using the default
Qt double to string conversion, which defaults to a max of 6
decimal places, explicitly format with 9 so that latitude and
longtitude values for the navigation related signals do not get
truncated.
Bug-AGL: SPEC-4662
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: I49d23c4224c41f33687c20cdbd21f4cbb538c52d
|
|
Add meson configuration missed in previous commit.
Bug-AGL: SPEC-4559
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: Idbcd961ab91cf48e7dc3b841aee3a79d0b615dcd
|
|
Changes:
- Add applaunchd gRPC API wrapper in applauncher directory, clients
can include AppLauncherClient.h to use it.
- To facilitate generating protobuf and gRPC code with protoc,
switch from CMake to meson for building. While the code
generation can be done in CMake, it is a lot more straightforward
with meson, and if use of this library continues meson will be
easier to maintain.
Known issues:
- The behavior of the client implementation here with respect to the
server side (i.e. applaunchd) going away is currently robust, but
could stand improvement with some further investigation. As the
code stands, starting applications works when applaunchd becomes
available again, but the streaming status RPC that is tied to
window activation in the homescreen does not reconnect, and there
seem to be some things that need to be resolved with respect to
Qt object connection expiry to do so. If the Qt demos continue to
be used in a significant fashion, this may be worth picking up.
Bug-AGL: SPEC-4559
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: I5cb480d4ce4d1cb944ebfd4114fb305f09f28ea3
|
|
Add vehicle-signals library that exposes configuration and interface
objects to use Vehicle Information Service (VIS) signals from a VIS
server such as KUKSA.val. In this initial version Qt signals to
expose some of the low level VIS errors to clients have not been
implemented, as it is not immediately obvious how they could be
leveraged in the AGL demo usecases. If the Qt demos continue to be
used for past the Needlefish release this may warrant revisiting.
Bug-AGL: SPEC-4408
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: I05d2bfdd09d090e3ed13ba4e4c2d1d205357d6e4
(cherry picked from commit b34fae267102d374bcc9ab7a6ff6a259515bb6bf)
|