Specifications

Windows Embedded Automotive 7 Deep Dive: Phone Core and Media Core 9
When the system starts up, the display driver determines what type of vehicle display it needs
to adapt to on the basis of a CAN message broadcast by the display head unit. Until that
message is received, any requests for display write operations fail. Based on the received
information the display driver chooses the appropriate character-set translation map, the
supported display layouts, and a display-specific CAN signal assembly.
The display driver implements two sets of input/output controls (IOCTLs)—one for determining
the supported layouts and another for writing a message or for clearing the display. Applications
communicate directly with the display driver for streaming information, requesting display
capabilities, and more. The display driver also needs to maintain state information with the
audio subsystem because of dependencies between the audio source and a particular display
control. The display driver does not distinguish between the different display sections on the
display screen. It does not perform any queuing of requests. It also does not perform any
verification of whether the application writing to the display has permission to do so.
The display driver relies on the character-set map to perform a mapping of Unicode characters
to codes that the display understands. The character codes that are sent to the display are
6-bits long and are chosen from a set of 64 characters, which includes a default character used
to map any unknown characters. The display driver also truncates the number of lines in a
display request to actual lines that the layout supports (it does not truncate characters on a
line—that is the responsibility of the display head unit or of the application itself).
Native Display API
The native display API layer uses the services of the display driver after opening a handle to the
display driver through a call to CreateFile on “ICD1” (the device name for the display head unit).
The handle is stored for subsequent DeviceIoControl calls. Upon success, the native display API
layer requests the supported display layouts by calling IOCTL_DISPLAY_GET_LAYOUTS and then
caches them.
The native display API layer is a pass-through to the display driver. The native display API layer
performs focus and parameter validation and packages arguments to send to the display driver.
All calls into the native display API are synchronous, and there are no callback or event
mechanisms.
This API layer helps ensure that the application that is making a display request has obtained the
display focus. Display focus is determined by whether the application has the current graphics,
windowing, and events subsystem (GWES) foreground window. If the requesting application
does have display focus, an appropriate IOCTL call is issued to the display driver. Applications
can also query supported capabilities of the vehicle display from this API layer.
Note that a Windows Embedded Automotive HMI is typically defined using XAML and rendered
through the XAML renderer. But some applications, such as map and video, have their own
graphical outputs from their processes. These graphical outputs are composited into a single
HMI and presented as one UI screen from a user viewpoint. Typically, this composition is done
using a hardware overlay. Microsoft Silverlight for Windows Embedded provides a feature which
blends the graphical outputs of the applications into the Windows Embedded Automotive HMI
through the CompositorCore.