search

flathub / us.zoom.Zoom

https://flathub.org/apps/details/us.zoom.Zoom
36 stars 48 forks source link

Wayland platform not available #24

Open heftig opened 5 years ago

heftig commented 5 years ago

If the host has QT_QPA_PLATFORM=wayland, Zoom will fail to launch and dump core, as the Wayland platform plugin is not available.

Maybe the flatpak should set QT_QPA_PLATFORM=xcb?

nedrichards commented 5 years ago

hrm, that makes sense. it's irritating since we specifically don't offer wayland support to the sandbox. if you want to provide a patch to the manifest I'd happily look at it.

prometheanfire commented 5 years ago

You could also compile zoom / the qt libs with wayland support enabled. Not sure how ready zoom is for wayland, but you could use https://github.com/webcamoid/webcamoid as an example of webcams in qt/wayland. Window sharing is the only thing that I suspect would be difficult (as that's a recent protocol within wayland iirc).

TheFrozenFire commented 5 years ago

I'm looking into this (and isolating Zoom in general), and some resources that may help are:

In general, it seems that the way forward would be to leverage portals to access specific resources, instead of promiscuously accessing lower-level devices directly.

nanonyme commented 5 years ago

@nedrichards I would propose instead preventing QT_QPA_PLATFORM from leaking to guest without explicitly overridden until there's proper Wayland support. This can be done by unsetting in manifest.

alatiera commented 4 years ago

Whoops, small typo in the MR above, meant to close #160 instead, got confused by Jan's Avatar opening both :D

heftig commented 4 years ago

Can you reopen this one, then? QT_QPA_PLATFORM still leaks into the sandbox and prevents Zoom's Qt from initializing.

ids1024 commented 4 years ago

I suppose compiling a copy of qtwayland (with the exact same qt version zoom is using) and adding it to the flatpak would probably be possible, but asking for weird issues?

prometheanfire commented 4 years ago

zoom would have to link with it, but I don't think it'd cause any issues offhand. It'd be good for performance reasons (no need to copy video buffers from the virtual x server to wayland).

There still needs to be support for desktop sharing on wayland, but that's something that just came out upstream dev wise (xdg-desktop-portal).

WhyNotHugo commented 4 years ago

@prometheanfire Screen sharing doesn't work anyway. Zoom runs through XWayland, and screen sharing just shared a black screen.

prometheanfire commented 4 years ago

that's my point :P build with wayland enabled and maybe build with xdg-desktop-portal support and you will be much of the way to full wayland support.

prometheanfire commented 4 years ago

that's my point :P build with wayland enabled and maybe build with xdg-desktop-portal support and you will be much of the way to full wayland support.

heftig commented 4 years ago

I'm pretty sure nobody who contributes to this repository has access to the Zoom source code.

ids1024 commented 4 years ago

I think the way QT works, back-ends like Wayland are provided through a plug-in architecture. So, it would simply be necessary to compile qtwayland, with a matching version number, and place it in the right path to be found by Zoom's QT version.

Of course, I have no idea if this might lead to weird issues of some kind or another.

Edit: That presumably wouldn't allow screen capture though; the program would have to specifically be written to support that.

prometheanfire commented 4 years ago

that's my point :P build with wayland enabled and maybe build with xdg-desktop-portal support and you will be much of the way to full wayland support.

WhyNotHugo commented 4 years ago

Yeah, it's easy to re-build Zoom with Qt's Wayland support enabled.

However, nobody on this discussion has access to Zoom's code or pipelines in order to do this. Go and open a support ticket with Zoom asking them to fix it. If they get enough requests asking the same thing, they might listen and fix their stuff.

You can open a support request here. Feel free to copy-paste:

When you guys make the Linux builds, it seems that you're disabling the Wayland backend for Qt.

Wayland is the graphical system on Linux (eg: the part that does all the drawing of windows on screen, input handling, etc).

Since you disable this, Zoom runs under Xwayland / in Xorg mode. Xorg is the previous Linux graphical subsystem, and doesn't support everyday things like scaling on hidpi displays.

Because of this, Zoom is super blurry on Linux -- simply because a small window is rendered internally, and then stretched.

As an end-user, there's nothing I can do around this; but it's very simple for you guys to work around this; just enabled the Wayland backend for your Linux builds (I'm sure your devs can get this through in no more than 1-2 hours).

I'm including a screenshot of Zoom next to your website, so you can see how absurdly blurry it looks - it's even worse on smaller highdpi screens.

In the meantime, let's please limit discussion here to things that can be patched by us on the flatpak package.

alatiera commented 4 years ago

However, nobody on this discussion has access to Zoom's code or pipelines in order to do this.

Agreed, but even if we did, it would be irresponsible to just downstream patch or rebuild something and invalidate the QA upstream does.

WhyNotHugo commented 4 years ago

invalidate the QA upstream does

I don't have the impression they QA Linux much, if at all. The amount of bugs on basic things there are is just ridiculous.

ids1024 commented 4 years ago

It seems to be fairly easy to get it to use the QT libraries from org.kde.Platform instead Zoom's versions: https://gist.github.com/ids1024/49edd39d6810386be7911d2d732704e2

It runs without error on Wayland... but for some reason it doesn't seem to be creating a window. I don't know what would cause that, or if I'm doing anything wrong.

At first glance, it works fine with the X backend. But the Flatpak package probably shouldn't do this unless it has some clear advantage, or it might cause issues instead.

Edit: It seems to be due to this. I think it QT here doesn't have/isn't using xdg-shell integration. The relevant files seem to be in some later org.kde.Platform versions...

Failed to load shell integration
Could not create a shell surface object.
WhyNotHugo commented 4 years ago

@ids1024 So... it runs that way, but won't create any windows?

ids1024 commented 4 years ago

Right. With the wayland mode, it runs without terminating, but doesn't create any windows. I didn't think there were any errors, but then I noticed the "shell integration" one. Which I think is likely the problem, though I'm not too familiar with the role xdg-shell plays in Wayland.

I guess we'll see if they update the QT version at some point. 5.9 is an LTS that loses support at the end of the month. But then, they aren't using the latest point release either.