Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite …
Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite …
I have to use Slack for work and screen sharing doesn’t work when I’m using Wayland.
Don’t let Slack launch at startup. As long as it launches after pipewire - everything works. Your can also restart it to fix sharing issue, but that can be a birch if you already started a call.
Is there a way to control the launch order? I suppose you could also find a script that waits for a given process to be responsive before launching another, but I’m not sure where I’d insert that either.
(I’ve been using Ubuntu mostly out-of-the-box so far and just now started having the time and energy to start learning about and fiddling with the internals)
If it launches via a systemd service, you can perhaps edit the file such that it depends on Pipewire before it launches.
Or disable the built in startup support and create your own service that does the same.
I’m not sure that would work. Pipewire probably starts via system (just takes a while to become functional) and slack is started by KDE. I guess you could just add a delay to slack’s start, but I just start it by hand.
Starting by hand is fine and I do it with just about anything I need anyway (though I suspect there is still some startup bloat I’ll need to sort out, if I don’t set up an entirely new system somewhere down the line), but don’t underestimate my compulsion to automate what I can (or at least know how to).
I’m a sucker for automation for automation’s sake :D
Oh, thx for the tip!
Why? Why plasma nailed own screensharing to audio server? There already are wayland extensions for this.
Pioewire handles audio and video pipelines between applications.
So why Wayland instead of pipewire at all?
Because Pipewire only handles and understands media streams, so it can stream the output of a window or the whole desktop, but only because the Wayland compositor has already composed the windows and other data it gets from the application to a visual and hands the final result to Pipewire.
Which goes back to oroginal question. Why pipewire if there are already wayland extensions?
Because it is convenient for programs to use Pipewire for screensharing, as those programs can then also use the same Pipewire support for all their audio and webcam needs. Also Pipewire is good at multiplexing the various media streams.
I started running OBS with a virtual camera to do screen sharing. It is so much nicer to manage sharing with OBS than with Slack/Google Meet/Discord.
Oh, never heard of this, I will check it out thx.
Oh, that sounds like an interesting idea. Currently stuck with teams at work. Screen sharing does work under wayland. But definitely going to try this.
Try using XWayland video bridge. It should allow any XWayland apps to use screen sharing. Unfortunately most distros either don’t ship it yet or ship broken versions but you can download nightly Flatpaks from Gitlab CI
I’m not sure why, but every time I use XWayland Video Bridge (installed as of about 2 days ago so it should still be pretty new), I just end up with a black screen being broadcasted - not sure what could be causing that.
Thx!