What's New in OpenPV 5

OpenPV 5 includes changes both visually as well as architecturally which are designed to support new platforms, improved modularity and performance. This document will help you navigate the various changes as you begin developing with OpenPV 5.

Overview of Changes

Overall, our goal in OpenPV 5 was to maintain high levels of compatibility with OpenPV 4 while improving the experiences in many common OpenPV Workflows. While many of the changes are directly applicable to the OpenView Pro hardware platform, many of the improvements apply to new and existing platforms.

Improved Support for Ahsoka.CommandLine – Ahsoka.CommandLine has been significantly expanded. The following commands are new or updated since OpenPV 4:

Project and SDK Management (Desktop):

--AddExtensions [PathToPackageInfoFile] [SupportVersion] [IncludePreRelease] — Installs extension NuGet packages directly into the specified project.
--AddSdkFromLocal [PathToPackageInfoFile] [PlatformSupportFolder] — Installs SDK files from a locally downloaded Platform Support package.
--AddSdkFromSpark [PathToPackageInfoFile] [SpecificVersion] [SparkConnectionInfoFile] — Downloads and installs SDK files directly from Spark.
--RunSdkCommands [PathToPackageInfoFile] — Runs model and code generation commands included in the core and extensions.
--GenerateExtensionInfo [AssemblyName] [OutputFile] [Namespace?] — Generates an AOT-safe IExtensionRegistrar source file by scanning an assembly. Used for Native build support.

Packaging:

--GenerateAutoStartupInfo [PathToPackageInfo?] [OutputPath?] — Generates AutoStartServiceConfig files from a PackageInfo.json. Used in CI/CD pipelines to produce startup configuration without running the full toolkit.

Spark Integration:

--CreateSparkCredentialFile [Url] [Login] [Password] [PathToOutputFile] — Creates a Spark credential JSON file for use in automated upload/download workflows. Intended for use with secrets / environment variables in CI pipelines — prevents the need to check in credentials.

Security and Device Management (Desktop):

--LockDevice [TargetConnectionInfoFile] [Description] — Locks a display with an SSH key, disabling root password logins.
--LockAppInstaller [TargetConnectionInfoFile] [PrivateKeyFile] — Locks the application installer with a private signing key, requiring all loaded applications to be signed.

Bulk Provisioning:

--PreProvisonDisplays [DeviceInfoFile] [SparkConnectionInfoFile] [ProvisioningFile] — Sets up a batch of displays to acquire licenses automatically on their first Spark connection. Designed for factory / pre-provisioning workflows.

More Control for Application Startup – Services run in a separate Linux systemd service called Ahsoka.ServiceManager. The Service Manager tab configures which services autostart, their order, which can start in parallel, and whether services are available locally only or also remotely. Services must be configured on the Service Manager tab — they do not auto-start from the C# dispatcher.

Startup Orchestration (AutoStartServices.bin) – Run Add SDK any time services or extensions change. This generates AutoStartServices.bin, a startup orchestration file used by both C++ and C# applications to start services earlier and in parallel, improving startup time by 1–1.5 seconds compared to direct application startup. C# apps on the desktop receive this file in their bin folder automatically during build or publish.

