NVIDIA 364.19 Linux Driver Stabilizes The Wayland & Mir Support

[pal666]

You really don't know what's PID 1 in RHEL 6, do you?

well, you really don't know what is arrow of time

[SaucyJack]

Well that is where my point of view differs. It was the Wayland guys who decided to design their architecture in a way that it can't be used by proprietary drivers. They had the vain hope they could force Nvidia into opening up their drivers. But that is not a pragmatic approach if you only got such a low market share.

Well, we will see what the future might bring. I have to leave now, was nice talking to you.

Wow guy. You're either an epic level idi*t, or you walk around with a neon sign above your head that says "I am a Nvidia shill".

[Pecisk]

Pal666, just for you - just trolling in answers doesn't make you right. Nvidia support will be implemented in many Wayland compositors, like it or not. You might feel angry about it, you might feel devastated - no one really cares. Open source is based on practical usage of code and improvements, not on religious beliefs.

[Timeus]

I'm going to buy next generation graphics card for my desktop. I will definitely buy AMD GPU if wayland won't work on Nvidia's binary driver.

[computerquip]

Pal666, just for you - just trolling in answers doesn't make you right. Nvidia support will be implemented in many Wayland compositors, like it or not. You might feel angry about it, you might feel devastated - no one really cares. Open source is based on practical usage of code and improvements, not on religious beliefs.

The only people implementing support would be nvidia. I doubt any serious maintainer would mainline that support as well. Not that there's anything wrong with that actually... people would probably still used the forked compositors.

That said, the problem nvidia had with using the current solution was they didn't understand how to fit the current solution into their hardware (in a proprietary way). As far as I understand, there is work being made to figure that out or to extend GBM in order to do so. There's also nothing preventing nvidia from contributing patches that add the extended functionality needed to support their hardware themselves. Until then, you can use an AMD or Intel GPU to use Wayland now.

[gilboa]

The only people implementing support would be nvidia. I doubt any serious maintainer would mainline that support as well. Not that there's anything wrong with that actually... people would probably still used the forked compositors.

That said, the problem nvidia had with using the current solution was they didn't understand how to fit the current solution into their hardware (in a proprietary way). As far as I understand, there is work being made to figure that out or to extend GBM in order to do so. There's also nothing preventing nvidia from contributing patches that add the extended functionality needed to support their hardware themselves. Until then, you can use an AMD or Intel GPU to use Wayland now.

It remains to be seen. *If* kwin and mutter maintainers decide to implement EGLStreams, all other compositors will follow suit. If they'll stick to their guns, EGLStreams will die.

Either way, history seems to suggest that most distribution, Fedora included, are far more accepting than what you seem to believe. E.g. Fedora tries not to be break RPMFusion/nVidia unless they really, really have to. (I use Fedora w/ nVidia on ~20 workstations).

[duby229]

You mean like EGLDevice and EGLStreams, which is an open Khronos specification that everyone could implement today?

Then they should implement an OSS licensed reference. That's all I mean. They're the ones that want compositors to use it when those same already have something else implemented.

[duby229]

Apply the weston patches Nvidia wrote and voila, a wayland compositor on these drivers. So yes, you *can* technically run a wayland compositor on these drivers, the tech is there. That the tech is different from what compositors currently use does not suddenly make this tech not be there.

Ok, fine, but what about desktops people use? A gnome user perhaps? A KDE user maybe?

It's not practical for almost anyone to patch weston and then expect their preferred desktop to function. Technically it won't happen.

[hiryu]

I don't have the time to go through the thread with a fine tooth comb so take this with a grain of salt, but the discussion here seems to indicate that maybe the gbm route isn't entirely out of the question for Nvidia:

https://lists.freedesktop.org/archives/wayland-devel/2016-April/027835.html

That said, as long as there's no seperate code paths required for the Wayland clients themselves, it may not be too unreasonable for the compositors to have seperate code paths. Nvidia's EGL stream solution isn't actually vendor specific, even if only one vendor currently implements it. However, this is up to the devs on both sides to determine if this is the way to go.

My main problem with the 364 drivers, including with 364.19, is that I'm not able to enter in a password during boot for luks. I'm required to use encrypted partitions on my laptop for work, so this is a huge show stopper. I'm using the 364.x series on my 2 desktops without any issue though, but not yet 364.19 just yet.

Seems nvidia hasn't tested that scenario. I'm using an Ubuntu 15.10 flavor. Maybe it's just me or this version of the distro. Is anyone else able to enter a password at boot using the nvidia 364.x drivers? I may need to file a bug...

[hiryu]

I just made a post and it seems to have disappeared entirely, so lets try again.

Take this with a grain of salt as I haven't gone through the thread all that thoroughly, but this discussion seems to indicate that gbm wouldn't entirely be out of the question for Nvidia:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/866988-nvidia-364-19-linux-driver-stabilizes-the-wayland-mir-support/page8

Maintaining 2 seperate code paths, as long as it's not too much overhead and doesn't require separate code paths for the clients as well, doesn't seem too unreasonable here. While currently only implemented by one vendor, EGL streams isn't vendor specific and perhaps others may prefer this approach in the future. However, this is all up to the devs. I think ultimately, the right thing will be done here.

My main issue with the 364.x driver series is that it breaks the ability for me to enter a password at boot for luks. I am required to have encrypted partitions for work on my laptop, and thus the 364.x series is completely broken for me (I've tested all releases in the 364.x line including 364.19) so I'm stuck with 361.x for a while, at least on my laptop. The 364.x series has been working fine on my desktops where I'm not using luks.

Maybe it's just me. Has anyone else run into trouble with password prompts at boot with the 364.x drivers? Maybe it's my distro and version (an Ubuntu 15.10 flavor).