Announcement

Collapse
No announcement yet.

KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

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

  • Originally posted by MrCooper View Post




    That makes no sense.

    DDX stands for "Device Dependent X", which refers to the code in the xserver tree which is specific to a particular X server binary such as Xorg (or Xwayland, Xvfb ...), not used by any other X server binary. There can be no functional X server without some DDX code. That's what the dead Xorg DDX code (which is almost 6 times as big as the Xwayland DDX code at this point) is.
    ​I see exactly zero mentions of DDX in

    Its all DRM, which is exactly the same device API used by wayland.

    Originally posted by MrCooper View Post
    Per above, the dead Xorg DDX code is used only by Xorg, not by Xwayland.
    If that's not dead, it's certainly on life support.
    Do you have an example of a meaningful DDX bug that has been open for more than 5 years?

    Because I know of plenty of meaningful wayland compositor bugs and issues that have been open a lot longer than that, and Ive never seen one for DDX.

    Hyperthetically speaking. lets say no xorg ddx code was touched by anyone for the next 10 years even if they wanted to, what would be the consequences?

    Because if you applied that logic to ANY wayland compositor they all really would be dead with zero use in 10 years because everyone will have switched back to xorg-server.

    If anything is on life support right now its wayland. No 3rd party adoption, decades of investment and still not even close to basic feature parity with xorg-server, desperate attempts to make people care, emotional outbursts and tears and blame gaming. These are signs of being on life support, not getting on quietly and flawlessly with its job and no one noticing.
    Last edited by mSparks; 22 September 2023, 05:56 AM.

    Comment


    • Originally posted by mSparks View Post
      All you have written is that this problem is an issue with selinux
      Currently, ioctls are not whitelisted. Whitelisting them would significantly improve security.


      that applies equally to X11 and wayland.
      Again try again. The GEM ioctl is the problem but on a DRI2 system you cannot filter it and have it work. Whitelist/Blacklist ioctl does not help you when you are in DRI2 where you must use GEM. Because if you blacklist the ioctl that gives GEM handle mapping into applications you also applications from accessing their own GEM handles.

      Newer is better right. Eglstreams is newer than DRI2 right. It has all the same properities that make GEM handles unable to be secured + one nice extra. You know that one master file that every gem buffer is in that connected to the device driver with GEM the.

      Eglstreams version for has the master file for all Eglstreams buffers is connected to the First Wayland compositor or x11 server so that if the wayland compositor or x11 server using eglstreams crashes all allocated memory gets freed so coming segfaults that can disrupt applications like firefox and chrome from saving their state.
      Yes again

      Yes Eglstreams in nvidia implementation is also using a ioctl that if you block the application cannot get access to it own Eglstreams buffers..

      Nvidia closed source driver also has a ioctl that if you block cannot get access to it own graphics buffers.
      Guess what GEM/Eglstreams/Nvidia closed source don't block that ioctl and you can get access to every graphical buffer. You have no security.

      Wayland after 2013 is based around DMABUF so blocking the GEM ioctl has zero effect on it. Nvidia closed source user space code to wrap up DMABUF to Nvidia own still end up using one of these highly insecure ioctl interfaces.

      mSparks these defects are true rock and hard place. You block the ioctl nothing works you allow the ioctl you have security nightmare. Remember the Unix rule everything is a file. That says that a graphics buffer should be it own file like DMABUF has it any other way of doing is wrong and is also very insecure on Unix like OSs

      Windows NT design says that everything should be handle/object so graphics buffers should be their own object if they are not under windows what you have is highly insecure.

      The reality is Nvidia closed source driver is a security nightmare. Open source drivers moved away from this security nightmare in 2013.

      Be it GEM, Eglstreams or Nvidia closed source current you have the same 3 problem that make rock and hard place.
      1) block access to the master file and programs cannot use graphical buffers at all
      2) block the ioctl for application to access segment of the master file then cannot access it own graphical buffers.
      3) Leave access to the ioctl and the application can access every graphical buffer without restriction.
      selinux cannot help you this is defective design that comes from the fact X11 was first not design for POSIX compatible OS..

      Of course Nvidia adds a nice 4 issue for the Eglstream.
      4) master file for all graphical buffers is connected bare metal Wayland compositor or X11 server writtn using Eglstreams so that if that crashes it takes everything with it.

      Yes Wayland compositor not working on robustness before 2021 is developers could not work out how to make Nvidia side work because by design it could not. Yes Wayland getting robustness moving aligns with nvidia agreeing to move to DMABUF being a sane design.

      Comment


      • Originally posted by mSparks View Post
        ​I see exactly zero mentions of DDX in

        Its all DRM, which is exactly the same device API used by wayland.


        DDX is part of xserver that xserver userspace drivers interface with.


        Code:
        Section "Device"
        Identifier "AMD Radeon"
        Driver "radeon"
        EndSection​
        See the bit called radeon there msparks what is it.
        Do notice how Intel with X11 server these days is recommend in most cases to fall back on xf86-video-modesetting instead of xf86-video-intel. Yes both of these things are X11 userspace DDX drivers.

        Yes that --Driver "radeon"-- is referencing the package xf86-video-radeon that is a DDX driver. Zero mentions of DDX is not exactly true. It mentions a DDX driver just does not call it a DDX driver. gentoo documentation issue. archlinux normally in their documentation do clearly say its a DDX driver or at least mention of DDX.

        Comment


        • Originally posted by oiaohm View Post
          See the bit called radeon there msparks what is it.
          written by AMD and updated every few weeks?
          exactly the same code used by wayland.
          Certainly NOT "on life support".

          Originally posted by oiaohm View Post
          The GEM ioctl is the problem but on a DRI2 system you cannot filter it and have it work.
          Good?
          Because having userspace applications manage operating system permissions is absolutely idiotic?

          Are you really insisting that IBM sees wayland compositors as replacements for SELINUX?
          OMFG I think that's the funniest thing you have said this whole thread.

          Not quite on par with the guys that picked their own reviewers for their journal article and STILL got rejected.
          but pretty close.​
          Last edited by mSparks; 22 September 2023, 06:34 AM.

          Comment


          • Originally posted by mSparks View Post
            written by AMD and updated every few weeks?
            exactly the same code used by wayland.
            Certainly NOT "on life support".
            Wayland does not use the DDX code. Only thing with commonality with Wayland compositors is "xf86-video-modesetting" and the Xwayland DDX of course.

            When Redhat was running x.org development AMD did update DDX radeon every few weeks but since Redhat has moved over to Wayland path that has stopped. So not even correctly on life support.-

            Originally posted by mSparks View Post
            Because having userspace applications manage operating system permissions is absolutely idiotic?.
            1) block access to the master file and programs cannot use graphical buffers at all
            2) block the ioctl for application to access segment of the master file then cannot access it own graphical buffers.
            3) Leave access to the ioctl and the application can access every graphical buffer without restriction.​


            This is have no permissions what so ever and by design no way to implement any be it user space or kernel space. In fact I did not mention the best bit. GEM/Eglstreams/"Nvidia current closed source" all are working on security by obscurity issuing buffers numbers in a simple i++ with i being the last one issued with no punishment for attempting to allocate a buffer that currently not allocated..

            Originally posted by mSparks View Post
            Are you really insisting that IBM sees wayland compositors as replacements for SELINUX?.​
            This is the most idiot comment from you so far.

            Wayland compositors are using file handles. So why would someone need to replace Selinux when you just use OS native permission systems so the OS native permission system can work. Wayland by design is using interfaces that selinux and other Linux security modules can filter.

            I could go into the X11 protocol where instead of ioctl you have a function call that any application can do that has the same problem with no way to clearly identify where the request has come from.

            There is still the issue of what todo with dbus and LSM integrations but at least there is permissions there not the GEM/Eglstreams/"nvidia current closed source" of we don't care about permissions..

            Comment


            • Originally posted by oiaohm View Post

              Only thing with commonality with Wayland compositors is "xf86-video-modesetting"
              This is the only part of DDX being used by XORG on anything younger than 10 or 20 years old.
              It switches it to the DRM driver that both xorg and wayland use for 2D and 3D acceleration.
              the Driver "radeon" you posted above.
              nvidia,nouveau, AMDVLK, RADV, drm-intel etc.
              Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


              ->the xf86-video-modesetting generic DDX that is widely used has lacked that option. That is until a developer finally stepped up and has pending support for the "TearFree" option.

              Apparently, that means wayland is dead......
              Last edited by mSparks; 22 September 2023, 09:09 AM.

              Comment


              • Originally posted by mSparks View Post
                This is the only part of DDX being used by XORG on anything younger than 10 or 20 years old.
                It switches it to the DRM driver that both xorg and wayland use for 2D and 3D acceleration.
                the Driver "radeon" you posted above.
                Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


                ->the xf86-video-modesetting generic DDX that is widely used has lacked that option. That is until a developer finally stepped up and has pending support for the "TearFree" option.
                No you still have the problem that when you load X11 compositor with X11 server that you take a huge performance hit where a person using Wayland gets the compositor effects without this problem. Also remember if xf86-video-modesetting driver decides to fire up with your Nvidia graphics as it can you will take the exact same performance hit as Wayland compositors have.

                Nvidia issues with Wayland Compositors are issues using xf86-video-modesetting and Nvidia. So wayland driver problems are X11 driver problems get use to it.

                Next loading X11 compositor still is going to cause performance hit from hell.

                Also yes they implemented TearFree on mode-setting but the option for application to tell xf86-video-modesetting to allow tearing the Xwayland DDX has is not their yet.

                The reason why Wayland started in the first place was waking up in DRI2 to make X11 compositor perform well would require completely redoing the Xcomposite bit of X11 protocol so breaking all X11 compositors. Someone still need to step to do that fix.

                Comment


                • Originally posted by oiaohm View Post

                  when you load X11 compositor with X11 server that you take a huge performance hit
                  Meanwhile, in the real world
                  Download Safing's Portmaster and take control of your network traffic: https://safing.ioGrab a brand new laptop or desktop running Linux: https://www.tuxedoc...


                  Wayland = 10% performance hit on average vs xorg-server
                  Originally posted by oiaohm View Post
                  Nvidia issues with Wayland Compositors
                  Yeah yeah, its all nvidias fault wayland never made it off life support and 3rd parties dont want to adopt it. bo ho. definitely no blame game being played there. wayland is fit and healthy and ready to rule the world....

                  I mean, Just look how gorgeous dolphin can look on AMD wayland


                  What user doesn't want that from their desktop experience.
                  Call out the jedi mind trick eh
                  "This is not the tear free you are looking for"
                  ROFL

                  But somehow, "dead" xorg-server is managing better performance, tear-free, with none of the issues. Weird that.
                  Last edited by mSparks; 22 September 2023, 09:43 AM.

                  Comment


                  • Originally posted by mSparks View Post
                    ​I see exactly zero mentions of DDX in
                    https://wiki.gentoo.org/wiki/Xorg/Ha...leration_guide
                    I've been working on X server code for 2.5 decades, I don't need a document to know what DDX means.

                    Try https://www.x.org/releases/X11R7.7/d...rver-spec.html

                    (Some people say DDX when they mean "Xorg driver"; that's a pet peeve of mine)

                    Do you have an example of a meaningful DDX bug that has been open for more than 5 years?
                    I have 38 (at the time of writing) examples:

                    xserver issues migrated from Bugzilla with Xorg DDX label

                    Probably just the tip of the iceberg though.

                    Because if you applied that logic to ANY wayland compositor they all really would be dead with zero use in 10 years because everyone will have switched back to xorg-server.
                    Dream on. Not in this universe, where we're in the long tail phase of the transition.

                    If anything is on life support right now its wayland.
                    That's ridiculous. There's orders of magnitude more development activity around Wayland than around Xorg at this point, it reminds me of the golden days of Xorg.

                    No 3rd party adoption, decades of investment and still not even close to basic feature parity with xorg-server
                    That dead horse again? Were you using X when it was as old as Wayland is now? I was (also developing it), it wasn't as feature-complete as Wayland is now. E.g. it was only just getting things like anti-aliased text rendering, compositing and RandR.

                    By your argument, X should have been declared a failure and abandoned then. But it was the start of its golden era.

                    desperate attempts to make people care, emotional outbursts and tears and blame gaming.
                    I see one person here which fits that description.​

                    Originally posted by oiaohm View Post
                    When Redhat was running x.org development AMD did update DDX radeon every few weeks but since Redhat has moved over to Wayland path that has stopped.
                    ​Not quite how that went down, which is:

                    The person doing most of the xf86-video-amdgpu/radeon work for AMD (me) moved to Red Hat (not Redhat), because I wanted to work on advancing the Wayland ecosystem. Nobody has picked up xf86-video-amdgpu/radeon development at a comparable pace since.​

                    Originally posted by mSparks View Post
                    Meanwhile, in the real world
                    Download Safing's Portmaster and take control of your network traffic: https://safing.ioGrab a brand new laptop or desktop running Linux: https://www.tuxedoc...


                    Wayland = 10% performance hit on average vs xorg-server
                    nvidia driver.

                    Phoronix regularly tests Wayland vs Xorg gaming performance on AMD GPUs, it's always basically a wash these days (as it should be, since gaming should boil down to directly scanning out client buffers in both cases, unless there's some bug or configuration issue which prevents that).
                    Last edited by MrCooper; 22 September 2023, 11:42 AM.

                    Comment


                    • Originally posted by MrCooper View Post
                      That's ridiculous. There's orders of magnitude more development activity around Wayland than around Xorg at this point, it reminds me of the golden days of Xorg.
                      Oh, I am well aware a lot of money is being spent right now trying to keep it alive....
                      The big question is tho, can it be brought to life within the 12 month deadline Fedora just gave it, or will FC40 see less adoption than Nobara.
                      What you talking to me for, you got a lot of work to do before then... not least getting nvidia-settings up and running, I'd suggest you start reverse engineering that now, or FC40 is going to drop with no nvidia configuration support.

                      Originally posted by MrCooper View Post
                      I have 38 (at the time of writing) examples:

                      xserver issues migrated from Bugzilla with Xorg DDX label
                      xfree86 is not DDX, its not even xorg-server.... And not one of them is actually an issue.
                      Originally posted by MrCooper View Post
                      Were you using X when it was as old as Wayland is now?
                      Xorg-Server was released in 2004, been on that since it's initial release.
                      Wayland was released in 2008, just 4 years later, tried it 3 or 4 times since RH started putting "using wayland is recommended" in its documentation, only to find that was a really shitty recommendation that broke everything and offered nothing.
                      My first linux distro I used in a meaningfull way was mandrake linux in 1998, so I guess that was probably running XFree86

                      I have played with some very early unix/bsd spins on virtual machines just to get a feel for them.
                      e.g.
                      SunOS was a UNIX based OS derived from BSD. Initially released in 1982, it was the standard OS on Sun Machines at that time. Platforms supported by this OS were the Motorola 68000, the Sun 386i, and the SPARC. SunOS machines are still actually in use today powering dams and bread factories.

                      and
                      https://docs.oracle.com/cd/E19455-01...kmd/index.html

                      As for "3rd party adoption", in between my Friday night CSGO dead time I gave

                      a go
                      Code:
                      msparks@localhost Development]$ cd way_test/
                      [msparks@localhost way_test]$ cc -o connect connect.c -lwayland-client
                      [msparks@localhost way_test]$ ls
                      connect  connect.c
                      [msparks@localhost way_test]$ ./connect
                      Can't connect to display
                      [msparks@localhost way_test]$​
                      Hmm, I think I might see the cause of the lack of 3rd party adoption.
                      Last edited by mSparks; 22 September 2023, 01:38 PM.

                      Comment

                      Working...
                      X