Aaron Plattner one of the main developers of the NVIDIA drivers, made it known by posting the status of Wayland protocol support in the test branch of the R515 controller, for which NVIDIA provided the source code for all kernel-level components.
It should be noted that in several areas, Wayland protocol support in NVIDIA driver has not yet reached parity with X11 compatibility. At the same time, the lag is due to both NVIDIA driver issues and general limitations of the Wayland protocol and composite servers based on it.
There are several areas where the NVIDIA R515 driver lacks feature parity between X11 and Wayland. This may be due to limitations of the driver itself, the Wayland protocol, or the specific Wayland composer in use. Over time, this list is expected to become shorter as missing functionality is implemented in both the driver and upstream components, but the following captures the situation as of the release of this version of the driver. Note that this list assumes a compositor with reasonably full support for graphics-related Wayland protocol extensions.
Within limitations that exist the following are still mentioned:
- Library libvdpau, which enables hardware acceleration mechanisms for video post-processing, compositing, display and decoding, lacks built-in support for Wayland. The library cannot be used with Xwayland either.
- Wayland and Xwayland are not supported by the NvFBC library (NVIDIA FrameBuffer Capture) used for screen capture.
- The nvidia-drm module does not report variable refresh rate features like G-Sync, which prevents them from being used in Wayland-based environments.
- In Wayland-based environments, output to virtual reality screens, eg compatible with SteamVR platform, not available due to the inoperability of the DRM Lease mechanism, which provides the necessary DRM resources to form a stereo image with different buffers.
- Xwayland does not support the EGL_EXT_platform_x11 extension.
- The nvidia-drm module does not support the GAMMA_LUT, DEGAMMA_LUT, CTM, COLOR_ENCODING, and COLOR_RANGE properties, which are required for full color correction support in composite managers.
- When using Wayland, the functionality of the nvidia setup utility is limited.
- With Xwayland on GLX, drawing the output buffer to the screen (front buffer) does not work with double buffering.
While on the part of the limitations of the Wayland protocol and composite servers:
- The functions like stereo out, SLI, Multi-GPU Mosaic, Frame Lock, Genlock, Swap groups and advanced display modes (warp, blend, pixel shift, and YUV420 emulation) are not supported on Wayland protocol or composite servers. Apparently, to implement such functionality, it will be necessary to create new EGL extensions.
- There is no commonly accepted API that allows Wayland composite servers to turn off video memory via PCI-Express Runtime D3 (RTD3).
- Xwayland lacks of a mechanism that can be used in the NVIDIA driver to synchronize application rendering and screen output. Without such synchronization, under some circumstances, the appearance of visual distortions is not excluded.
- The Wayland Composite Servers do not support display multiplexers (mux) used in laptops with dual GPUs (integrated and discrete) to directly connect a discrete GPU to an integrated or external display. In X11, the display "mux" can automatically switch when a full-screen app exits through the discrete GPU.
- Indirect rendering via GLX does not work in Xwayland, as GLAMOR's 2D acceleration architecture implementation is not compatible with NVIDIA's EGL implementation.
- Hardware overlays are not supported by GLX applications running in Xwayland-based environments.
Finally if you are interested in knowing more about it, you can check the details in the following link