summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--docs/0-waltham-overview.md54
-rwxr-xr-xdocs/images/Diffrence_between_Wayland_and_Waltham.jpgbin352025 -> 357121 bytes
2 files changed, 29 insertions, 25 deletions
diff --git a/docs/0-waltham-overview.md b/docs/0-waltham-overview.md
index fe09f4b..3ca369e 100644
--- a/docs/0-waltham-overview.md
+++ b/docs/0-waltham-overview.md
@@ -5,37 +5,41 @@
## 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.
+In today's world, the information for a driver is becoming excessive. For
+example, the safety information to let a driver notice the obstacles on the road,
+the telematics information about a car accident or a traffic jam, the media
+information from connected phones etc. In the future world, it is expected that
+more displays will be available in the car and show more information.
+The cluster will have more information other than engine speed or fuel meter,
+In-Vehicle-Infortainment discplay will show you a map with very rich contents not
+only gudigin the route. Head Up Display on a windshield will bring the driver to
+the new world. Therefore We will need to show the information on the appropriate
+display, so that a driver will not be confuesed due to the information overload.
+In order to achieve this, we need something which can transfer the information
+from the device where it's produced to the display which makes it visible.
+Waltham is developed to be this something. It transfers the rendering metadata
+from one device to the other.
## 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.
+Waltham resembles [Wayland](https://wayland.freedesktop.org).
+Wayland is a communication protocol with C libraries that implement (Wayland)
+protocol. Compositors and clients use those libraries to talk to each other.
+(libwayland-server and libwayland-client).
+Waltham is also a protocol, which is described in XML. As a result of parsing that
+mark-up language, it's a C library. The keyword here about Waltham is the *network*
+IPC library. libwayland-server and libwayland-client are both IPC libraries.
+Waltham on the other hand, works over the network.
+Waltham is developped by Collabora along with ADIT, a joint venture company owned
+by Robert Bosch Car Multimedia GmbH and DENSO corporation.
+
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 API is minimal and symmetric between server and client side
- Waltham does not provide an event loop implementation
- The registry implementation is left out of the library, only the interface is
provided
@@ -48,7 +52,7 @@ 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
+requirements at [**Waltham Requirements**](https://confluence.automotivelinux.org/displa
y/UIGRA/Waltham+backend+requirements).
1. Shall be able to support fast/reliable remoting among multiple ECUs
@@ -61,8 +65,8 @@ communication
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.
+Gstreamer transfers the buffers via UDP, which is faster than TCP.
+Input events are supported by Waltham protocol.
### Links
* [Announcement of Waltham](https://lists.freedesktop.org/archives/wayland-devel
diff --git a/docs/images/Diffrence_between_Wayland_and_Waltham.jpg b/docs/images/Diffrence_between_Wayland_and_Waltham.jpg
index 020770f..0383654 100755
--- a/docs/images/Diffrence_between_Wayland_and_Waltham.jpg
+++ b/docs/images/Diffrence_between_Wayland_and_Waltham.jpg
Binary files differ