Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken screen sharing on Linux Wayland #18607

Closed
vchernin opened this issue Aug 17, 2021 · 11 comments · Fixed by element-hq/element-desktop#256
Closed

Broken screen sharing on Linux Wayland #18607

vchernin opened this issue Aug 17, 2021 · 11 comments · Fixed by element-hq/element-desktop#256
Assignees
Labels
A-Electron A-VoIP O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect Z-Platform-Specific

Comments

@vchernin
Copy link

vchernin commented Aug 17, 2021

Steps to reproduce

  1. Try to screen share on Linux Wayland with the new 1:1 calling feature.

What happened?

Sharing the full screen or most apps will not work. You might in some cases be able to share other xwayland Chromium based apps, but that's a guess at best. This issue is not about group calls with embedded Jitsi, that is broken in all Element desktop builds due to element-hq/element-desktop#683.

What did you expect?

Chromium and Electron apps like Element currently require passing --enable-features=WebRTCPipeWireCapturer at runtime to enable PipeWire screen sharing on Wayland. This isn't something most users will know exists, so screen sharing will simply be assumed to be broken with Element on Wayland.

Element should enable this flag at build time so .DEB and Flatpak users can screen share. Jitsi meet electron did so here (not the Jitsi embedded in Element, just a seperate Electron Jitsi package).

As far as I've seen, this flag does not cause regressions for X11 users. The expererience with it on Wayland can sometimes have issues, but I think mostly working screen sharing on Wayland by default is better than hardly anything at all.

One issue I noticed is Element seems to have a similar problem as Jitsi Meet Electron, where the preview image is broken even though the share button works.

As discussed extensively here, when on Wayland, devices with dedicated gpus (notably AMD) might experience segfaults when using experimental (not fully enabled by default in any distro I know of) DMA-BUF PipeWire screencasting. Since DMA-BUF screencasting will not be fully enabled by default until issues discussed there are fixed, I don't see this as blocking for Element.

Operating system

Linux

Application version

Element version: 1.8.1 Olm version: 3.2.3

How did you install the app?

Flatpak, will affect DEB as well.

Have you submitted a rageshake?

No

@SimonBrandner SimonBrandner self-assigned this Aug 18, 2021
@SimonBrandner SimonBrandner added A-Electron A-VoIP O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround Z-Platform-Specific labels Aug 18, 2021
@SimonBrandner
Copy link
Contributor

@vchernin, I've submitted element-hq/element-desktop#256. I don't have a Wayland setup, so I can't really test this. In case you were able to try out the PR yourself and test it, it would be great. But don't worry about it if you don't know how to compile Element desktop/don't have time for it

@vchernin
Copy link
Author

@SimonBrandner wow thanks for doing this so quickly! I do think your fix should work given it's the same as Jitsi's.

I tried using recent work in Flatpak to build from source, but that wasn't as trivial I was hoping for. And I tried reading over the build instructions, but that might take me some time to figure it out...

If anyone who is more familar with Electron can build this and try it out on Wayland please do. And then this should be mergeable :)

@dbkr
Copy link
Member

dbkr commented Aug 18, 2021

I've merged the PR so this will be in tomorrow's nightly if you could give it a test. Follow instructions on https://element.io/get-started but instead of https://packages.riot.im/debian/, use https://packages.riot.im/nightly/ or just grab a deb from there for a one-off non-updating build).

@dbkr dbkr reopened this Aug 18, 2021
@dbkr
Copy link
Member

dbkr commented Aug 18, 2021

Re-opening since it's untested - let's close this once we know it works.

@SimonBrandner
Copy link
Contributor

I've merged the PR so this will be in tomorrow's nightly if you could give it a test. Follow instructions on element.io/get-started but instead of https://packages.riot.im/debian/, use https://packages.riot.im/nightly/ or just grab a deb from there for a one-off non-updating build).

You should also be able to do sudo apt install element-desktop-nightly (if on Debian)

@vchernin
Copy link
Author

You should also be able to do sudo apt install element-desktop-nightly (if on Debian)

I'm not actually on Debian, but I can easily test this in a VM when it's ready.

@vchernin
Copy link
Author

So I tested the current nightly build (to confirm what happens before the flag was added). But in a Ubuntu 21.04 VM I can't start video calls due to no camera access, I'm sure it's possible to pass it through somehow but that seems overkill. Is there a trick to override this error?
image

Otherwise I'll just try in a live usb on real hardware.

@SimonBrandner
Copy link
Contributor

SimonBrandner commented Aug 18, 2021

Is there a trick to override this error?

Not without tempering with the code, live USB is probably the easiest way

@SimonBrandner
Copy link
Contributor

But you should be able to screen-share in voice calls if both sides support it

@vchernin
Copy link
Author

Not without tempering with the code, live USB is probably the easiest way

Thanks, will do.

But you should be able to screen-share in voice calls if both sides support it

Yeah, I'll just use my phone with latest stable Element as that already worked when I tried with stable Flatpak.

@vchernin
Copy link
Author

vchernin commented Aug 19, 2021

@SimonBrandner I've just tested build element-nightly-2021081901_amd64 and it works exactly as hoped! This issue can be closed.

Further info:
I had to install Debian on a spare laptop, couldn't find a live DEB-based distros with a live Wayland environment.

The UX isn't perfect (as mentioned above) but it's much better than nothing. I'll open a follow up issue for improving that.

Thanks again!

vchernin added a commit to vchernin/im.riot.Riot that referenced this issue Aug 19, 2021
-Don't need module since Element builds against Electron 13, which supports PipeWire 0.3
-PipeWire 0.3 is included in the runtime.
-Mentioning the flag in the metainfo descrption will be redundant as of the next Element release, see element-hq/element-web#18607
su-ex pushed a commit to flathub/chat.schildi.desktop that referenced this issue Sep 13, 2021
-Don't need module since Element builds against Electron 13, which supports PipeWire 0.3
-PipeWire 0.3 is included in the runtime.
-Mentioning the flag in the metainfo descrption will be redundant as of the next Element release, see element-hq/element-web#18607
su-ex pushed a commit to flathub/chat.schildi.desktop that referenced this issue Sep 13, 2021
-Don't need module since Element builds against Electron 13, which supports PipeWire 0.3
-PipeWire 0.3 is included in the runtime.
-Mentioning the flag in the metainfo descrption will be redundant as of the next Element release, see element-hq/element-web#18607
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Electron A-VoIP O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect Z-Platform-Specific
Projects
None yet
3 participants