Since “running out of the box” is a strong statement, let us try to build this box such that we have a baseline to give you quality feedback on this beta driver.
I would appreciate very much in case you (NVIDIA) be so kind to confim the following steps and open questions we have as a community, and I will try to keep this thread as clean as possible considering your feedback, updating the steps accordingly.
#1) First, let us assume we have an Arch-based distro and we have a supported NVIDIA card.
GBM API support for a single NVIDIA card: (Yes / No);
GBM API support for hybrid setups (NVIDIA + intel). Here, I mean just GBM API, nvidia only, no prime-offload: (Yes / Partial / No)
GBM API support for hybrid setups (NVIDIA + intel) with prime-offload: (Yes / Partial / No (for 470, not sure for 495)
#2) Install 495 KMS driver using TKG’s Frogging-Family/nvidia-all PKBUILD. Here, I chose Tkg’s installer so we could have a Arch-agnostic installer.
- Can you confirm that TKG’s installer works in your test environment and does what you expect from your new GBM shared libraries? (cf. commits 9404b959dce5152da15afb5b9cda4907c3492e8d and ef12a70f293cb23b35205503eab4de63af52305d ) (Yes / No)
#3) Install libxcb-git from AUR;
#4) Install mesa-git from AUR;
#6) Install egl-wayland-git from AUR (egl-wayland-git depends on libglvnd-git) to work);
- Build Xwayland with eglstreams? (Yes / No)
#8) Install libdrm-git from AUR;
#9) change /etc/mkinitcpio.conf such that we have nvidia drivers available as soon as possible:
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
Does the order matters here? For example, in case one has an optimus device, should one add i915 before or after the NVIDIA drivers?
Update initramfs with
sudo mkinitcpio -P
#10) Change /etc/default/grub and add
rd.driver.blacklist=nouveau nvidia-drm.modeset=1 to GRUB_CMDLINE_LINUX_DEFAULT
Blocking nouveau and adding
nvidia-drm.modeset=1as a redundancy fallback to ensure we’ve enabled modesetting.
grub-mkconfig -o /boot/grub/grub.cfg
#11) Steps 1-10 should be enough to satisfy all dependencies we have for 495 GBM API right? (Yes / No)
Here, I am assuming one knows how to setup and configure sway (it might be a strong assumption, since it was not an option before, but anyway…).
sway now identifies that we are trying to run it with NVIDIA’s proprietary driver and tries to avoid it. So, one workaround is :
In case one has a login manager (like SDDM or GDM), modify
/usr/share/wayland-sessions/sway.desktopsuch that one ends up with
In case lunching from TTY, use
#13) Run sway and test
nvidia-smi, check whether
sway is there
#14) Install vulkan-tools
vkcubeand check whether one has a spinning cube, and vulkan renderer selected NVIDIA.
With all that said and done, steps 1-14 should provide a functional sway setup with the 495 driver on Arch-based distros with hardware acceleration.
Some open questions remain though, for instance, on Wayland/XWayland, do we have support for the following? If so, what is the recommended setup?
Coolbits (Yes / No)
TripleBuffer (Yes / No)
Sync to VBlank (Yes / No)
Flipping (Yes / No)
GSync (Yes / No)
Runtime D3 (RTD3) Power Management (All / Fine / Coarse / None)
Another thing is the external monitor issue. Since 470 drivers, we have numerous reports here in this forum showing that external monitors do not work on Wayland, and it remains on 495 (cf. sway issue ticket , I can confirm this issue)
Can you acknowledge this issue? At least give us a internal bug report ID. I can give you my bug report files, in a separated thread, since I am trying to keep this one as clean as possible.