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

  • oiaohm
    replied
    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.

    Leave a comment:


  • shmerl
    replied
    Is it using Pipewire for screen capture?

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

    Leave a comment:


  • 144Hz
    replied
    uid313 Then you need Sway, KDE and others to do something about it.

    Leave a comment:


  • lyamc
    replied
    I'm really liking the momentum behind getting wayland support

    Leave a comment:


  • Vistaus
    replied
    And people keep saying this stuff isn't possible on Wayland...

    Leave a comment:


  • darkbasic
    replied
    Wow that's huge, please release a stable version ASAP.

    Leave a comment:


  • juxuanu
    replied
    Finally I won't need to have obs-studio-wayland and instead use obs-studio everywhere.

    Leave a comment:


  • StanGenchev
    replied
    Originally posted by uid313 View Post
    This sounds like a difficult application to get working on Wayland because it needs to be able to find what other windows/applications are running, and then sneak on them so it can live stream those, and Wayland prevents applications from spying on other applications.
    Also you might want to have some key bindings to control OBS Studio while using other applications, and Wayland doesn't allow applications to listen for keypresses in other applications.
    It's not difficult. Roughly speaking, everything that is possible in X11 is possible on Wayland. The 'problem' is that with Wayland you have to have the proper permissions from the system and/or user and to use different tools/libraries as some of the functionality in X11 was moved out of the compositor/wm. For screen recording/sharing, you have to use pipewire and xdg-portal. Those are standards across all Wayland compositors. If you need to monitor all keyboard/mouse events, then you have to go lower in the stack then before and use for example evdev (AS a python dev I use python-evdev). Of course the app has to have the proper permissions. That is key and one of the most important reasons why X.org devs created Wayland in the first place.

    Leave a comment:


  • treba
    replied
    Originally posted by uid313 View Post

    Yeah, but if you rely on APIs from the compositor you might end up with a application that only works on that compositor, example it only works on GNOME Shell, but not on KDE or Sway.

    Yeah, you want global hotkeys so that while you are live streaming maybe a game, you can tell streaming application to lower or raise the volume, the mute or unmute the microphone, or skip to the next song. I don't think there is any universal way to do it.
    It relies on xdg-portal, which is a cross compositor standard, even if independent of Wayland. KDE and sway both support it, even if not as mature yet as Gnome. See https://github.com/flatpak/xdg-desktop-portal

    Leave a comment:


  • uid313
    replied
    Originally posted by treba View Post

    It's actually not that tricky - it just has to use the right APIs from the compositor instead of spying. A plugin for that has been around for a while from the same programmer (feaneron) and he uses it for his livestreams. Not sure about the global hotkey situation, maybe still needs a proper solution.

    Edit: https://gitlab.gnome.org/feaneron/obs-xdg-portal/
    Yeah, but if you rely on APIs from the compositor you might end up with a application that only works on that compositor, example it only works on GNOME Shell, but not on KDE or Sway.

    Yeah, you want global hotkeys so that while you are live streaming maybe a game, you can tell streaming application to lower or raise the volume, the mute or unmute the microphone, or skip to the next song. I don't think there is any universal way to do it.

    Leave a comment:

Working...
X