This is not the case, see this: Current graphics driver releases - Linux - NVIDIA Developer Forums
R470 is supported on Linux, just as well as on Windows.
Also for the record, usually NVIDIA support is longer on Linux than on Windows. If you look at Fermi, on Windows only specific Quadro Fermi GPUs are supported with security updates, but on Linux all Fermi GPUs are supported.
Weird thing is I don’t have any dbus spam,maybe is not affecting to optimus laptops. (running 495 beta)
Hmm, that is not good. Maybe we should skip 495.44 for now and keep 470.xx? Wonder also about the Gsync fix not mentioned there …
I pushed 495.44 drivers to unstable without pre-compiled extramodules. Users might need to install nvidia-dkms package after removing any linuxXXX-nvidia package before. Pre-compiled packages may come later this week.
EDIT: Dont forget to run sudo mkinitcpio -P after. 
Hmm, maybe we should go then for that release series and wait a little longer for 495 and beyond. Let’s see.
Anyway, I think discarding 470 drivers when 495/latest drivers are pushed to Stable would be a mistake. That would mean people should use the 390 drivers, which are not really good at all, or not compatible at all with some currently working software (rendering, encoding, gaming, things important for users with Nvidia cards, most of the time).
I really think creating an additional video-nvidia-470xx driver for MHWD, when 495 hits Stable, would be a good move for all concerned people. It is not like recreating the nightmare when there was half a dozen drivers versions to maintain, it is keeping LTS drivers alive to keep proper support for all users.
At minimum Manjaro should provide a solution, like the DKMS package made for the 340 drivers, to not say 
to these concerned users.
PS: it is not even for me, I don’t care I don’t have old video card.
After removing linux514-nvidia and installing nvidia-dkms, the machine couldn’t boot my display manager. It got stuck before showing anything graphical except the useless short text about a filesystem scan, without telling me anything important about booting there. I had to manually switch to a TTY and look in the journal with journalctl -R and scroll down a few pages to find the error, which was an error about kernel module version mismatches. (I wish it would have just printed that error directly instead of requiring that.)
From my research about the error, I found that I had to type sudo mkinitcpio -P, wait for that to finish, then reboot again from a TTY (get there with Ctrl+Alt+F2) for booting to the display manager to succeed again. This short comment is to help anyone who had the same issue.
Edit: Phil’s updated this comment’s parent comment with this solution as well.
Currently we have this situation with Nvidia drivers:
:: Different overlay package(s) in repository community x86_64
-------------------------------------------------------------------------------
PACKAGE stable-staging unstable
-------------------------------------------------------------------------------
linux510-rt-nvidia 470.82.00-1 -
:: Different overlay package(s) in repository core x86_64
-------------------------------------------------------------------------------
PACKAGE stable-staging unstable
-------------------------------------------------------------------------------
mhwd-nvidia 470.82.00-1 495.44-1
:: Different overlay package(s) in repository extra x86_64
-------------------------------------------------------------------------------
PACKAGE stable-staging unstable
-------------------------------------------------------------------------------
gsettings-desktop-schemas 40.0-3 -
libxnvctrl 470.82.00-1 495.44-1
linux414-nvidia 470.82.00-1 -
linux419-nvidia 470.82.00-1 -
linux44-nvidia 470.82.00-1 -
linux49-nvidia 470.82.00-1 -
linux510-nvidia 470.82.00-1 -
linux513-nvidia 470.82.00-1 -
linux514-nvidia 470.82.00-1 -
linux515-nvidia 470.82.00-0.1 -
linux54-nvidia 470.82.00-1 -
nvidia-dkms 470.82.00-1 495.44-1
nvidia-utils 470.82.00-1 495.44-1
opencl-nvidia 470.82.00-1 495.44-1
:: Different sync package(s) in repository extra x86_64
-------------------------------------------------------------------------------
PACKAGE stable-staging unstable
-------------------------------------------------------------------------------
gsettings-desktop-schemas - 41.0-1
:: Different overlay package(s) in repository multilib x86_64
-------------------------------------------------------------------------------
PACKAGE stable-staging unstable
-------------------------------------------------------------------------------
lib32-nvidia-utils 470.82.00-1 495.44-1
lib32-opencl-nvidia 470.82.00-1 495.44-1
Yeah, I just hit this while trying to upgrade packages and removed my linux510 (had it as backup but never really needed ant it blocked upgrading to nvidia 495.44) but then ended up without linux514-nvidia installed. No biggie - was going to re-install that and bam - target not found…
So that’s a bit of a pickle…
Since the 495 driver has key Wayland support improvements, it would be good to have this available as a ‘normal’ kernel module on the unstable branch for those who want it.
Thanks to plilm and buju followed the info rebooted and on latest nvidia drivers.
core 174.4 KiB 167 KiB/s 00:01 [###################################################################] 100%
extra 1905.0 KiB 1790 KiB/s 00:01 [###################################################################] 100%
community 6.7 MiB 5.16 MiB/s 00:01 [###################################################################] 100%
multilib 177.1 KiB 873 KiB/s 00:00 [###################################################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing nvidia-utils (495.44-1) breaks dependency 'nvidia-utils=495.29.05' required by linux513-nvidia
:: installing nvidia-utils (495.44-1) breaks dependency 'nvidia-utils=495.29.05' required by linux514-nvidia
@oberon is current working on the extramodules for 495 driver series. We had some low staffing this week due to some vacations and other things going on. For sure the modules may be online in some hours …
Has anyone been able to get Plasma 5.23.2 desktop to be GPU accelerated with Nvidia in the Wayland session? Whenever I log in to Plasma Wayland with Nvidia 495.44 installed, Plasma renders with llvmpipe, X works as intended. Reverting to 47x fixes Wayland (uses my GTX 1060 instead of llvmpipe)
Tried different kernels, made sure my modesetting config was correct, checked package versions for stuff such as xwayland and egl-wayland, all up to date.
Usually I’m a patient soul; but this GBM support has me drooling, lol
Seems we’re waiting for an egl-wayland and Qt update for this to work properly, so for now we have to use EGLStreams for just a little bit longer. Solution in link.
Some urgent info for all “Unstablers”:
The latest series of updates will make your system unbootable if you’re using LVM and udev-based initramfs. Here is what I’m looking at right now:
Building image from preset: /etc/mkinitcpio.d/linux514.preset: 'default'
-> -k /boot/vmlinuz-5.14-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.14-x86_64.img
==> Starting build: 5.14.14-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [keyboard]
-> Running build hook: [consolefont]
-> Running build hook: [autodetect]
-> Running build hook: [plymouth]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [plymouth-tpm2-totp]
-> Running build hook: [tpm2]
-> Running build hook: [plymouth-encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
-> Running build hook: [lvm2]
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/install/lvm2: line 33: add_udev_rule: command not found
-> Running build hook: [resume]
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-5.14-x86_64.img
==> Image generation successful
This was udev-based initramfs.
Now let’s move to systemd-based:
==> Building image from preset: /etc/mkinitcpio.d/linux514.preset: 'systemd'
-> -k /boot/vmlinuz-5.14-x86_64 -c /etc/mkinitcpio.systemd.conf -g /boot/initramfs-5.14-x86_64-systemd.img
==> Starting build: 5.14.14-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [systemd]
-> Running build hook: [keyboard]
-> Running build hook: [sd-vconsole]
-> Running build hook: [autodetect]
-> Running build hook: [sd-plymouth]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [sd-plymouth-tpm2-totp]
-> Running build hook: [sd-encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-5.14-x86_64-systemd.img
==> Image generation successful
Seems OK with systemd hook. Will reboot now and see, but I already can tell that udev-based initramfs’ images I have now are slightly smaller than systemd-based ones, which is the opposite of what it used to be on my machine.
Hilariously both have “Image generation successful” report at the end 
PS: the last batch of updates I’m talking about contained these packages:
python-pexpect (4.8.0-3 -> 4.8.0-4)
python-ptyprocess (0.7.0-1 -> 0.7.0-2)
python-cachetools (4.2.3-1 -> 4.2.4-1)
openexr (3.1.2-1 -> 3.1.3-1)
lvm2 (2.03.13-1 -> 2.03.14-1)
cryptsetup (2.4.1-1 -> 2.4.1-3)
device-mapper (2.03.13-1 -> 2.03.14-1)
EDIT:
Yep, as expected, system is unbootable with udev initramfs, but works fine with systemd-based one.
There’s a command add_udev_rule in updated lvm2 hook, but /usr/lib/initcpio/functions has no such command:
$ pamac update
Preparing...
Synchronizing package databases...
Refreshing core.db...
Refreshing extra.db...
Refreshing community.db...
Refreshing chaotic-aur.db...
Resolving dependencies...
Checking inter-conflicts...
To upgrade (4):
device-mapper 2.03.14-1 (2.03.13-1) core 300.3 kB
cryptsetup 2.4.1-3 (2.4.1-1) core 601.7 kB
lvm2 2.03.14-1 (2.03.13-1) core 1.6 MB
openexr 3.1.3-1 (3.1.2-1) extra 1.2 MB
Total download size: 3.7 MB
Total installed size: 103.1 kB
Apply transaction ? [y/N] y
Download of openexr (3.1.3-1) started
Download of device-mapper (2.03.14-1) started
Download of device-mapper (2.03.14-1) finished
Download of cryptsetup (2.4.1-3) started
Download of openexr (3.1.3-1) finished
Download of cryptsetup (2.4.1-3) finished
Download of lvm2 (2.03.14-1) started
Download of lvm2 (2.03.14-1) finished
Checking keyring... [4/4]
Checking integrity... [4/4]
Loading packages files... [4/4]
Checking file conflicts... [4/4]
Checking available disk space... [4/4]
Upgrading device-mapper (2.03.13-1 -> 2.03.14-1)... [1/4]
Upgrading cryptsetup (2.4.1-1 -> 2.4.1-3)... [2/4]
Upgrading lvm2 (2.03.13-1 -> 2.03.14-1)... [3/4]
Upgrading openexr (3.1.2-1 -> 3.1.3-1)... [4/4]
Running post-transaction hooks...
Reloading system manager configuration... [1/5]
Reloading device manager configuration... [2/5]
Arming ConditionNeedsUpdate... [3/5]
Updating linux initcpios... [4/5]
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'default'
-> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64.img
==> Starting build: 5.15.0-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.15-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'fallback'
-> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64-fallback.img -S autodetect
==> Starting build: 5.15.0-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
-> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.15-x86_64-fallback.img
==> Image generation successful
Refreshing PackageKit... [5/5]
A restart is required for the changes to take effect.
Transaction successfully finished.
$