Fedora 36 Planning to Run Wayland by Default with Nvidia's Proprietary Driver
phoronix.com
phoronix.com
The actual change proposal is: https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVI...
Discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fe...
I aint touching that with a 10 foot pole anytime soon.
How do you know this (that it was wayland)? I have never had a lockup caused by anything other than swapping, across multiple machines with Intel graphics.
Manjaro, clean install on my Intel laptop. Login with wayland, freezes for up to a minute at a time, sometimes it locks up completely.
Reboot and login with Xorg. Flawless.
Manjaro, clean install on my AMD laptop. Login with wayland. Flawless.
Intel tends to break randomly its Linux driver for some of its gpus, it's quite annoying.
I'll happily blame Intel as well, but the point is: I only see this problem with Wayland, sticking to Xorg and it's smooth sailing.
On firefox it works out of the box. On Slack as well.
On chromium it's still hidden behind the flag: chrome://flags/#enable-webrtc-pipewire-capturer
On Zoom it's more complicated. For whatever reason it uses gnome's private screenshot API to share screen Now that Gnome secured this API, it's not working at all, even for Gnome users... The web version allows to share the screen, but their web version is really not great.
Can you not do that with XWayland? Genuinely curious. I've never used/needed remote X, so I am not up to date with the capabilities.
There are remote Wayland options, though. I think Waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe) is one?
I used to run the XOrg-accelerated stuff as it was faster and used less power on my laptop, but once my machine got new enough for SNA it became too buggy vs. modesetting.
https://support.zoom.us/hc/en-us/articles/201362153-Sharing-...
Linux sessions utilizing Wayland can only share an entire desktop or whiteboard. In order to share just a specific application, you will need to launch your Linux session with Xorg instead.
The Zoom application needs to be adapted to work through the Wayland screencast portal interface to get things working properly (including sharing audio!). I've tried to report this to Zoom, but I'm not enough for them to realize it's a problem...
* https://twitter.com/Det_Conan_Kudo/status/135988702055492403...
* https://twitter.com/Det_Conan_Kudo/status/140481481290384589...
* https://twitter.com/Det_Conan_Kudo/status/144619684654890189...
If you (or anyone else here reading this) is a Zoom customer, please file support tickets asking for this to be fixed. I gave them all the technical details on how to fix this at the beginning of this year, so they know what they need to do.
I wont touch any nvidia nor x.org with a 10ft pole anymore.
Are you a Fedora dev? Do you have an impression that NVIDIA is getting to be a bit more cooperative with the desktop Linux development community these days, like with the changes related to GBM that made this decision possible for Fedora?
While this Change currently describes the effort for GNOME, KDE Plasma is likely to also be ready for Fedora Linux 36 for this. There a couple of other blockers to deal with, but hopefully those are squared away in time...
I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware.
I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well.
For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.
Tegra drivers (incl Xavier) already had GBM since years, with the nvgpu driver stack.
Doesn't mean you don't need to explicitly spell it out in Orin requirements though :-)
Thanks Eike
Also, it’s not defaulting to installing the driver anyways - as described in the article and its sources, what Fedora is actually planning to do is to change GDM’s udev rules to select the Wayland session by default if the proprietary drivers are running.
Also I'd be skeptical to some extend on this. Maybe back in time when a chip fail ratio was lower was a case. But now, there is a quite measurable amount of chips not passing requirements for a high tier cards, but can be used in the lower models (with limited amount of cores etc or worse thermal efficiency).
"A developer driver inadvertently included code used for internal development which removes the hash rate limiter on RTX 3060 in some configurations," the company said in a statement. "The driver has been removed."[1]
So it's hard to tell when it's binning, and when it's hobbling.
[1] https://www.theverge.com/2021/3/16/22333544/nvidia-rtx-3060-...
“It’s not just a driver thing,” said Bryan Del Rizzo, Nvidia’s head of communications, last month. “There is a secure handshake between the driver, the RTX 3060 silicon, and the BIOS (firmware) that prevents removal of the hash rate limiter.”
I feel a lot of this comes down to them using closed source software that they either don't have the code to, or aren't privileged to distribute. Libraries are a common spot for this to appear
Kepler could literally have all its cores enabled with a simple bridge on one laser cut. That's fun but very hit or miss, the more cores are disabled the higher the likelihood they're actually defective so it was binned lower.
Maxwell can have their Hwid modded but performance will be lower than actual Quadros.
Newer cards have an even bigger performance difference, more hardware differences I think.
Of course, I'd hate that in normal times, but if they now made me an offer to "upgrade" my 1060 (to moderately higher performance, but still lower end), I'd probably take it.
AFAIK there’re only 4 differences between GeForce and Tesla/Grid: more and faster VRAM, more FP64 GFlops on most GPUs, unlimited count of nvenc encoding streams versus 2 on GeForce, and support for virtualization. Only the first two are hardware differences, the other 2 are software.
Another thing about virtualization, it sounds ridiculous but nVidia charges non-trivial per-user fee to allow people to use the hardware they already own. Specifically, for virtual workstation they want $450 per concurrent user. That’s on top of the $3000-$12000 purchase price of these GPUs.
IBM does that with mainframes, but, at least, it’s hardware they own that they shipped in the box for you to rent out when needed or to buy and enable.
Of course, distributing a "cracked" driver would breach licensing agreements and violate copyright (and possibly other laws), so it's out of the question for any kind of professional use. However, if Nvidia uses it to differentiate services, wouldn't there be a significant risk of private consumers (gamers, hobbyists, etc) using such a driver to "upgrade" their cards for personal use?
The firmware itself truly is signed and so on
Another big deal is there’s no hardware video decode support in Firefox. I don’t have integrated graphics, so I rely on Nvidia’s VDPAU implementation that doesn’t work on Wayland. This really stinks!
I’m really on the fence about it and I keep thinking of switching back to Xorg.
NVIDIA’s VDPAU successor seems to be Vulkan Video. So those issues are going away at some point in the future at least.
No sure it works on wayland though, not tested it there.
[1] https://wiki.archlinux.org/title/NVIDIA_Optimus#Use_Intel_gr...