NVIDIA 364.19 Linux Driver Stabilizes The Wayland & Mir Support

[duby229]

That's a tedious discussion. Unfortunately Google does not publish OS stats anymore so the exact numbers will remain a mystery.

Well that remains to be seen.

One of the best things nVidia ever did for themselves and for open source was vdpau. It was a fantastic idea that worked out beautifully. If they don't like GBM, then they need to provide an open source alternative that the open source drivers can use. It's the only possible way the open source community would cooperate.

EDIT, It may be too late for that, vdpau was released at exactly the right time when important OSS drivers were about to implement video decode. In this circumstance it's probably too late. Unfortunately

[blackout23]

If they don't like GBM, then they need to provide an open source alternative that the open source drivers can use. It's the only possible way the open source community would cooperate.

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

[pinguinpc]

In my case this drivers stay working good

For now test saint row the third and works stable in large test

[blackout23]

If they don't like GBM, then they need to provide an open source alternative that the open source drivers can use. It's the only possible way the open source community would cooperate.

Well guess what they did? EGLDevice and EGLStreams are open Khronos specifications that everyone could implement TODAY if they want.

[Temar]

One of the best things nVidia ever did for themselves and for open source was vdpau. It was a fantastic idea that worked out beautifully. If they don't like GBM, then they need to provide an open source alternative that the open source drivers can use. It's the only possible way the open source community would cooperate.

EDIT, It may be too late for that, vdpau was released at exactly the right time when important OSS drivers were about to implement video decode. In this circumstance it's probably too late. Unfortunately

I agree, it is far too late for that. So either GBM offers a plugin architecture which can be used by proprietary drivers or Nvidia will end up shipping their own libgbm and we have the libGL mess again. Of course the EGL standard could always be extended and Wayland could then implement support for these drivers as a second codepath to support proprietary drivers. But they won't do it and Nvidia won't open their drivers, so we have the same mess again, because people can't get their act together.

[duby229]

I agree, it is far too late for that. So either GBM offers a plugin architecture which can be used by proprietary drivers or Nvidia will end up shipping their own libgbm and we have the libGL mess again. Of course the EGL standard could always be extended and Wayland could then implement support for these drivers as a second codepath to support proprietary drivers. But they won't do it and Nvidia won't open their drivers, so we have the same mess again, because people can't get their act together.

You say people but it was nvidia that didn't get their act together.

[anda_skoa]

As Linus Torvalds said in the famous video, Nvidia is mainly focused on the embedded market when it comes to Linux.

That may very likely be the case, but Wayland is already the technology of choice there is an embedded device needs support for multiple windows or even multiple applications.
So the question will be, if embedded stacks like Qt will add these Nvidia specific code paths to their compositors.

Cheers,
_

[Temar]

You say people but it was nvidia that didn't get their act together.

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.

[Pecisk]

That may very likely be the case, but Wayland is already the technology of choice there is an embedded device needs support for multiple windows or even multiple applications.
So the question will be, if embedded stacks like Qt will add these Nvidia specific code paths to their compositors.

Cheers,
_

Yes, they will. End of discussion.

[Gusar]

What? It's not a practical matter, technically you can't run a wayland compositor on these drivers. It most certainly is a technical issue. Practically you could write a wayland compositor that works, but technically it doesn't exist yet.

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.