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 |
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 |
|---|---|---|---|
|
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
Remove every call to
wfdDeviceSetSafeStateNV()and any dynamic dispatch throughPFNWFDDEVICESETSAFESTATENV. 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.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.Remove every call to
wfdReadPixelsFromSourceQNX()and any dynamic dispatch throughPFNWFDREADPIXELSFROMSOURCEQNX. 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.