Announcement

Collapse
No announcement yet.

NVIDIA Says It Has No Plans To Support Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Soo many trolls, zealots and sheeples

    Widelands isn't even really usable for day to day stuff and people are crying that NVIDIA have stated that they have no plans to support it

    They didn't say they won't support it, they didn't say they will never support it JUST they don't plan to.

    It aint even fucking stable yet, it aint even rolled out on any distro yet wtf should nvidia waste time providing hooks to wayland when, for something that is in an alpha state, could change its api...

    if/when wayland has its 1st stable release and it starts to get picked up I am sure nvidia will look into providing support BUT since noone can say that they will or they won't on something that is in the very far future WTF go full retard over it! never go full retard

    Comment


    • no plans = fu*k off
      whats policy of all corporations.. same asus xonar DX.. still no binary drivers... a asked them 3 years ago... other manifacturers do same...
      no plans = never will be...
      cause its non profit for them...

      Comment


      • Originally posted by makomk View Post
        They do need to, because Wayland is currently hardcoded to use the kernel modesetting code and a fairly significant chunk of DRI2 directly. What's more, this part of Wayland is itself under the GPL, so it's not like they can fork a modified version that uses their own proprietary modesetting library either.
        It's really easy to add somethings not using KMS, NVidia or AMD can do a closed source module that does modesetting and the just add support in wayland to use this closed source library.


        Originally posted by makomk View Post
        That's the minimum requirement for something like Wayland to be used. Wayland itself does actually require DRI2. If they wanted to, AMD might just be able to implement enough of DRI2 to allow Wayland to run on top of X.org on fglrx, but this option really isn't practical for NVidia because they don't actually use DRI. Even then, running Wayland without using X.org as a backend is another matter entirely.
        Maybe you should actualy have read the wayland code, there is no need for dri2 at all in it except in the x11 version but the point of wayland is not to run on x11. Really all the closed source need are the image extension which basicly need to be able to associate a name (unique int number) to gl/gles/... buffer. So no it doesn't need any significant change to nvidia or fglrx closed source driver. All it needs is providing a modesetting facilities outside X and adding support for the EGL image extension, none of this should be hard.

        Comment


        • Why Canonical is Supporting Wayland (and Not Alone)

          Originally posted by JeanPaul145 View Post
          Even if Wayland becomes sort of a defacto standard on Linux desktops and nVidia *still* decides not to support it, I don't really see the problem: nvidia blob users will keep on using X.org and nouveau users will use Wayland (or X.org). So everyone would still have a choice in what kind of driver and display server to use (except of course the newest-gen gfx card users, for obvious reasons).

          For that matter, I don't get all those people whining about Canonical planning to implement Wayland: They can run an xserver on wayland if they need the features, and if that for some reason doesn't meet their needs X.org will still be in the repo's, so anyone can simply swap out Wayland for X.org. Linux in general is about choice and fortunately Canonical is not about to take that away from Ubuntu's users.
          For anyone who doesn't need features like X-forwarding (which will be most Ubuntu users I'm guessing), implementing Wayland will be a huge win both in display quality and performance.
          Canonical pretty much has little option as far as supporting Wayland, when two of the three major GPU suppliers (Intel and AMD) to Canonical's hardware partners (especially System76) are also backing Wayland (both directly and indirectly). Finding Intel there is no surprise (largely because of Gallium3D, which has a lot in common with Wayland); it's the presence of AMD that's the Left Field Event.

          AMD had been taking a severe lambasting in the open-source community for over-reliance on binary-blob drivers, especially for Linux (for everything from workstation GPUs to netbook GPUs) Starting with Gallium (and now Wayland), AMD has made a rather abrupt turnabout and has been dropping source-code into the pipeline as fast as AMD's lawyers will let it. Instead of a two year lag (as it was at its worst) between hardware-release and the availability of open-source driver support, it's now less than nine months; only HD5xxx/6xxx are not supported by open-source drivers now, and that could change for HD5xxx by the end of this calendar year.

          Part of what is causing nVidia's reticence is that they remain hostile to Gallium3D (a solid support base for Gallium3D is pretty much a necessary for Wayland) - while AMD was late, at least they were (and are) there. Whether or not it will come back to bite them is in the hands of nVidia.

          Comment


          • Originally posted by glisse View Post
            It's really easy to add somethings not using KMS, NVidia or AMD can do a closed source module that does modesetting and the just add support in wayland to use this closed source library.




            Maybe you should actualy have read the wayland code, there is no need for dri2 at all in it except in the x11 version but the point of wayland is not to run on x11. Really all the closed source need are the image extension which basicly need to be able to associate a name (unique int number) to gl/gles/... buffer. So no it doesn't need any significant change to nvidia or fglrx closed source driver. All it needs is providing a modesetting facilities outside X and adding support for the EGL image extension, none of this should be hard.
            AMD *is* supporting Wayland, and their drivers (not just the open-source ones, but their binary blob Linux Catalysts) support KMS today. If you have solid Gallium3D support, the jump to solid Wayland support is even easier (which is why Intel is there with both feet).

            Lastly, the big driving force behind Wayland is an area in which nVidia is now taking some serious (pardon the expression) heat - netbooks, notebooks, and laptops, which are the LEAST likely to have any desire to run Wayland atop X (simply due to reasons of code weight). Instead, this class of hardware would prefer to run Wayland *instead* of X, not atop it. Without Wayland, nVidia could find itself a non-player in open-source portable computing (and therefore locked into WinMac), and does nVidia really want to wind up there (considering that they aren't exactly chasing either Intel or AMD away)?

            Comment


            • Originally posted by PGHammer View Post
              only HD5xxx/6xxx are not supported by open-source drivers now, and that could change for HD5xxx by the end of this calendar year.
              HD5xxx (aka Evergreen) is already supported; Alex & Richard are working on HD6xxx now.

              Comment


              • Originally posted by PGHammer View Post
                Finding Intel there is no surprise (largely because of Gallium3D, which has a lot in common with Wayland); it's the presence of AMD that's the Left Field Event.
                Originally posted by PGHammer View Post
                Part of what is causing nVidia's reticence is that they remain hostile to Gallium3D (a solid support base for Gallium3D is pretty much a necessary for Wayland) - while AMD was late, at least they were (and are) there. Whether or not it will come back to bite them is in the hands of nVidia.
                Uh, Intel doesn't support Gallium3D and as far as i know has no plans to ever do so in the future. They seem to like their classic driver, for whatever reason, and have been pretty dismissive whenever someone has mentioned Gallium.

                Comment


                • Wrong Company

                  Originally posted by smitty3268 View Post
                  Uh, Intel doesn't support Gallium3D and as far as i know has no plans to ever do so in the future. They seem to like their classic driver, for whatever reason, and have been pretty dismissive whenever someone has mentioned Gallium.
                  Now you *could* have stuck AMD (not Intel) into that sentence as little as a year ago. Do you remember that big dustup over a massive rewrite of Mesa and the compositing layer of X.org (GEM vs. TIM)? That was the dustup that gave birth to Gallium3D (and eventually to Wayland as well); Intel was backing one, while AMD (and nVidia) were backing the other. However, that wasn't even the biggest reason why AMD had been getting whacked - the bigger reason was the lack of open-source support for (at the time) the HD series GPUs - the only solid support required the binary-blob (which wouldn't work on every Linux distribution extant). It is precisely that whacking that has me classifying AMD's about-face (especially in terms of Gallium 3D and Wayland) as a Left Field Event.

                  Intel likes the classic driver for X (because X.org did *not* adopt the model that Intel wanted in the GEM vs. TIM dustup). Gallium doesn't care about esoterica like that (because it's abstracted) - Wayland doesn't, either. Intel's graphical hardware supported Gallium3D before AMD's hardware did (primarily because the big driver for Gallium3D was portable computers, where, until recently, Intel, not AMD, had the largest GPU presence).

                  Comment


                  • AFAIK the Gallium3D transition was largely independent of the GEM/TTM discussions... the only real dependency was a decision to only implement the Gallium3D stack over DRI2, which had a dependency on GEM/TTM, which in turn was implemented only for KMS systems.

                    The "radeon rewrite" initiative was primarily to let one set of userspace code work with both DRI1 and DRI2/GEM/TTM/KMS, by introducing a new abstraction layer for command submission and buffer management.

                    Comment

                    Working...
                    X