NVIDIA Presents Its Driver Plans To Support Mir/Wayland & KMS On Linux

[TheBlackCat]

What's there for you not to fathom? The bulk of serious bugs and complex problems are drivers, X.org and toolkit related. Moving to waylaid will not solve anything because then they'd be dependent on upstream to fix errors, make sure they follow guidelines, implement new stuff, etc. It's going to be the same mess like it's with X. Having their own compositor, display server and tightly integrated commercial toolkit, i.e. qt, this leaves only the drivers out of their direct control.

With wayland, they would still have their own compositor and display server. Wayland is a display server protocol, they would still implement the compositor (which is also the display server) themselves. And further, wayland allows extensions, so they would be able to implement any additional features they need whenever they want.

And canonical has no control over Qt at all, any changes they want to make have to be approved by the Qt project. Qt seems open to accepting patches to support Mir as long as Canonical promises to maintain the patches, but doesn't seem to have any interest in implementing or even maintaining them, unlike wayland that they are dedicated to maintaining themselves. And the Qt project is certainly not "tightly integrated" with Canonical, Canonical is just one of many downstreams for Qt. There is no indication it is a particularly influential or even particularly important one.

So going with Mir doesn't help them with any of the issues you listed, it just gives them a ton of extra work.

[Anarchy]

With wayland, they would still have their own compositor and display server. Wayland is a display server protocol, they would still implement the compositor (which is also the display server) themselves. And further, wayland allows extensions, so they would be able to implement any additional features they need whenever they want.

And canonical has no control over Qt at all, any changes they want to make have to be approved by the Qt project. Qt seems open to accepting patches to support Mir as long as Canonical promises to maintain the patches, but doesn't seem to have any interest in implementing or even maintaining them, unlike wayland that they are dedicated to maintaining themselves. And the Qt project is certainly not "tightly integrated" with Canonical, Canonical is just one of many downstreams for Qt. There is no indication it is a particularly influential or even particularly important one.

So going with Mir doesn't help them with any of the issues you listed, it just gives them a ton of extra work.

What's the use of the protocol if you have to implement it yourself? Or you can use the current protocol implementation, but then you're stuck with whatever comes from upstream and you're stuck with whatever they give you. And you still have to write your own compositor. Either way, you're breaking your own project for the sake of some abstract ideas of cooperation and interoperability. Mir gives them peace of mind knowing that if they fuck up something it's going to be their own fuck up. They might as well go on and write an exceptionally fast implementation of whatever they want and no one will give a damn. It's their own project and they're limited only by their knowledge base and money.

Qt is not a political project unlike GTK. It is a project developed by paid developers, whose only interest is making money out of it. They have no interest in seeing Canonical succeed or fail, nor does their parent company has any interest in Linux unlike Novell or Redhat. They might not control the development of Qt, but neither does Novell or Redhat.

[erendorn]

What's the use of the protocol if you have to implement it yourself? Or you can use the current protocol implementation, but then you're stuck with whatever comes from upstream and you're stuck with whatever they give you. And you still have to write your own compositor. Either way, you're breaking your own project for the sake of some abstract ideas of cooperation and interoperability. Mir gives them peace of mind knowing that if they fuck up something it's going to be their own fuck up. They might as well go on and write an exceptionally fast implementation of whatever they want and no one will give a damn. It's their own project and they're limited only by their knowledge base and money.

Qt is not a political project unlike GTK. It is a project developed by paid developers, whose only interest is making money out of it. They have no interest in seeing Canonical succeed or fail, nor does their parent company has any interest in Linux unlike Novell or Redhat. They might not control the development of Qt, but neither does Novell or Redhat.

Yeah, why make any web server follow http? Each web server should have its own API, and support added for each server into every browser.
Dude. Reality check. The protocol represents what is used to discuss between the server (compositor, developed by Canonical either way) and the clients (Qt, SDL, GTK, Java, and every huge cross platform program that does not use toolkits, like browsers, and none of them are developed by Canonical).
That's what using a common protocol brings you: you don't need to duplicate the work on projects you don't own anyway.

There are already several wayland compositors working or in progress. It is not expected that big players will use Weston.

But well, let them support the mir API downstream for each and every toolkit if they think it's a good idea. Their money, their time.

[Anarchy]

Yeah, why make any web server follow http? Each web server should have its own API, and support added for each server into every browser.
Dude. Reality check. The protocol represents what is used to discuss between the server (compositor, developed by Canonical either way) and the clients (Qt, SDL, GTK, Java, and every huge cross platform program that does not use toolkits, like browsers, and none of them are developed by Canonical).
That's what using a common protocol brings you: you don't need to duplicate the work on projects you don't own anyway.

There are already several wayland compositors working or in progress. It is not expected that big players will use Weston.

But well, let them support the mir API downstream for each and every toolkit if they think it's a good idea. Their money, their time.

I think that's the biggest problem with Linux, let's over engineers everything to the point of insanity, which might be a reflection of where Linux is exclusively used: HPC and servers. Wayland is way over engineered and complicated for a such a small project as desktop Linux. X11 turned out to be the way it is because 30 years ago different types of unix were the norm on workstations. Nowadays, PCs don't run xorg, they run windows or osx. And you don't need the fifty different desktops environments nor ten plus toolkits on Linux. But, that's my opinion, which might not necessarily be correct.

About the toolkits, Canonical is actually trying to separate itself from the bunch: Mir, Unity8, Click packages, exclusive Unity8 programs, etc. It all screams that they don't want to be part of the Linux community any more. Yes, that means more work for them in the short run. And I'm pretty sure there will be "natively" supported toolkits and "the rest", but as you said, it's their money and time. Only time will tell whether they succeed or not.

[erendorn]

I think that's the biggest problem with Linux, let's over engineers everything to the point of insanity, which might be a reflection of where Linux is exclusively used: HPC and servers. Wayland is way over engineered and complicated for a such a small project as desktop Linux.

I don't get that part. The biggest push for wayland has been for the embedded market (IVI, animated advert panels, TVs, boxes, where linux has quite a decent market share. also to some extent, phones). Wayland is well adapted to compositors much much simpler than a desktop shell. There's even test code for a system compositor, used just for full screening stuff during the boot process. Implementing wayland is simply not difficult (hence there are already half a dozen implementations).

[CoderniX]

This looks like what the (GNU/)Linux world has been doing for the past 5 years, through the graphics stack refactoring, and projects like wayland/mir.

Not exactly!

Wayland & Mir are some new kids in the hood, and they're yet to be tested under real situations' scenarios, i.e. Professional CAD Software, VFX and GFX Software, Gaming, Video/Images Rendering, and whatever.

As for the 5 years, no, they've been deprecating the unused hardware's code, and I meant getting rid of how to draw the Bitmaps based on the old protocol, the linear stuff and the rest, and I meant going back to the very lowest level of code, and make use of the new hardware capabilities and overcome all the things that hit X so hard in his past life.

Wayland and Mir bring whole new paradigms to the display system, and X has many issues from being designed for hardware of the last century. That's why it's being deprecated.

Exactly what I was saying, though I find your post somehow controversial looking at how you know what I meant, yet you put it as if I was off-topic.

But Mir doesn't bring anything compared to Wayland, so the comparison is pointless. The only thing it could bring is "swiftness" for Canonical (at the cost of less reusability of other projects), but even that it failed to do, given that Mir has not come to market any before than other Wayland compositors.

Controversial again, in my previous post I mentioned that Mir is the Solution for Canonical, and I understand their own angle from where they see things, and it makes sense for their convergence strategy, alongside their unified SDK idea, which again no other Distro is trying to resolve, when the likes of MS and Apple did have that ages ago.

Why they did not just make their own in-house Wayland compositor I simply cannot fathom. They would have gotten the best of both worlds... maybe they will, in a similar way to upstart.

Because time's proven Canonical was right, some of the big Wayland board members are big bigots as well, and they're totally immature and childish, i.e. how did Intel dealt with Mir patches for Mesa, which would have been happened even if Canonical had some Wayland platform exclusive specifications and they wanted them to be merged upstream, only to be slapped in the face by the likes of Intel and co, which is the same thing that stopped us from getting proper Optimus support on Linux, simply, because some FOSS fanatics --Alan Cox-- forbade NVIDIA from using the DMA-BUF to provide us a smooth resolution for what makes us more productive in our work, and heck if I care about Meritocracy to provide me a working solution and get the best money value of what I paid for.

The above problem is just a simple problem, yet it shows how fragile the decision making process in Linux, which would never have been happened on Windows or OSX, because Apple and Microsoft do own their full core stack of the Kernel and the OS, and because Hardware Technology is evolving, unfortunately not by the FOSS movement, but mostly by closed proprietary Hardware Vendors, and they need to be granted some space to provide support for us on par with the other OSes' users.

I can't see that happening for Canonical and Mir, but it would definitely happen a million times for Canonical and Wayland.

[Anarchy]

I don't get that part. The biggest push for wayland has been for the embedded market (IVI, animated advert panels, TVs, boxes, where linux has quite a decent market share. also to some extent, phones). Wayland is well adapted to compositors much much simpler than a desktop shell. There's even test code for a system compositor, used just for full screening stuff during the boot process. Implementing wayland is simply not difficult (hence there are already half a dozen implementations).

And I don't get your part. If those companies want wayland-like replacements/new-software then they should make one. Samsung electronics has more employees than Google, Apple and Microsoft combined. They are fully capable of developing their own software. There is literally zero reasons as to why Intel et al. should be doing that. And in the words of one of the managers of Uber Entertainment I'd rather see Intel fix their drivers instead of pretending to be the policeman of all things Linux. Also, the embedded market has been doing pretty fine without wayland so far. I'm sure they will survive without one companies taking care of the needs of other companies.

But, hey, that's how

[erendorn]

And I don't get your part. If those companies want wayland-like replacements/new-software then they should make one. Samsung electronics has more employees than Google, Apple and Microsoft combined. They are fully capable of developing their own software. There is literally zero reasons as to why Intel et al. should be doing that. And in the words of one of the managers of Uber Entertainment I'd rather see Intel fix their drivers instead of pretending to be the policeman of all things Linux. Also, the embedded market has been doing pretty fine without wayland so far. I'm sure they will survive without one companies taking care of the needs of other companies.

But, hey, that's how

But wayland is not an Intel project. Has not been since a long time. And that's just talking about the wayland/weston repo. All the work done on the kernel, input libs, toolkits, compositors is done by even more diverse contributors. And there are Samsung devs working on wayland stuff, namely the EFL compositor. Why would they want wayalnd-like replacement when they have wayland (same question as for Canonical, except they do ship stuff)? So in your previous post it was Novel and Red Hat, now it's Intel? Still not clear what the point is though.

[nanonyme]

Yeah, why make any web server follow http? Each web server should have its own API, and support added for each server into every browser.
Dude. Reality check. The protocol represents what is used to discuss between the server (compositor, developed by Canonical either way) and the clients (Qt, SDL, GTK, Java, and every huge cross platform program that does not use toolkits, like browsers, and none of them are developed by Canonical).
That's what using a common protocol brings you: you don't need to duplicate the work on projects you don't own anyway.

There are already several wayland compositors working or in progress. It is not expected that big players will use Weston.

But well, let them support the mir API downstream for each and every toolkit if they think it's a good idea. Their money, their time.

Counter-reality-check: Most client HTTP libraries are total crap and don't even support HTTP 1.1 without major glitches. This is the status today and soon we'll have been even more versions (2.0) to deal with. And that's not even taking into account all proprietary HTTP implementations when for reason or another existing libraries were not considered acceptable.

The root cause for this is that there is a protocol people needed to implement instead of there being one standard client library

[Anarchy]

But wayland is not an Intel project. Has not been since a long time. And that's just talking about the wayland/weston repo. All the work done on the kernel, input libs, toolkits, compositors is done by even more diverse contributors. And there are Samsung devs working on wayland stuff, namely the EFL compositor. Why would they want wayalnd-like replacement when they have wayland (same question as for Canonical, except they do ship stuff)? So in your previous post it was Novel and Red Hat, now it's Intel? Still not clear what the point is though.

Learn to read I said "Intel et al.". From the contributors list the most important contributors are from Intel, RedHat and Collabora. There's even a linux magazine article and they state the same thing there. Collabora is an open source consulting and development company whose customers are among others Intel and Samsung.

So much from the open source community project. We all know that's just bullshit. If that's what you want to believe in then go ahead. I will not argue with you any more. I end here.