4 ms·

> breaking screen recording/sharing etc That's a scary one IMO. I mean, if you are a dev who has devoted an enormous amount of your efforts into making a repl

> breaking screen recording/sharing etc That's a scary one IMO. I mean, if you are a dev who has devoted an enormous amount of your efforts into making a replacement for the stuff that displays all the stuff from all the other GUIs, seems like the identity function would be recording the shit you're displaying. The fact that OBS doesn't yet work under Wayland makes me wonder if sufficient (or any) dogfooding is going on. It'd be like if in the 90s you still couldn't easily compile code from inside Emacs. It's a smell.

cycloptic 6y ago
If you're noticing something that seems strange like that I would say do a thorough check to make sure you don't have some misinformation, there's a lot of bunk that goes around on social media. OBS is working but is not fully tested yet: https://github.com/obsproject/obs-studio/pull/2484/ https://github.com/obsproject/obs-studio/pull/2484/ (Disclaimer: I did some of the work on this port)
- jancsika 6y ago
  What's the relevance of the open bug report to what I wrote? For the record: * I'm running Debian bullseye * I'm running Gnome version 3.38.2 * I'm running OBS installed from apt: version 26.0.2+dfsg1-1+b1 (64 bit) Given a poster on this thread boldly claims that "Wayland is already done and ready," I'd say my setup is more than recent enough to test whether that claim is indeed usable in practice. Lo and behold, when I run OBS I get a blank screen staring back at me. If I log back in with Gnome running under X11, OBS works just fine. It's wonderful that the issue is being addressed, and I thank you for your work on it. But my point is that Wayland+OBS working together is a litmus test. The fact that the two are just beginning to play well is a big red light to me switching away from X11 any time soon. Anyway, that "done and ready" quote is really the source of my frustration. If I have to set an arbitrary timeout after a "loaded" event to get it to work properly, "loaded" is a probably misnomer.
  - cycloptic 6y ago
    You need to use that PR (and the right capture plugins) if you want native Wayland support, it's not merged yet. If you'd like to help move things along, please help test from git. I can give you more info on how to do this if you'd like. Even if this is merged it may be a while before it lands in debian testing.
  - kaba0 6y ago
    If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo. Screensharing/recording works on wayland (that is, there are extensions supporting it). Clients are slower to adapt, but once stable chromium does, a major pain point in client availability will be solved (I mean electron apps)
    - jancsika 6y ago
      > If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo. We're talking about two different things. You're talking about whether Wayland devs are ready for other devs to start leveraging their work. I'm talking about whether any Wayland-based distro is ready for a stable release. Clearly none are if a best-in-class screen recorder just gained the ability in a dev branch to recorder the screen under Wayland. Ubuntu understands what I'm talking about-- 20.04 is not Wayland-based, and I doubt it took look for them to make that decision. Whether best-in-class applications run correctly under Wayland is a perfectly reasonable and practical metric for Wayland's current value to users.
      - kaba0 6y ago
        Well, it is a difficult question as linux is a bazaar-style ecosystem and while apple can change something fundamental at a whim, every significant change in linux will result in a split of the community (with different ratios) and the ‘winner’ will slowly swallow the other. But still then, noone has the incentive in open-source to start porting their app (and usually, since the new thing will be a smaller community at first, it creates a negative feedback loop) - fortunately those that depend on frameworks more often than not can simply be started in wayland mode and no change is required by the maintainer. For more special clients (like a screen reader) you will need more time as these programs require special handling by the compositor so one has to create an extension for that and a/some DE should implement it then. It will take some time and maybe some niche program that relied heavily on the X implementation will never be ported, or will have to be recreated with wayland in mind (I mean those scripting little programs that read what is under the cursor and the like) Also, most DEs have really good backwards compatibility thanks to xwayland - because frankly some app will never be ported. (Also, accessibility is unfortunately quite the last thought on even paid platforms - and last I heard it was not all that great to begin with on linux)
- shmerl 6y ago
  Will OBS use pipewire for screen capture on Wayland?
Blikkentrekker 6y ago
It breaks everything of the sort. On X11, a client can view the contents of any arbitrary window, simulate input, read input — this is necessary obviously for screen sharing applications; though one can argue that maybe a permission model needs to exist to allow some clients to run with lower privileges — the funny thing is that it does; it's called te XSECURITY extension, it's very easy to use, and seldom used for whatever reason though SSH uses it whenever it can. On Wayland, no client can do such things, but many clients such as screen sharing tools, profiling tools, and whatever else that needs to simulate input and read surfaces obviously needs to. Wayland developers simply say “It must be built into the compositor”, but no compositor can be expected to provide all that, and no compositor does.
- cycloptic 6y ago
  The reason XSECURITY is not used is because it's not a real client API and it breaks applications. All it can do is force certain protocol requests to error out or return garbage data. In wayland the security method has moved towards asynchronously showing a dialog asking for permission. It's not feasible to modify the X11 protocol to have it do that without causing more breakage in applications. >no compositor does This is not correct. GNOME's compositor actually does support screen sharing, sharing of individual surfaces, and simulated input. And I'm not entirely sure what you mean by profiling tools, can you elaborate?