StartLocalRuntime – A new StartLocalRuntime() call (C#) / AhsokaRuntime::StartLocalRuntime() (C++) must be added to the beginning of application startup. On the desktop this starts the runtime services directly; on the target it defers to Ahsoka.ServiceManager.

Non-Blocking Client Startup – Client Start() calls return immediately. Clients wait up to 10 seconds for their service to become available on the first call. This timeout is configurable via properties on the client.

Separate UX Service – If your application architecture separates the UX and Business Logic process, the UX Process can now be started independently (earlier) than the main application. This enables customers to run advanced scenarios such as a WebBrowser UX with a Container Based Application running in separate processes. In addition, this optimizes the startup such that the UX dependencies don't prevent the main application from starting when not necessary.

Migration to Podman – For those using containers, the tool now has compatibility for using Podman instead of Docker Desktop. Enabled by default, Podman brings many advantages to users including a truly open-source platform (no logins required, no fees). Podman also runs without a service on all platforms allowing you to start, stop, and manage your containers without a bulky service running.

Container App Deployments – Customers can now specify that OpenPV deploy a container instance instead of a folder when packaging their application. This allows customers to create and manage containers that are platform independent but can be deployed to the target. When packaging, OpenPV will capture the container image, deploy it to the target, and set up the launch.

Optional BSP Add-Ons – For new BSP builds (starting with Pro), many BSP features are no longer deployed to the factory image. Features such as a WebBrowser, QT Support, and others are now standalone packages you can optionally include in an application package (.opv).

Library Feeds – Extensions no longer must be registered with the OpenPV Core application. Instead, metadata embedded in the NuGet package is used to find and install OpenPV packages. Library feeds can be configured per-project and per-package directly in the toolkit via Build tab → Library Feeds and are used automatically across all C# build paths. For local desktop testing, also add the feed to Visual Studio directly.

Enhanced Layer Manager Support (Pro) – Layer Manager now supports multiple screens as well as both static and video (mp4) startup logos, with support for stretching and scaling applications to fill the screen.

FastBoot (Pro) – A new Fast Boot prep process for Pro hardware replaces most systemd services with a minimal, carefully orchestrated startup sequence, targeting boot-to-logo in approximately 3 seconds and boot-to-working-application in approximately 4–5 seconds.

Browser Service – A new BrowserService allows HTML5 applications to programmatically control the built-in browser, including navigate, reload, forward, and back.

Device Security – Displays can be locked via SSH key (disabling root password logins) and the application installer can be locked with a signing key, requiring all loaded applications to be signed. See --LockDevice and --LockAppInstaller in Ahsoka.CommandLine.

New / Changed Extensions in 5.0

All extensions have been reworked in OpenPV 5 to support the new IExtensionRegistrar pattern and Native AOT compilation. Extensions now register their services, message types, code generators, and JSON serialization contexts through the registrar rather than via reflection, allowing applications built with the Native build mode to include extensions without any runtime reflection overhead.

Bluetooth Extension – Reworked with full Native AOT support. The D-Bus layer has been migrated to Tmds.DBus.Protocol (explicitly reflection-free) enabling AOT-safe BLE and Bluetooth Classic operation. Includes improved demos. Provides: BluetoothService (BR/EDR — adapter management, pairing, A2DP/AVRCP, HFP, SPP, PBAP, MAP, OBEX) and BLEService (BLE GATT server, advertisement management, pairing agent).

Control Extension – The CAN Services and IO Services extensions have been combined into the new Control Extension. Provides: CanService (J1939, NMEA 2000, and Raw CAN protocols across SocketCAN, STM32 coprocessor, and ECOM adapters), IOService (analog and digital I/O across RCD, CA90, and ST coprocessor platforms), and CanLocationServicePlugin (GPS/NMEA data via CAN). Includes new CLI commands: --GenerateCANClasses, --GenerateIOClasses, --GenerateCalibrationFromDBC, and --TestIO.

Audio Extension – Reworked with Native AOT support. Provides: AudioManagerService (multi-source audio routing, volume, and ducking via PulseAudio), A2BService (A2B digital audio bus network management with amplifier plugin support), and TunerService (FM/AM tuner control). Includes a Roslyn source generator for code generation support.

Storyboard Extension – Provides Crank Storyboard GUI framework integration with code generation (--GenerateStoryboardClasses) and SDK scaffolding (--AddStoryboardSDK). Reworked with Native AOT support.

Video Player Extension – Provides VideoService for managing multiple video player instances with support for file playback and live camera streams (USB, CSI, GMSL) via GStreamer, including an out-of-process native C player for process isolation.

BSP Updates and Compatibility

⚠️ Breaking Change — OpenPV 5.x requires a new BSP for OpenView Select displays. Applications built with OpenPV 5.x are not compatible with displays running an older BSP, and applications built with older versions of OpenPV cannot be installed on displays running the OpenPV 5.x BSP. Before upgrading, all displays in a deployment must be flashed with the new BSP.

OpenView Select BSP – A new BSP is required for OpenPV 5.x. This BSP is not backwards compatible with OpenPV 4.x applications, and OpenPV 4.x packages cannot be installed on displays running this BSP. Flash the new BSP using the Flash Tool available in Plugins before deploying OpenPV 5.x applications.

OpenView Pro BSP – Continued work on the Pro BSP with support for independent packages for Browser (Chrome), QT, and other optional components.

Developer Toolkit Changes

The following are changes which impact the Developer Toolkit in OpenPV 5.0.

Packaging Tab – Launch Commands are now located on the Build tab.

Build Tab (formerly the Development tab) – Renamed to better reflect its purpose. Added the ability to select "Container" as a deployment method with new container configuration options. Customers can now pass custom arguments to their launch executables allowing more complex startup scenarios. Optional BSP components can be added to the application package including Containers (Podman), an improved Chromium-based Browser, and QT Support.

The Build tab introduces separate build mode selectors for both the Application and the Service Manager, giving you fine-grained control over how each is compiled:

PreBuilt (Application only) – Skips the publish step entirely. The Application Output folder must already contain the published files. Use this when you are building outside of OpenPV.
Standard – A standard framework-dependent publish with no trimming. Fastest to build and easiest to debug.
Optimized – An IL-trimmed publish. Reduces package size and improves startup time at the cost of a longer build. For the Service Manager, this generates a trimmed build that includes your extensions and requires the Dotnet SDK.
Native – AOT (Ahead-of-Time) native compilation via Docker / Podman. Produces a fully native binary with no .NET runtime dependency on the target. The Installer UI and Service Manager are themselves compiled native, targeting ~3–4s to Installer UI and ~1–2s Service Manager launch. Podman or Docker is required on all C# developer machines — all C# compiles run inside the SDK container regardless of build mode. C++ developers no longer need the .NET SDK installed locally.

Display Tab – The Display tab now allows you to configure multiple screens (Primary / Secondary) as well as specify the resolutions for external displays. You can now pick both static (PNG, JPG) or video (MP4) startup logos for each screen.

Hardware Tab – No changes to this User Interface.

Service Manager Tab – Added configuration options for startup order, new auto-start options, and start delays for managing services started in the Ahsoka Service Manager.

API and SDK Changes

LightProto – C# applications use LightProto for protobuf serialization instead of protobuf-net. LightProto uses source generation rather than reflection, improving startup time and enabling Native AOT support.

Toolkit Service and Device Service – The former SystemService has been split into two services. The Toolkit Service handles toolkit communication such as loading applications and provisioning displays, and should be configured to start last in your startup order. The Device Service handles device operations such as SetBrightness and GetHardwareInfo — replace any SystemService calls with DeviceService, as the method signatures are the same.

Thread Pool Defaults – The default thread pool size on ARM/ARM64 targets is 16 threads, preventing pool starvation pauses during startup. This is applied automatically by StartLocalServiceManager or can be set directly in your application.

Extension Identifiers – The NuGet package name is now the canonical identifier for extensions everywhere in the platform, preventing name collisions between extensions from different sources.

Breaking changes from OpenPV 4: