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
    Finally I won't need to have obs-studio-wayland and instead use obs-studio everywhere.

    Comment


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

      Comment


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

        Comment


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

          Comment


          • #15
            uid313 Then you need Sway, KDE and others to do something about it.

            Comment


            • #16
              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


              • #17
                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


                • #18
                  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.

                  Comment


                  • #19
                    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


                    • #20
                      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

                      Working...
                      X