Skip to content
Miatafy

Mazda Connect UI Architecture (Opera Presto HMI)

The Gen 6 Mazda Connect HMI is not a native UI toolkit. The main screens, menus, and controls are HTML5/JS/CSS rendered inside an embedded Opera Presto browser running on the CMU’s i.MX6 SoC. Everything you touch on the screen is web content, and every constraint of a 2013-era Opera build applies to it.

Source basis: browser behavior, Opera configuration, CPU affinity, and rendering constraints come from local rootfs/config analysis. CASDK behavior is documented externally in flyandi/mazda-custom-application-sdk, and the public silverchris D-Bus notes corroborate the JCI service interface surface.

CPU affinity

Section titled “CPU affinity”

The SoC is a dual-core Cortex-A9. Opera is pinned to one of the two cores. Several other services share that core, including the touchscreen driver, so rendering and touch input largely live together on one core while everything else runs on the other. This is why heavy DOM work and a busy service layer compete: they are not always on separate cores, and the touch path sits on the rendering core.

IPC to native services

Section titled “IPC to native services”

The browser-side JavaScript opens local IPC connections to the native service layer. Over those connections it receives events (vehicle state, button presses, navigation updates) and sends commands back. The HMI is a thin client: it draws, it listens, it dispatches — the actual work happens in the native services behind the socket. See Services for the service architecture.

Opera Presto constraints

Section titled “Opera Presto constraints”

The embedded browser uses Opera’s Presto engine, not Blink. Anything you write for it (a custom app, a theme, an injected tweak) lives under the limits of that engine.

JavaScript

Section titled “JavaScript”
  • ES5 only. No arrow functions, let/const, Promises, template literals, or destructuring. No ES6+ syntax of any kind.
  • All code uses var, function expressions, and callback-style async. Code transpiled for modern browsers will not run unless it targets ES5.

CSS

Section titled “CSS”
  • Transforms and animations require the -o- vendor prefix: -o-transform, -o-transition, -o-animation.
  • Gradients use -o-linear-gradient().
  • Standard prefixes (-webkit-, -moz-) and unprefixed properties are unreliable; assume -o- is the path that works.

Rendering

Section titled “Rendering”
  • Presto’s Vega backend supports hardware-accelerated Canvas 2D through the i.MX6 GPU.
  • Standard DOM rendering is not GPU-accelerated. Anything performance-sensitive (gauges, animated overlays) is faster drawn to a Canvas than built from animated DOM.

Custom applications (CASDK)

Section titled “Custom applications (CASDK)”

CASDK is a community framework for building custom JavaScript apps that run inside the CMU’s Opera browser. It provides:

  • Lifecycle hooks for app load, focus, and teardown
  • UI helpers tuned to the head-unit’s input model
  • IPC wrappers so app code can talk to native services without hand-writing the socket layer

CASDK apps inherit every Opera limit above — ES5, -o- prefixes, Canvas-for-performance. One practical ceiling worth knowing: data polling through CASDK runs at roughly 1 Hz. That is fine for status displays and slow-moving vehicle state, and too slow for anything that needs smooth real-time telemetry.

Browser configuration

Section titled “Browser configuration”

Opera is configured through an INI file on the rootfs that controls rendering behavior, memory limits, cache settings, and other tuning parameters. It is the single place where most “why does the UI behave this way” answers live, and the lever most modifications reach for.

Section titled “Related pages”