NvDisplay Changes#

Production Profiles#

Target Changes

Backward Compatible

Platform

OS

For 7.0.2.0 Production profiles, the display mode timings are set when the driver loads based on the timings in the Device Tree (see the “Display Serializer” page in the NvDisplay SDK docs). Changing the mode timings dynamically is not supported. Client-initiated modeset requests returns success only if the requested mode timings match the mode already set by the driver and will return failure otherwise.

No.

Note: Prior code that relies on dynamic modeset will not work, unless the mode being set matches the mode specified in the device tree and set by the driver during init.

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

The new display driver implementation is designed to accommodate multiple guest virtual machines. The setting of the display mode is an operation that affects other virtual machines, so no guest VM should be able to control it. Instead, the client specifies the mode in the device tree and the driver sets the mode during initialization.

Steps to Migrate

Change: For 7.0.2.0 Production profiles, the display mode timings are set when the driver loads based on the timings in the Device Tree (see the “Display Serializer” topic in the NvDisplay SDK documentation). Changing the mode timings dynamically is not supported. Client-initiated modeset requests will return success only if the requested mode timings match the mode that was already set by the driver, and returns failure otherwise. Relevant WFD API: Clients dynamically set the display mode timings via wfdSetPortMode (section 4.4.4 of the OpenWFD specification). Since dynamic mode changes are not supported, this function fails unless the mode timings requested match the mode timings already set by the driver during driver initialization. Clients should know what their desired mode is and set it in the Device Tree instead of dynamically in their client code.

NvDisplay Queues#

Target Changes

Backward Compatible

Platform

OS

For release 7.2.5.0, NvDisplay uses two ivc queues per VM. The IVC Queue number assignment is taken from Device Tree and PCT.

No.

Note: The board will not boot using an old device tree or PCT.

NSR, SR

Linux, QNX, and Android

Migration Path

  • Thor to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.3.0 to 7.2.5.0

Migration Rationale

NvDisplay added support for Type-C display. To support plug-unplug features of this display, NvDisplay needs to send asynchronous notifications from DisplayServer to Display Driver running in VM. This occurs with a new IVC Queue channel per VM to send asynchronous notifications.

Steps to Migrate

Clients using release 7.2.5.0 should use the new device tree and PCT configuration supplied with the release. NvDisplay software expects two IVC Queue information to be preset in the device tree and PCT. Without this information, the board will fail to boot.

DisplayServer PCT Updates for Core Elimination#

Target Changes

Backward Compatible

Platform

OS

For release 7.2.6.0, the display_server_config structure in PCT is updated to support DisplayServer core-elimination. The changes expose multi-threaded server properties and add debug-thread properties consumed by DisplayServer at boot. Debug thread properties are expected to be customer configurable.

No

NSR, SR

Linux and QNX

Migration Path

  • Thor to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.5.0 to 7.2.6.0

Migration Rationale

The DisplayServer core-elimination feature requires DisplayServer to consume per-thread and debug-thread configuration directly from PCT. Without these PCT additions, DisplayServer cannot pick up the configuration required to operate under core-elimination.

Steps to Migrate

If using release 7.2.6.0, use the updated display_server_config PCT struct and configuration supplied with the release. You can choose to update the debug-thread properties as per your performance requirements.

NvDisplay Runtime Feature Configuration#

Target Changes

Backward Compatible

Platform

OS

For release 7.2.6.0, NvDisplay DisplayServer ships as a single shared binary across AV and Cockpit deployments. Per-deployment feature enablement is now driven by internal Device Tree and PCT entries managed by the display team.

No.

Note: If customers continue to use old PCT/DT files against the new DisplayServer, the new feature flags will not be present and the corresponding display features (for example, hotplug events) will default to disabled — silently becoming unavailable at runtime.

NSR, SR

Linux and QNX

Migration Path

  • Thor to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.5.0 to 7.2.6.0

Migration Rationale

NvDisplay DisplayServer moved to a single shared binary across AV and Cockpit deployments. These deployments require different feature sets (for example, AV does not enable display hotplug events while Cockpit does). Without runtime gating, NVIDIA would maintain N parallel binaries per SoC × per deployment, which does not scale.

Steps to Migrate

Clients using release 7.2.6.0 should use the new Device Tree and PCT configuration supplied with the release. The properties involved are internal and managed by the display team; no per-property edits by customers are expected. Using old PCT/DT files against the new DisplayServer will silently disable the affected display features.

WF/wfdext.h NV and QNX-Specific Symbols Removed#

Target Changes

Backward Compatible

Platform

OS

  • The wfdDeviceSetSafeStateNV() entry point and its function-pointer typedef PFNWFDDEVICESETSAFESTATENV have been removed from WF/wfdext.h. The prototype (previously gated by WFD_WFDEXT_PROTOTYPES) and the typedef are no longer declared.

  • The WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX macro (previously defined as 0x7731) is removed from WF/wfdext.h.

  • The wfdReadPixelsFromSourceQNX() entry point and its function-pointer typedef PFNWFDREADPIXELSFROMSOURCEQNX are removed from WF/wfdext.h. The prototype (previously gated by WFD_WFDEXT_PROTOTYPES) and the typedef are no longer declared.

No. Source changes are required.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

The NV-vendor and QNX-specific WFD extension entry points (wfdDeviceSetSafeStateNV, wfdReadPixelsFromSourceQNX) and the WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX pipeline attribute are no longer part of the public WFD extension surface on QNX safety builds. Safe-state transitions are now driven by the standard WFD device lifecycle / commit path, and pixel readback / post-fence scanout flows move to the supported NvSciSync / NvSciBuf / NvMedia paths.

Steps to Migrate

  1. Remove every call to wfdDeviceSetSafeStateNV() and any dynamic dispatch through PFNWFDDEVICESETSAFESTATENV. Rely on the standard WFD device lifecycle / commit path to drive safe-state transitions.

    Before:

    WFDErrorCode err = wfdDeviceSetSafeStateNV(device);
    

    After:

    // no replacement; remove the call and rely on the standard WFD
    // device lifecycle / commit path to drive safe-state transitions.
    

    Compile-time signal of this break: implicit declaration of function 'wfdDeviceSetSafeStateNV' / 'PFNWFDDEVICESETSAFESTATENV' undeclared.

  2. Remove every reference to WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX (for example, when querying or setting pipeline post-fence scanout-begin attributes).

    Before:

    wfdSetPipelineAttribiv(device, pipeline,
                           WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX,
                           value);
    

    After:

    // no replacement; remove references to
    // WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX. Use the supported
    // pipeline post-fence APIs (NvSciSync-based) instead.
    

    Compile-time signal of this break: 'WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX' undeclared.

  3. Remove every call to wfdReadPixelsFromSourceQNX() and any dynamic dispatch through PFNWFDREADPIXELSFROMSOURCEQNX. Perform pixel readback through the supported NvSciBuf / NvMedia readback paths instead.

    Before:

    WFDErrorCode err = wfdReadPixelsFromSourceQNX(device, source,
                                                 x, y, width, height,
                                                 format, data);
    

    After:

    // no replacement in WF/wfdext.h; perform pixel readback through
    // the supported NvSciBuf / NvMedia readback paths instead.
    

    Compile-time signal of this break: implicit declaration of function 'wfdReadPixelsFromSourceQNX' / 'PFNWFDREADPIXELSFROMSOURCEQNX' undeclared.