cancel
Showing results for 
Search instead for 
Did you mean: 

[Linux] Regarding Nvidia+Xwayland/Wayland

lolsniperftw
Listener

Hello,

 

I have opened a ticket regarding an issue I had with Zoom crashing on Nvidia when using Wayland session (and also at the same time filing a bug to Nvidia https://github.com/NVIDIA/egl-wayland/issues/63 in which I discovered it is an issue on Zoom's end). The reason I am trying to use on Wayland is because Xwayland is showing a blank window when opened (which turns out is an issue on Zoom's end as well).

 

The support representative I talked to in the ticket was helpful and tried to get a response from the engineering team (which never came) regarding the response I received from Nvidia in the github issue I linked here.

 

Direct link to the response I received from Nvidia: https://github.com/NVIDIA/egl-wayland/issues/63#issuecomment-1204312146

 

So I am raising it here as well just in case it can lead to a more helpful response. I am not expecting an ETA of course but just acknowledgement that it is being worked on.

38 REPLIES 38

JPLeB
Listener

I'm experiencing this issue as well. Zoom needs to upgrade its version of Qt from 5.12 to 5.13. As is, they're shipping an old buggy version of this library to users, which might have other issues besides this one.

Another thread where people have reported this same issue:

https://community.zoom.com/t5/Meetings/The-latest-Zoom-client-not-start-on-Linux/m-p/70035

 

Looking at when the fix was merged to Qt, it seems the appropriate version should be 5.15 and not 5.13.

So I did more digging into QtWayland and QtWebEngine source code and it seems that implementing the fixes to Zoom will be more complicated unless they skip ahead to Qt version 6.3.

 

The QtWayland PR only begins to appear in 5.15 : https://github.com/qt/qtwayland/blob/5.15/src/client/qwaylandwindow.cpp#L251

 

and the Chromium PR that made it into QtWebEngine only made it in 6.3: https://github.com/qt/qtwebengine-chromium/blob/9a8385241542eaad285501be6dc66d96a76c20aa/chromium/co...

 

JPLeB
Listener

Fellow "video application used by millions of people" OBS recently upgraded to Qt version 6: https://github.com/obsproject/obs-studio/discussions/6481

 

Seems good to not be stuck on a deprecated version of a GUI library. I hope this is in the works at Zoom.

Yeah I know about that.

OBS were always up to date regarding the Qt version I believe.

I will be surprised if Zoom makes the jump from 5.12 to version 6 but it is required to get everything to work unless they backport some of the changes to the version they use.

gameking505
Listener

I've been having an issue with Zoom crashing and I finally landed on this thread to find the root cause. This is disappointing. Seems like nvidia users on wayland are out of luck if we want to use Zoom.

 

lolsniperftw - let me know if you ever found a workaround

daveman1010220
Listener

Is there any work-around that will help a Linux+Wayland+Nvidia user to work with Zoom at this time?

Nope.
Right now you can either switch to X11 or use Zoom on the browser (Firefox should work fine afaik).

Thanks for the info. I'll try the browser. There are good reasons to begin switching over to Wayland. Zoom is the only application that is giving me any problems, so I can't justify not switching anymore.

gameking505
Listener

The latest update to Zoom seems to not instantly crash, which is an improvement from earlier. Was there some sort of update that addressed the Qt issue?

 

Unfortunately for me, the application is unbearably slow to respond, so something odd is still going on. 

Yeah there was an update to Zoom that fixed both Zoom crashing on native Wayland and blank window in Xwayland. The application is also very slow to respond here in native Wayland and in Xwayland it is sometimes crashing when joining a meeting.

Some updates:

Native Wayland client slowness is expected for the time being because they cannot update Qt further due to old distributions that they still need to support so they recommend to use it on XWayland.

 

Did you try to run it on XWayland? For me it mostly works but sometimes it can crash when joining a meeting. Does it happen for you too?

 

I can try... but I don't actually know how to force zoom to use xwayland...

Xwayland is the default. Are you on a laptop or desktop?

gameking505
Listener

I'm on a desktop, using a gtx 1080.

 

Zoom works for now, but it is very slow, and weirdly the window only visually updates while my mouse is moving over it. Super odd.

That is  because you probably launched it in Wayland mode instead of Xwayland(which is the default).

As far as I know I'm just using the default settings - but where would I change back to xwayland? Is there a startup flag or a config file somewhere?

Xwayland is the default. How do you launch Zoom right now?

I launch via Rofi or sometimes dmenu. 

Weird. Do you have xeyes installed? It will be able to tell you if it is running under Xwayland or Wayland (If the eyes follow the cursor when you move the cursor over Zoom then it is Xwayland)

No movement with xeyes so I'm pretty sure it's running under Wayland. How do I run it under xwayland?

What is the content of the Exec line in Zoom.desktop? (It should be located in /usr/share/applications/)

/usr/bin/zoom %U

Ok so it is not that. What is the content of /etc/environment file?

That file is empty (besides comments), however I did just recall that I had a few environment variables set up in my Sway launch script from trying to get Zoom working a while back that may be affecting things.

export QT_QPA_PLATFORMTHEME=qt5ct
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_AUTO_SCREEN_SCALE_FACTOR=1
export QT_QPA_PLATFORM=wayland

 

Yeah the last line is forcing it to use Wayland

Did it work now?

Unfortunately no... it still seems to launch in Wayland mode even after commenting out those lines in my startup script.

Something is forcing it to launch in Wayland mode

Evidently so... but I am unable to tell what. I even nuked the zoom.conf and zoomus.conf files and it still launches in wayland... not sure what's up there. Guess I'll wait for a future update to sort things out before I switch fully to Sway.

Maybe rofi or dmenu have exports of env variables?

Nope - nothing going on with rofi/dmenu as far as I can tell. And I get the same outcome when just running the Zoom command via the terminal.

 

I do have the following env variables in my Sway launch script:

export SDL_VIDEODRIVER=wayland
export WLR_NO_HARDWARE_CURSORS=1
export SDL_VIDEODRIVER=wayland
export _JAVA_AWT_WM_NONREPARENTING=1
export XDG_CURRENT_DESKTOP=sway
export XDG_SESSION_DESKTOP=sway

As far as I know, these are all needed to actually get Sway to launch with an nvidia card? When I set up my Sway install I pulled these out of the wiki. Could these be creating an issue?

Maybe export SDL_VIDEODRIVER=wayland ?

Sadly no dice. I've disabled literally all of the variables in the script just to check, and Zoom still starts in wayland native mode rather than xwayland. Not sure what I can do to force it to use xwayland but for now it's unusable in native Wayland - mega slow and the window only updates while the mouse is moving.

I am out of ideas as well.

Sadly support told me that updated Qt 6 is not planned atm because they want to support older distros.

running with env -u WAYLAND_DISPLAY forces x and fixed this issue for me. you can change the exec line in your Zoom.desktop to env -u WAYLAND_DISPLAY /usr/bin/zoom %U

This worked for me, you are a lifesaver. The application crashes intermittently during meetings which is annoying; but at least that's a separate issue.