1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
**Table of Content**
1. TOC
{:toc}
## Context
In today's world, the information for drivers is becoming excessive. For example
, safety information to let driver notice the obstacles on the road, telematics
information about car accident or traffic jam, media information from connected
phones etc. In the future world, it is expected that the more displays will be
available in the car and show more information. Thin-Film Transistor(TFT) Cluster
will have more information other than engine speed and map, Head-Up-Display on
windshield will bring driver to new world.
However, too much information would make drivers confused. We need more
comprehensive Human Machine Interface, which displays the information what the
driver needs on appropriate place and time with comprehensive user interface
design. To conclude, Graphics sharing between multiple Electronic Control Unit
(ECU)s are necessary. Waltham is developed for this purpose.
## Waltham
[Waltham protocol](https://github.com/waltham/waltham) is a network IPC library
designed to resemble [Wayland](https://wayland.freedesktop.org) developed by
Collabora along with ADIT, a joint venture company owned by Robert Bosch Car
Multimedia GmbH and DENSO corporation.
Wayland is a protocol for a compositor to talk to its clients as well as a C
library implementation of that protocol. Waltham does same as Wayland, the
protocol is described in XML files, parsed results in a C library. libwayland-
server and libwayland-client are both IPC libraries. Waltham on the other hand,
it works over the network. Sharing function itself is not implemented in Waltham.
Please refer [Waltham documentation](https://waltham.github.io/waltham/) for
more details.
### Major differences from Wayland to Waltham
- Waltham uses TCP sockets for reliable communication
- Waltham cannot send file descriptors
- Waltham API is minimal and symmetric between server and client sides
- Waltham does not provide an event loop implementation
- The registry implementation is left out of the library, only the interface is
provided
- No multi-threading support for sharing objects between threads
### Requirements in automotive industry
In order to use Waltham in automotive industry, the automotive specific
requirements must be covered.
The below shows very high level requirements. You can find the further
requirements at [i**Waltham Requirements**](https://confluence.automotivelinux.org/displa
y/UIGRA/Waltham+backend+requirements).
1. Shall be able to support fast/reliable remoting among multiple ECUs
2. Shall be able to support input handling
3. Shall be able to share dedicated application
4. Shall be able to share complete display output depending on additional
communication
* Surface sharing is not part of Waltham protocol, Each system needs to
implement the most efficient way for surface sharing.
On AGL, we implemented [Waltham client and Receiver](1-waltham-client-and-receiv
er.md) to enable surface sharing along with GStreamer encoder/decoder.
It uses UDP for remoting, which is faster than TCP. Input events communicates
with Waltham protocol.
### Links
* [Announcement of Waltham](https://lists.freedesktop.org/archives/wayland-devel
/2016-October/031413.html)
* [Bi-weekly meeting minutes](https://wiki.automotivelinux.org/eg-ui-graphics)
* [UI and Graphics wiki](https://confluence.automotivelinux.org/display/UIGRA/UI
+and+Graphics+Home)
* [Waltham source codes](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/
weston-ivi-plugins.git;a=tree;h=refs/heads/master;hb=refs/heads/master)
|
