Wayland: Screensharing is difficult to use #829
Labels
GNU/Linux
Issues affecting GNU/Linux
Comments
|
Can you get the crash backtrace, if you launch it from a terminal? |
|
I will try to do what you ask. I will have to re-install the 23.1.0 versions again, though. I'll do it as soon as I can, both with the deb and with the AppImage. As I wrote in my post, I had re-installed the 22.12.0 version, which does what it needs to do. |
|
@Alfagiovanni56 the only change from 2022.12.0 to 2023.1.0 is the update from Electron 21 to Electron 22 (with Chromium 106 -> 108 inside). In the past few versions Wayland support has gotten better in Electron, but as you mention it, it may have gone backwards this time with Electron 22. From a first look this could be related: electron/electron#36660 |
|
I have openend both the latest AppImage and the deb version from a terminal. Since I don't know how to save the terminal output into a file, I have made several sreenshots of the output, since after a while it didn't match one screen anynmore. For both the AppImage and the deb file there are 4 screens:
|
|
Sorry, closing the issue was a mistake. I wanted to close my post! |
|
I have the same behaviour on Fedora 37 + Wayland/Nvidia. I'm using the From the TRACE I can see some "Permission denied" on |
|
@goldyfruit goldyfruit I have tried all available versions, including flatpak. The deb and AppImage packages open and function normally and crash only when trying screen sharing. The Flatpak even refuses to start up. On clicking the Jitsi icon nothing happens! |
Exactly the same for me. |
|
The permission errors sound relevant. Please note the Flatpak version is a third-party build. We don't support that one ourselves. |
|
I am aware of the fact that Flatpak is third party. I just tried them all to compare their behaviour within a wayland session. Normally I use the deb version. |
|
I got this from my kernel log: Here is the generated Here is the generated |
|
I'm experiencing this issue on Arch Linux with Gnome 43.2 and Wayland. This is the output: |
csett86
added a commit
that referenced
this issue
Feb 3, 2023
|
This is now fixed by reverting back to electron 21. This is not a sustainable fix, as electron 21 is EOL around April this year, so we will need to find a way why this breaks in electron 22+ and how to fix it permanently. |
|
I'd say that is up to Electron to fix. We can't be beholden to an old Electron version because Wayland is broken. Long term, that is. |
|
Thx for taking care of this, even if - for the moment being - with a workaround. I hope it will give us (jitsi community, electron, ...) more time for permanent, future oriented solutions. I could be wrong and I am a relative outsider, but I have the impression that there could also be something in the relationship between Jitsi and Electron. I have other electron-based packages (e.g. Teams-for-Linux, which I use only if necessary to participate in meetings not organised by me) which allow screen sharing. Perhaps they are based on previous versions too. Anyhow, Electron should be (made) aware of this kind of problems with Wayland, in order to facilitate permanent solutions. |
|
Last reflection, following my previous mail. It could well be that the problem is not so much between jitsi and Electron or about Electron and Wayland, but more in particular between chrome-based browsers and Wayland. How else can we explain that in linux sessions with Wayland, Firefox allows screen sharing without any problem, but Brave and Google Chrome don't? That is one of the reasons why, as a user of Brave, at this moment I am so dependent on the Electron app and can't easily switch to the web version. |
|
When we say Electron bug we really mean a Chromium bug here :-) |
|
Exactly! |
|
I can confirm that this workaround (going back to Electron 21) allows sharing screen on Arch Linux. Let's hope screen sharing gets fixed in newer Electron versions before EOL. |
2 tasks
csett86
added a commit
that referenced
this issue
May 10, 2023
csett86
added a commit
that referenced
this issue
May 10, 2023
* chore(deps) update Electron to 24 * docs: document broken screensharing on wayland See #829 --------- Co-authored-by: Christoph Settgast <[email protected]>
|
As Electron 21 is EOL, we now have to upgrade. Unfortunately that means that screensharing is broken under wayland (segfaulting). Other electron apps are also affected, see electron/electron#37463 Only workaround is using X11 or a browser instead of the app under wayland. |
@saghul That upstream issue has been fixed! |
|
That won't solve the double dialogs IIRC. |
|
Ok, I've no idea where to put it best, so I'll just throw it into here for now. ATM I'm having the Electron Jitsi-Meet in version I can successfully share my screen (no need for a rush in any of the dialogs (as suggested somewhere above), full screen or individual window.
Now, with the above steps to reproduce I can share my window, but the log will be constantly spammed with stuff like this: And sometimes these: But the actually really annoying thing for me is that Jitsi crashes on me, anytime I click abort on the pipewire dialog.
It will just have the following line as last in the log and be gone: From the outside that feels a bit like the dialog is triggered and when it comes back with a null, there's some whole in the error handling for this, once the callback hits. I hope this is in the jitsi-meet code and can be fixed on your end 🙏 and not somewhere upstream in electron 😬 Logs: |
saghul
added a commit
to jitsi/jitsi-meet-electron-sdk
that referenced
this issue
Feb 13, 2025
saghul
added a commit
to jitsi/jitsi-meet-electron-sdk
that referenced
this issue
Feb 13, 2025
saghul
added a commit
to jitsi/jitsi-meet-electron-sdk
that referenced
this issue
Feb 13, 2025
|
This is now fixed in release 2025.2.0, but it still needs a matching version of the Jitsi Web release. At this moment supported on alpha.jitsi.net, I will update here once also released via jitsi stable |
|
Todays jitsi-meet web stable release (2.0.10073) now also supports everything required to make the new wayland flow working: https://github.com/jitsi/jitsi-meet-release-notes/blob/master/CHANGELOG-WEB.md#2010073-2025-02-27 |
|
still doesn't work for me: jitsi-meet-electron version is 2025.2.0 |
|
I also just tested it with the Flathub Version (2025.2.0), and I can still crash it by canceling the Pipewire dialog and still get those dialogs multiple times. Attached is a log. |
|
Those are PipeWire bugs, alas. On Arch and latest Ubuntu you'll get the (native) dialog twice, but it will work and cancelling doesn't crash. |
|
and what about my case? |
|
Yeah well I can't really see how that should be a Pipewire issue? If I use Jitsi in the Browser, I only get the Pipewire dialog to share the screen and I can cancel that dialog just fine without crashing the Browser, the tab or the meeting. If using the electron based client, I get a custom dialog + the Pipewire dialog. Also, that the Jitsi Electron client crashes if the Pipewire dialog is canceled, seems like a not sane handling if the Pipewire dialog is not exited with a share, but a cancel 🤷 |
You won't be getting the custom dialog if you are using the latest version of Jitsi Meet Electron while also using the latest Jitsi Meet stable release. You need both.
We don't invoke PipeWire directly, but by using the |
Can you try to run it without any flags? |
|
Ah, the server plays a role in this too? 🧐
Then...It's neither a Pipewire nor Jitsi Bug, but one in Electron that it crashes on cancelation? |
What kind of environment is that? X11 or Wayland? |
|
Wayland of course, as this issue is about wayland (: |
Yeah, that explains.
I saw some of those crashes that went away after updating PipeWire on Arch so I suspect some combination of PipeWire verion(s) with Electron... |
Weird that the failing component has x11 in the name. Do you have the |
|
|
Really weird, it seems like wayland is not being properly detected because it seems to start in X11 mode. This is where the error originates: https://chromium.googlesource.com/chromium/src/+/e81f6a2c0d78c2208bf2a63cbf3afdb5ab4ffbfd/ui/ozone/platform/x11/ozone_platform_x11.cc#167 |
|
Looking at electron/electron#44607 it seems like XWayland is still the only reasonable way :-/ Which I suppose if how I ran my test, unknowingly. At least SS works now with the portal 😅 |
|
but jitsi works fine for me on wayland-only environment started with |
|
🙃 I don't know what to say. There is nothing else that I know we can apply that would fix anything. What we changed for SS is to use the same API that the normal browser users, and in case of Wayland, completely bypass our logic and let the PipeWire portal take care of it, to avoid the double dialogs.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.
Description
I had installed the newest version of jitsi-meet-electron 23.1.0 ([jitsi-meet-amd64.deb) on my machine (Ubuntu 22.04). Within a wayland session - which is default on Ubuntu 22.04 - the app crashes whenever one tries screen sharing. I had a frozen image once, but most of the time the app simply closes down. I have also tried to install the latest AppImage, which causes exactly the same type of crash.
When opening an online session on Brave or Chrome, screen sharing is simply impossible within a Wayland session, with the single exception of other browser pages in Brave resp. Chrome. Finally even the Firefox (snap) crashes in a Wayland session when one tries to share a screen.
Unfortunately, this makes it almost impossible for me to use the latest versions of the electron app. Therefore I have decided to re-install the 22.12.0 version for the time being. I hope that it will be possible to reproduce the problem and to of course to resolved it as soon as possible.
My machine is an Ubuntu 22.04.1, Gnome 42.5 and Wayland.
Current behavior
App crashes on screen sharing: closes down unexpectedly.
Expected Behavior
Share one's screen going through the normal procedure / choices (whole screen or window etc...
Possible Solution
???
Steps to reproduce
Start session on ubuntu 22.04 / wayland and try screen sharing. Compare with an Xorg session
Environment details
The text was updated successfully, but these errors were encountered: