Announcement

Collapse
No announcement yet.

OBS Studio Merges Its EGL-Wayland Code To Natively Support Wayland

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

  • #11
    Wow that's huge, please release a stable version ASAP.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #12
      And people keep saying this stuff isn't possible on Wayland...

      Comment


      • #13
        I'm really liking the momentum behind getting wayland support

        Comment


        • #14
          Is it using Pipewire for screen capture?

          Also, I hope the focus on OpenGL/EGL will switch to Vulkan/WSI in Wayland use cases.

          Comment


          • #15
            Originally posted by Vistaus View Post
            And people keep saying this stuff isn't possible on Wayland...
            This is the problem this is true that you cannot screen capture using Wayland protocol and deception at the same time.

            Points
            1) Wayland Protocol is designed to be between the compositor and the application. Not between application and screen/output.(this is a big difference)
            2) Wayland Protocol does not forbid applications from directly using libdrm and other direct access paths.
            3) DMA BUF is a file handle with permissions and this is what wayland on open source drivers is using to pass buffers around.
            4) Display to compositor is a DMA BUF with open source drivers.

            Can you see problem in these 4 points. Its really simple wayland compositor may not be able to screen capture at all because the DMA BUF it has been passed for the output screen give the compositor read permission also the DMA BUF from the applications to the compositor don't have to give the compositor read permissions. The compositor should be able todo it job with the metadata alone not reading the buffer contents. Since the wayland compositor may not have read permission it makes no sense to implement screen capture in the Wayland protocol at all.

            This is really the differences that wayland was being designed from the ground up to be more secure. This results that particular operations you should go outside the wayland protocol because parts using the wayland protocol may not have permission to perform the actions other wise.

            Yes just because something is impossible to-do in Wayland protocol does not mean that is the only way to perform that task. libdrm and eglstreams both can be used to screen capture by direct access. A direct access screen capture means you can capture the screen without care if X11, Wayland or a text based terminal is there. Why you are directly asking the GPU what in heck its putting on the screen by a DMA BUF/eglstream buffer with permission that your process can read it.

            We have had a very big tunnel vision problem with people repeatedly demanding that Wayland protocol should implement X features when X feature makes no sense at all to be in the Wayland protocol because it was designed to be secure and being secure means that feature cannot work that way because going though wayland protocol the permissions required to perform that task are not promised to be there. Yes there are other ways includes using the backend libraries the Wayland compositor itself would use where you can in fact ask for higher permissions.

            Yes screen capture the other way of going directly down to libdrm or eglstreams with a handler program to get you the higher privillage buffer acess is one option other using a third party like xdg-portal with pipewire both will allow screen capture.

            Its also like how do I global key capture its perfectly possible to capture the input device into Linux or freebsd in a generic way that does not depend on X11 or Wayland compositor running yet will work while they are running.

            Lot have got use to the X11 way that everything and the kitchen sink is in one thing. Wayland is not this so requires developers to think a bit differently most importantly not just throw up hands and say something impossible because the wayland protocol does not have that feature.


            Originally posted by shmerl View Post
            Is it using Pipewire for screen capture?
            There are two possible screen capture backed for Obs studio that work with wayland. Pipewire and a libdrm based one.

            Originally posted by shmerl View Post
            Also, I hope the focus on OpenGL/EGL will switch to Vulkan/WSI in Wayland use cases.
            That will be slow you are talking lots of code changes.

            Comment


            • #16
              Originally posted by 144Hz View Post
              oiaohm Your tunnel vision theory is spot on. Replacing old X features requires tons of developer resources. Ultimately not all DEs and WMs will make it to the post-X era.
              This is where things take a horrible turn for the worst for you arguement. Replacing old X features requires tons of developer resources is true. But you have overlooked something most of the parts you need to replace for wayland were in fact deprecated under X11 protocol almost a decade ago with a dbus interface yet there are still a lot of WM and DE under X11 not providing the new interfaces and worse as wine/Qt/Gtk.. quirk lists shows have not implemented even the deprecated X11 ones correctly.

              There is a lot of distribution hoping/DE and WM hopping that is caused by using parts that are under resourced for developers that have not even implemented the deprecated X11 parts correctly.

              So yes a lot of DE and WM really need to end of life and not make it to the post-X era. Yes due to the fact they are broken as applications update for Xwayland that are providing X11 protocol related parts correctly if it provides will result in newer versions of X11 applications tested with Xwayland working only on bare metal mostly with DE/WM for X11 that have Wayland support but having odd quirks on the DE/WM that have not done this because of the broken they have.

              144Hz X11 on bare metal is broken in many ways.

              1) X11 server on bare metal does not really have any funded developers.
              2) DE/WM that support X11 only most of them under closer inspection are broken and are causing distribution hopping and WM/DE hopping.

              Like it or not the fact that not all DE and WM will make into the post-X era is a good thing long term. Maybe some of the ones that die will pool their resources to make a Wayland compositor that has enough personal to-do the job properly?

              Comment


              • #17
                Originally posted by oiaohm View Post

                This is where things take a horrible turn for the worst for you arguement. Replacing old X features requires tons of developer resources is true. But you have overlooked something most of the parts you need to replace for wayland were in fact deprecated under X11 protocol almost a decade ago with a dbus interface yet there are still a lot of WM and DE under X11 not providing the new interfaces and worse as wine/Qt/Gtk.. quirk lists shows have not implemented even the deprecated X11 ones correctly.

                There is a lot of distribution hoping/DE and WM hopping that is caused by using parts that are under resourced for developers that have not even implemented the deprecated X11 parts correctly.

                So yes a lot of DE and WM really need to end of life and not make it to the post-X era. Yes due to the fact they are broken as applications update for Xwayland that are providing X11 protocol related parts correctly if it provides will result in newer versions of X11 applications tested with Xwayland working only on bare metal mostly with DE/WM for X11 that have Wayland support but having odd quirks on the DE/WM that have not done this because of the broken they have.

                144Hz X11 on bare metal is broken in many ways.

                1) X11 server on bare metal does not really have any funded developers.
                2) DE/WM that support X11 only most of them under closer inspection are broken and are causing distribution hopping and WM/DE hopping.

                Like it or not the fact that not all DE and WM will make into the post-X era is a good thing long term. Maybe some of the ones that die will pool their resources to make a Wayland compositor that has enough personal to-do the job properly?
                I fear this because all I want is a simple xfce / gnome 2 style DE again on wayland. I don't like tablet focus gnome which unfortunately has been the biggest funded and developed wayland and honestly x11 DE. I also don't like bloated KDE along with some keyboard focused tiling minimal thing like sway.

                I wish xfce received more funding and support. It's probably going to be years before it even gets basic wayland support if it gets wayland support at all.

                Comment


                • #18
                  Originally posted by fafreeman View Post
                  I fear this because all I want is a simple xfce / gnome 2 style DE again on wayland. I don't like tablet focus gnome which unfortunately has been the biggest funded and developed wayland and honestly x11 DE. I also don't like bloated KDE along with some keyboard focused tiling minimal thing like sway.

                  I wish xfce received more funding and support. It's probably going to be years before it even gets basic wayland support if it gets wayland support at all.
                  This is worse. xfce will need to pick up the pace on a lot of things like GTK 4.0 support. Xfce is not only lagging in Wayland support its lagging in using current versions of libraries what means it more open to security flaws.


                  Originally posted by 144Hz View Post
                  fafreeman That’s not going to happen. So far only GNOME has demonstrated the willingness and capabilities to reach the post-X era.
                  Sorry that is tunneled visioned on your part. KDE and sway/wlroots is showing good progress in that direction of post-X. Xfce does in fact depend on Gnome maintained and made parts and has been under resourced to keep up on that side.

                  The reality here items like xfce have not been in a healthy location for development or funding for quite some time.

                  Wayland change over really is just displaying existing problems that need fixing by either merging projects to increase resources in remaining projects or killing off projects or somehow finding more funding for them.

                  Comment


                  • #19
                    Originally posted by fafreeman View Post
                    I fear this because all I want is a simple xfce / gnome 2 style DE again on wayland. I don't like tablet focus gnome which unfortunately has been the biggest funded and developed wayland and honestly x11 DE. I also don't like bloated KDE along with some keyboard focused tiling minimal thing like sway.
                    GNOME Classic is the starting point.

                    Comment


                    • #20
                      Originally posted by 144Hz View Post
                      oiaohm KDE showing good progress? I see nothing but forks and weekly blogs about some unquantifiable “wayland improvements”.
                      This is shows you have not been reading. KDE what you hear talked about is KDE mainline and 1 fork KWinFT. Thing you have missed is if you take the lead developer of KWinFT and check is name against KDE mainline patches he is there. KWinFT is very much like the Wine staging branch for the mainline KDE because the improvements that work properly in KWinFT are moving mainline.

                      Quite a few of the wayland improvements are based on bugs if you get to the bugs you have the information to in fact quantify the improvements. Really 144Hz you are not putting in the effort to know how KDE is in fact going. Reporting always only part of the picture.

                      Comment

                      Working...
                      X