Announcement

Collapse
No announcement yet.

KDE Has Another Week Worth Of Wayland Fixes

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

  • #31
    Originally posted by curfew View Post
    KDE people are developing their own compositor within their Kwin window manager. What is built into the Qt framework is actually separate from this effort, and the KDE devs have also explained why they are not making use of Qt's "native" Wayland libraries. I am not sure how the politics are surrounding extensions to Wayland protocol. I presume KDE is leading the way and Qt might re-implement same extensions or not, or maybe Qt is sticking to what has been "standardized", I have no idea.

    Besides I count at least six separate "serious" efforts: GTK, Qt, Kwin / KDE, libweston, wlroots... and Mir.

    The biggest issue here is, as a personal computer user, that the leading efforts for mainstream are Gnome / Mutter and KDE / Kwin. These two projects are standalone and "proprietary" in the sense that there is very little use for them outside Gnome and KDE. They are also building on their existing legacy Xorg-oritended codebase, which means that performance-wise they will be the slowest for a long time until they get re-written in a sufficient manner over the years.
    I actually already explained that to him... But he doesn't care... He just goes la-dee-dah.... He is completely oblivious that xorg already exists and that -desktop- compositors were already working on it, and that to replace it Wayland is -not- sufficient and requires huge amounts of re-invention due to it's lack of scope for -desktop- funtionality. He thinks all the re-invention that's happening is getting shared, but it's definitely not.

    Gnome is just as good as a walled garden, KDE isn't using Qt's work at all, Weston is functionally limited to appliances...
    Last edited by duby229; 22 November 2020, 11:27 PM.

    Comment


    • #32
      Originally posted by curfew View Post
      KDE people are developing their own compositor within their Kwin window manager. What is built into the Qt framework is actually separate from this effort, and the KDE devs have also explained why they are not making use of Qt's "native" Wayland libraries. I am not sure how the politics are surrounding extensions to Wayland protocol. I presume KDE is leading the way and Qt might re-implement same extensions or not, or maybe Qt is sticking to what has been "standardized", I have no idea.
      Generally the Qt/KDE relationship over the years is both sides implement there own versions of stuff and some point down the track they pick an winner then deprecate the loser implementation.

      Originally posted by curfew View Post
      Besides I count at least six separate "serious" efforts: GTK, Qt, Kwin / KDE, libweston, wlroots... and Mir.
      GTK has no work for Wayland Server. Gnome does have some work for wayland server but its all contained in Mutter and GnomeShell. Qt and Kwin I see as normal rival Qt implementation process that if history holds true one will win and one will die the resulting winner out of this will come the general Qt solution.

      Mir you can fairly much straight up delete because its a prototype to what Gnome is coming that has just not died yet. There is no new wayland protocol work coming out of Mir these days. I would say Mir was a serous attempt but the moment its not. Its also when you look at Qt mainline wayland server support you are not seeing new features.

      Really only 4 active implementation work on Wayland at the moment is Gnome, KDE, Weston and wlroots(from swaywm). With the ones outside this slowly becoming bit-rotted in support.

      Reality this was always going to be the outcome that there would be in time a short list because its too much work for there to be too many different implementations of wayland core to exist. But remember X11 server history had more than 1 at many points due to disagreements in how things should be done.

      Originally posted by curfew View Post
      The biggest issue here is, as a personal computer user, that the leading efforts for mainstream are Gnome / Mutter and KDE / Kwin. These two projects are standalone and "proprietary" in the sense that there is very little use for them outside Gnome and KDE. They are also building on their existing legacy Xorg-oritended codebase, which means that performance-wise they will be the slowest for a long time until they get re-written in a sufficient manner over the years.
      There is a yes and no here. Yes gnome very standalonish. KDE when you dig into Kwin is attempt to develop libraries to be used by other Qt programs and working up stream on libwayland-server.

      I will get back the standaloneish. Gnome current idea is very much old Mir idea. https://github.com/material-shell/material-shell that you want a different desktop you don't write it yourself you write extension that plugs into GnomeShell.

      Comment


      • #33
        Originally posted by oiaohm View Post

        That is not true. You have the libwayland-server and wlroots stuff that provides a lot of foundation stuff included in. Yes libwayland-server includes parts that are not part of the Wayland protocol. What ever is provided by libwayland-server and wlroots each compositor does not have to-do themselves. So Wayland compositors can save themselves a lot of work by working upstream on the libraries they depend on.

        Sorry the idea that lot of stuff that was part of Xorg has to be reinvented in every single compositor is not true. It has to be reinvented in a library that all the wayland compositors use in the ideal case. Some features reinvented outside wayland composer completely.


        Remember Xorg was not the only X11 server and is not the only one either https://en.wikipedia.org/wiki/List_of_display_servers.
        Unfortunately no major distro is going to use wlroots until they change their stance on NVidia which is the status quo right now anyways (KDE/Gnome have manually rolled their own Wayland integration).

        Comment


        • #34
          Originally posted by mdedetrich View Post
          Unfortunately no major distro is going to use wlroots until they change their stance on NVidia which is the status quo right now anyways (KDE/Gnome have manually rolled their own Wayland integration).
          This is no way near as straight forwards as you make it. Its if Nvidia or wlroots changes their position. Nvidia could change their position so allowing the open source nouveau to have all the firmware bits they need to work and that would allow wlroots to work without changes.

          Remember Nvidia is having trouble with 5.9 and newer Linux kernels with their binary blob. Also when running a Wayland desktop be it gnome/kde/weston you don't have working XWayland for legacy applications as in old games or business applications.

          Like it or not the best Wayland experience is with AMD or Intel GPUs.

          Remember the longer the dispute between kernel.org and Nvidia goes on the more likely that running Nvidia will equal running a Linux kernel with a exploit known in the wild. The hard reality is wlroots may not be the one needing to change their position at all. The one that could critical need to be changing their position is Nvidia.

          Comment


          • #35
            Originally posted by oiaohm View Post

            This is no way near as straight forwards as you make it. Its if Nvidia or wlroots changes their position. Nvidia could change their position so allowing the open source nouveau to have all the firmware bits they need to work and that would allow wlroots to work without changes.

            Remember Nvidia is having trouble with 5.9 and newer Linux kernels with their binary blob. Also when running a Wayland desktop be it gnome/kde/weston you don't have working XWayland for legacy applications as in old games or business applications.

            Like it or not the best Wayland experience is with AMD or Intel GPUs.

            Remember the longer the dispute between kernel.org and Nvidia goes on the more likely that running Nvidia will equal running a Linux kernel with a exploit known in the wild. The hard reality is wlroots may not be the one needing to change their position at all. The one that could critical need to be changing their position is Nvidia.
            Well for NVidia its feasibly impossible for them to release their current driver as open source, they have too many legal/IP issues. Considering the author of wlroots/sway (ddevault) opinion is also just as unlikely to change, they will never support the blob. So this status quo will just sit here until something massive changes.

            I think people need a bit of a reality check here, a huge proportion of Linux users use the NVidia cards along with the blob and no major DE is going to release make Wayland the default for NVidia users if its inferior (which it currently is). And none of the major DE's will use wlroots until it supports NVidia properly (which kind of makes wlroots goal as a general purpose library unfulfilled right now).

            So yeah, if wlroots wanted to become the general purpose library for other compositors to (similar to X11 now) they should have prioritized working with all existing hardware (which means being collaborative with NVidia) rather than being stubborn and only working with GBM/mesa.

            As I said elsewhere, with this situation Wayland will never become a default for a huge proportion of Linux users.
            Last edited by mdedetrich; 23 November 2020, 04:55 AM.

            Comment


            • #36
              Originally posted by curfew View Post
              KDE people are developing their own compositor within their Kwin window manager. What is built into the Qt framework is actually separate from this effort, and the KDE devs have also explained why they are not making use of Qt's "native" Wayland libraries. I am not sure how the politics are surrounding extensions to Wayland protocol. I presume KDE is leading the way and Qt might re-implement same extensions or not, or maybe Qt is sticking to what has been "standardized", I have no idea.

              Besides I count at least six separate "serious" efforts: GTK, Qt, Kwin / KDE, libweston, wlroots... and Mir.

              The biggest issue here is, as a personal computer user, that the leading efforts for mainstream are Gnome / Mutter and KDE / Kwin. These two projects are standalone and "proprietary" in the sense that there is very little use for them outside Gnome and KDE. They are also building on their existing legacy Xorg-oritended codebase, which means that performance-wise they will be the slowest for a long time until they get re-written in a sufficient manner over the years.
              I believe the biggest issue here is Wayland itself. The devs didn't stop at improving the X protocol, they also changed the architecture of the windowing system (see: https://en.wikipedia.org/wiki/Waylan..._Wayland_and_X).
              Having your software talk using protocols is easy (relatively speaking), but having it interacting with totally different components is hard.

              That's why seeing X striding along after all this time, while Wayland support is still being figured out is not even a little surprising.

              Comment


              • #37
                Originally posted by mdedetrich View Post
                Well for NVidia its feasibly impossible for them to release their current driver as open source, they have too many legal/IP issues.
                Really we don't need to open source their current binary blob. Simply providing the firmware open source nouveau needs and these firmware could remained closed source. The reality in performance the nouveau driver is not that far behind when it can clock the cards correctly.

                Originally posted by mdedetrich View Post
                Considering the author of wlroots/sway (ddevault) opinion is also just as unlikely to change, they will never support the blob. So this status quo will just sit here until something massive changes.
                Something needs to change. The Nvidia is under pressure from kernel.org how this will play out time will tell.

                Originally posted by mdedetrich View Post
                I think people need a bit of a reality check here, a huge proportion of Linux users use the NVidia cards along with the blob and no major DE is going to release make Wayland the default for NVidia users if its inferior (which it currently is).
                The reality is Wayland support is broken under Nvidia because Nvidia has not released what is required so XWayland works and other bits like it.

                Originally posted by mdedetrich View Post
                And none of the major DE's will use wlroots until it supports NVidia properly (which kind of makes wlroots goal as a general purpose library unfulfilled right now).
                There is a major Wayland part not supported. https://github.com/Plagman/gamescope this is from Valve. You know Steam. This is based on wlroots. So there is already a major player using wlroots that is DE choice neutral.

                Originally posted by mdedetrich View Post
                So yeah, if wlroots wanted to become the general purpose library for other compositors to (similar to X11 now) they should have prioritized working with all existing hardware (which means being collaborative with NVidia) rather than being stubborn and only working with GBM/mesa.
                You have missed Nvidia is not cooperating with what Valve wants one of the biggest game distributors on earth.

                Originally posted by mdedetrich View Post
                As I said elsewhere, with this situation Wayland will never become a default for a huge proportion of Linux users.
                The reality is horrible for all people who play commercial games from Steam on Linux Wayland support in the form of something wlroots compatible is going to come a mandatory feature.

                So is it going to come if you want to game on Linux you buy AMD and avoid Nvidia like the plague because is a broken pile of garbage. That is the path we are heading to if Nvidia does not change its path.

                Comment


                • #38
                  Originally posted by oiaohm View Post
                  Really we don't need to open source their current binary blob. Simply providing the firmware open source nouveau needs and these firmware could remained closed source. The reality in performance the nouveau driver is not that far behind when it can clock the cards correctly.
                  The reality is that the for the people that buy NVidia cards, only the vast minority would use nouveau due to its performance being much lower than the blob (this is even taking into account if the signed firmware problem gets resolved). nouveau is like 20 years behind the blob in terms of performance. The blob also isn't going to support things like CUDA (which is actually the big reason many enterprise people use NVidia in the first place).

                  I am sorry, but this is not a short term or even medium term strategy

                  Originally posted by oiaohm View Post
                  Something needs to change. The Nvidia is under pressure from kernel.org how this will play out time will tell.
                  Change what? They are never going to open source their blob (I can guarantee that) and nouveau is many man years behind being on the same level.

                  Originally posted by oiaohm View Post
                  The reality is Wayland support is broken under Nvidia because Nvidia has not released what is required so XWayland works and other bits like it..
                  Actually lets be clear, Wayland isn't broken because of Nvidia. Wayland is broken because Linux OS developers refuse to support Nvidia in their Wayland implementation. Wayland is just a protocol, it has nothing to do with GBM/Mesa or any Linux specific technologies.

                  Originally posted by oiaohm View Post
                  There is a major Wayland part not supported. https://github.com/Plagman/gamescope this is from Valve. You know Steam. This is based on wlroots. So there is already a major player using wlroots that is DE choice neutral.
                  I am aware of gamescope but its also blocked from working with NVidia's blob because ironically changes are required in X11/Xserver (this was the result of discussing with someone else) and since X11 is "abondonware" nothing is happening on that front.

                  Currently gamescope can't provide hardware acceleration from NVidia blob to Wayland which kind of defeats the purpose of it.

                  Originally posted by oiaohm View Post
                  You have missed Nvidia is not cooperating with what Valve wants one of the biggest game distributors on earth.
                  NVidia is co-operating, if they didn't they wouldn't have even released EGLStreams or released libglvnd https://github.com/NVIDIA/libglvnd . The problem is not that NVidia is not co-operating, its actually Linux that is not co-operating. Hint: If you ask another company to do something that is practically feasibly impossible then you are not co-operating by definition.

                  Nothing is stopping Linux kernel/OS developers from making the blob work with the kernel (either via EGLStreams or libglvnd or even the kernel providing an interface that Nvidia can use). They just refuse to do so for various technical arguments.

                  On the other hand if NVidia open sources their driver, they would literally open themselves to massive lawsuits. This means they would have to spend years getting rid of all of the SG IP from their blob (which considering their blob is over 30 years old with millions lines of code isn't going to be easy).


                  Originally posted by oiaohm View Post
                  The reality is horrible for all people who play commercial games from Steam on Linux Wayland support in the form of something wlroots compatible is going to come a mandatory feature.
                  Mandatory or not, its going nowehere if it doesn't work with the biggest gaming GPU manufacturer. No one in their right mind would play Steam on Linux if they have an NVidia card if they are forced to use Wayland.

                  Originally posted by oiaohm View Post
                  So is it going to come if you want to game on Linux you buy AMD and avoid Nvidia like the plague because is a broken pile of garbage. That is the path we are heading to if Nvidia does not change its path.
                  Let me change that

                  That is the path we are heading to if Nvidia AND linux does not change its path.
                  This is not all NVidia's fault, its also Linux's. I am sorry, this problem isn't going to get anywhere if you keep blaming NVidia for everything. Not only is doing this immature and childish, its also not constructive (if anything it put us back many years because I can imagine NVidia not feeling enthusiastic working with Linux developers if they have such an attitude).

                  In any case, history says that you are completely wrong. When NVidia released EGLStreams, both Gnome and KDE devs refused to use it/co-operate. There was a deadlock for many years because NVidia really did the only thing they reasonably could do. Fast forward to today where everyone is pushing hard to make Wayland the default, and guess what, KDE/Gnome had no choice but to accept EGLStreams because yeah, surprise surprise, no DE is going to kill off a massive proportion of its user base.
                  Last edited by mdedetrich; 23 November 2020, 06:39 AM.

                  Comment


                  • #39
                    Originally posted by mdedetrich View Post
                    The reality is that the for the people that buy NVidia cards, only the vast minority would use nouveau due to its performance being much lower than the blob (this is even taking into account if the signed firmware problem gets resolved). nouveau is like 20 years behind the blob in terms of performance.
                    When you benchmark nouveau with functional signed firmware sorry its not 20 years behind. Its really looks like AMD with their closed source vs open source in performance shape with nouveau winning on some programs.

                    Originally posted by mdedetrich View Post
                    The blob also isn't going to support things like CUDA (which is actually the big reason many enterprise people use NVidia in the first place).
                    CUDA is current dead on 5.9 and newer Linux kernels.


                    Originally posted by mdedetrich View Post
                    Actually lets be clear, Wayland isn't broken because of Nvidia. Wayland is broken because Linux OS developers refuse to support Nvidia in their Wayland implementation. Wayland is just a protocol, it has nothing to do with GBM/Mesa or any Linux specific technologies.
                    This is nothing todo with why Xwayland does not work.


                    Originally posted by mdedetrich View Post
                    I am aware of gamescope but its also blocked from working with NVidia's blob because ironically changes are required in X11/Xserver (this was the result of discussing with someone else) and since X11 is "abondonware" nothing is happening on that front.
                    This is bull crap that X11/Server needs patching. https://gitlab.freedesktop.org/mesa/..._requests/6429 this here demo that no changes are need in X11/Xserver to get XWayland to work.

                    The reality here is Xwayland uses GLVND vendor library,. The reality here is Nvidia has not provided the required platform library so XWayland can work. Redhat developer by hack demos that this is exactly the case.


                    Originally posted by mdedetrich View Post
                    NVidia is co-operating, if they didn't they wouldn't have even released EGLStreams or released libglvnd https://github.com/NVIDIA/libglvnd .
                    The problem here is Nvidia put forwards libglvnd Mesa and other drivers have taken this on board as their primary solution. Why Xwayland does not work with Nvidia is that Nvidia has thrown libglvnd over the wall not implemented everything their side themselves. Throwing stuff over the wall and saying to others you should implement it this way and then you don't is not cooperation.

                    Xwayland being 100 percent dependant on libglvnd for all driver bits is because of Nvidia own suggestion by the way mdedetrich. Basically Nvidia made this bed now they are refusing to be put in it. Did they design huge nails into libglvnd to sabotage other vendors???? Nvidia need to truly start explaining what the hell is wrong with their own designed solution that they are refusing to use it. That refusal is why Xwayland does not work with Nvidia.

                    Comment


                    • #40
                      Originally posted by oiaohm View Post

                      When you benchmark nouveau with functional signed firmware sorry its not 20 years behind. Its really looks like AMD with their closed source vs open source in performance shape with nouveau winning on some programs.
                      Yes because AMD directly contributed to the open source driver which is something that NVidia can't do to nouveau for the IP reasons stated earlier.

                      Originally posted by oiaohm View Post
                      CUDA is current dead on 5.9 and newer Linux kernels.
                      Currently yes, but the loss is bigger on Linux's end if nothing is done about it All this means is that a lot of Linux users will refuse to update Linux if they are using CUDA which is actually a bigger problem for Linux rather than NVidia.

                      Originally posted by oiaohm View Post
                      The reality here is Xwayland uses GLVND vendor library,. The reality here is Nvidia has not provided the required platform library so XWayland can work. Redhat developer by hack demos that this is exactly the case.

                      The problem here is Nvidia put forwards libglvnd Mesa and other drivers have taken this on board as their primary solution. Why Xwayland does not work with Nvidia is that Nvidia has thrown libglvnd over the wall not implemented everything their side themselves. Throwing stuff over the wall and saying to others you should implement it this way and then you don't is not cooperation.

                      Xwayland being 100 percent dependant on libglvnd for all driver bits is because of Nvidia own suggestion by the way mdedetrich. Basically Nvidia made this bed now they are refusing to be put in it. Did they design huge nails into libglvnd to sabotage other vendors???? Nvidia need to truly start explaining what the hell is wrong with their own designed solution that they are refusing to use it. That refusal is why Xwayland does not work with Nvidia.
                      You do realize that there is reason why NVidia isn't doing what you think they should be doing, otherwise they would have done so. Its not like Nvidia is sabotaging themselves. They already stated that the GBM/Mesa infrustructure is completely different from their blob and supporting it directly from their blob would create a massive performance decrease and/or other problems (this was said like 8 years ago). Their Linux driver is actually a massive cross platform binary that is shared for all of their drivers for their OS's with an interface layer that the binary than communicates with the OS/Kernel. Linux is the ONLY OS/platform that is causing them problems and thats because its the only OS/platform that is monolithic and GPL (which causes problems for proprietary drivers). Linux of course has no issues with userspace blobs, but suddenly if its a driver than shit hits the fan.

                      This was the whole reason behind the design of EGLStream's, it was to make a vendor neutral open standard for compositing/desktops that made no assumptions on the kernel or the driver. Linux didn't want it, so we are stuck here.,

                      Anyways we are going around circles, but my prediction for what has currently happened is entirely correct. Linux DE devs need to figure out how to work with NVidia otherwise its actually Linux that endsup suffering, not NVidia. NVidia users that wan't CUDA will just run old Linux's with backported fixes, its not the first time that this has happened in enterprise (heck this might ironically end up hitting Redhat really hard if it goes on long enough, a lot of redhat people rely on CUDA).

                      But yeah, continue blaming NVidia for everything because that has definitely worked in the past
                      Last edited by mdedetrich; 23 November 2020, 08:11 AM.

                      Comment

                      Working...
                      X