cycloptic 6y ago

If you're noticing something that seems strange like that I would say do a thorough check to make sure you don't have some misinformation, there's a lot of bunk that goes around on social media. OBS is working but is not fully tested yet: https://github.com/obsproject/obs-studio/pull/2484/ https://github.com/obsproject/obs-studio/pull/2484/ (Disclaimer: I did some of the work on this port)

jancsika 6y ago
What's the relevance of the open bug report to what I wrote? For the record: * I'm running Debian bullseye * I'm running Gnome version 3.38.2 * I'm running OBS installed from apt: version 26.0.2+dfsg1-1+b1 (64 bit) Given a poster on this thread boldly claims that "Wayland is already done and ready," I'd say my setup is more than recent enough to test whether that claim is indeed usable in practice. Lo and behold, when I run OBS I get a blank screen staring back at me. If I log back in with Gnome running under X11, OBS works just fine. It's wonderful that the issue is being addressed, and I thank you for your work on it. But my point is that Wayland+OBS working together is a litmus test. The fact that the two are just beginning to play well is a big red light to me switching away from X11 any time soon. Anyway, that "done and ready" quote is really the source of my frustration. If I have to set an arbitrary timeout after a "loaded" event to get it to work properly, "loaded" is a probably misnomer.
- cycloptic 6y ago
  You need to use that PR (and the right capture plugins) if you want native Wayland support, it's not merged yet. If you'd like to help move things along, please help test from git. I can give you more info on how to do this if you'd like. Even if this is merged it may be a while before it lands in debian testing.
- kaba0 6y ago
  If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo. Screensharing/recording works on wayland (that is, there are extensions supporting it). Clients are slower to adapt, but once stable chromium does, a major pain point in client availability will be solved (I mean electron apps)
  - jancsika 6y ago
    > If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo. We're talking about two different things. You're talking about whether Wayland devs are ready for other devs to start leveraging their work. I'm talking about whether any Wayland-based distro is ready for a stable release. Clearly none are if a best-in-class screen recorder just gained the ability in a dev branch to recorder the screen under Wayland. Ubuntu understands what I'm talking about-- 20.04 is not Wayland-based, and I doubt it took look for them to make that decision. Whether best-in-class applications run correctly under Wayland is a perfectly reasonable and practical metric for Wayland's current value to users.
    - kaba0 6y ago
      Well, it is a difficult question as linux is a bazaar-style ecosystem and while apple can change something fundamental at a whim, every significant change in linux will result in a split of the community (with different ratios) and the ‘winner’ will slowly swallow the other. But still then, noone has the incentive in open-source to start porting their app (and usually, since the new thing will be a smaller community at first, it creates a negative feedback loop) - fortunately those that depend on frameworks more often than not can simply be started in wayland mode and no change is required by the maintainer. For more special clients (like a screen reader) you will need more time as these programs require special handling by the compositor so one has to create an extension for that and a/some DE should implement it then. It will take some time and maybe some niche program that relied heavily on the X implementation will never be ported, or will have to be recreated with wayland in mind (I mean those scripting little programs that read what is under the cursor and the like) Also, most DEs have really good backwards compatibility thanks to xwayland - because frankly some app will never be ported. (Also, accessibility is unfortunately quite the last thought on even paid platforms - and last I heard it was not all that great to begin with on linux)
shmerl 6y ago
Will OBS use pipewire for screen capture on Wayland?

Blikkentrekker 6y ago

It breaks everything of the sort. On X11, a client can view the contents of any arbitrary window, simulate input, read input — this is necessary obviously for screen sharing applications; though one can argue that maybe a permission model needs to exist to allow some clients to run with lower privileges — the funny thing is that it does; it's called te XSECURITY extension, it's very easy to use, and seldom used for whatever reason though SSH uses it whenever it can. On Wayland, no client can do such things, but many clients such as screen sharing tools, profiling tools, and whatever else that needs to simulate input and read surfaces obviously needs to. Wayland developers simply say “It must be built into the compositor”, but no compositor can be expected to provide all that, and no compositor does.

cycloptic 6y ago
The reason XSECURITY is not used is because it's not a real client API and it breaks applications. All it can do is force certain protocol requests to error out or return garbage data. In wayland the security method has moved towards asynchronously showing a dialog asking for permission. It's not feasible to modify the X11 protocol to have it do that without causing more breakage in applications. >no compositor does This is not correct. GNOME's compositor actually does support screen sharing, sharing of individual surfaces, and simulated input. And I'm not entirely sure what you mean by profiling tools, can you elaborate?