Zoom Screen Sharing Causes White Screen to Cover Display

[ElliotKillick]

Qubes OS version
R4.0

Affected component(s) or functionality
Qubes GUI agent, vm side

Brief summary
Screen sharing in Zoom works from the perspective of the meeting participants; but on your side, all you see is a big white screen spanning the entire display. This prevents interaction with the windows and if played around with for a bit, locks up. At which point, my only remedy was to logon to a new tty to kill the zoom process inside the affected qube.

To Reproduce

1. Install Zoom on fedora-31 AppVM from: https://zoom.us/client/latest/zoom_x86_64.rpm
2. Install Zoom on another device (e.g. phone)
3. Join a meeting together
4. Enable screen sharing on fedora-31 AppVM

Expected behavior
Screen sharing from Zoom should capture everything inside the AppVM without whiting out the screen from its perspective.

Actual behavior
Screen is completely white on the side of the screen sharing AppVM.

Additional context
Given the current times, pandemic and all, this is of fairly high importance.

Solutions you've tried
I ran ps aux | grep qubes-gui to see if I had manual composition mode enabled as described in: marmarek/qubes-gui-agent-linux@3187ffb
I did not have a -c switch.

Related, non-duplicate issues
#4351

[ElliotKillick]

Screen capture does still work though, for example, if I use flameshot to take a screenshot. Just more evidence that this is different from #4351.

[GWeck]

I had the same behaviour when I used Zoom from an AppVM running under ubuntu 1804 (bionic beaver). Running Zoom from an AppVM running under Windows 7 with QWT 4.0.1.3 allowed, however, to share the screen from the perspective of the VM - no whiting of the screen.

So this seems to be a problem of a generic Linux driver, since it occurs with Fedora and Debian based systems, but not with Windows. Windows, however, lacks the audio driver, and, at least for me, did not succeed in connecting an USB webcam.

[v6ak]

In my opinion, this is caused by some transparent overlay that is there for annotating the screen content. Since Qubes OS does not support transparency, the overlay is white.

Workarounds:

a. Use Zoom from a web browser.
b. Hide the overlay by xdotool selectwindow windowunmap.

If the reason is the transparent layer, I am not sure how Qubes OS can reasonably fix it in a generic way. Of course, Qubes OS might blacklist the overlay.

[GWeck]

The layer seems to be inactive. xdotool selectwindow returns a window ID, but commands like windowunmap, windowkill or windowsize have no effect on the white overlay, although they work on other windows.

[v6ak]

Did you run it in AppVM, or in dom0? I have succeeded with running this in dom0.

…

On June 3, 2020 1:07:05 PM GMT+02:00, "Dr. Gerhard Weck" ***@***.***> wrote: The layer seems to be inactive. `xdotool selectwindow` returns a window ID, but commands like `windowunmap`, `windowkill `or `windowsize `have no effect on the white overlay, although they work on other windows. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #5863 (comment)

-- Sent from my fruity BlackBerry phone. Please excuse my brevity.

[GWeck]

I ran it from the AppVM. Now I tried from dom0, and it is working. Thanks a lot!!!

[ElliotKillick]

Thanks @v6ak, worked like a charm for me too! I found that the name of the annotating window is cpt_frame_window (cpt stands for "capture" I presume) meaning that it can be closed a bit easier using the following command after starting Zoom screen sharing:

xdotool windowunmap "$(xdotool search --name cpt_frame_window)"

Probably just add a small sleep before so you click start screen sharing and then, once the white screen pops up, have this command run.

I suppose the real solution would be to add support for transparent windows. Should still be secure as long as it has the coloured window border around it. Being able to use the annotation feature in Zoom would be nice.

For the time being, a suitable workaround for getting annotation is to use flameshot. It nicely sits in the system tray and can be clicked on whenever you need annotating.

[v6ak]

You can edit it as you wish. While theoretically copyright might apply, I consider this single line to be too trivial. So feel free to consider it as public domain. When you have some keyboard shortcut, you don't need to sleep. (I mean your script doesn't need to sleep, of course…) You don't need to have a specific shortcut for this, something menu based on dmenu works. Well, I am not much convinced that transparent windows are risk-free. This might require a deeper discussion about user behavior. Maybe it is OK, but I don't think it to be a no-brainer…

[marmarek]

Transparent windows are tricky security-wise, because it makes hard to tell what is part of such window. Imagine full screen transparent window from some red qube, that renders a green password prompt inside - it may be really hard to notice it really belongs to the fullscreen transparent window.
I have some ideas for heuristics to make it slightly less risky (for example allow only over windows belonging to the same qube), but they all are still risky, and can be also tricky to implement in a way not breaking expected application behavior.

[ElliotKillick]

Perhaps there should be a setting to allow transparency on a qube by qube basis like there is for fullscreen mode in /etc/qubes/guid.conf. That, plus the coloured window border, along with some aforementioned heuristics should make for a reasonable solution.

This case is particularly tough because the window covers the full screen, is transparent, and has to receive mouse and keyboard input (for annotation with drawing, text boxes, etc.).

Also, I should note that the flameshot solution only allows you to annotate but of course any annotations participants make are invisible to you.

[GWeck]

The transparent window shown in Zoom screen sharing seems to be a "feature" of the Zoom product. I tested the GotoMeeting videao conference software now, and it allows screen sharing without this transparent window, probably because it may be lacking the possibility to annotate etc.

[ehanoc]

@ElliotKillick, @GWeck, @v6ak, @marmarek

You can almost fix this issue completely by changing the line in ~/.config/zoomus.conf

[AS]
showframewindow=true

change to

[AS]
showframewindow=false

Now, after fixing this, you will be able to screen share and function. Although, the toolbar and the zoom menus are still blank. From what i gather it has to do with the display composite options for xfce4. I still haven't figured that one out though ...

Hope it helps folks

[heinrich-ulbricht]

@ehanoc If by "toolbar" you mean the top center bar showing the session ID and meeting controls - this is working fine for me, the bar is showing and can be used. Seems like the perfect solution for me. (Using the latest zoom-client from the snap store on Fedora 31.)

[ehanoc]

@ehanoc If by "toolbar" you mean the top center bar showing the session ID and meeting controls - this is working fine for me, the bar is showing and can be used. Seems like the perfect solution for me. (Using the latest zoom-client from the snap store on Fedora 31.)

No, i mean the top one during screen sharing.

It regular bottom-toolbar, does works normally

[GWeck]

For me, the file is ~/snap/zoom-client/current/.config/zoomus.conf.

Screen sharing shows all windows under control of the VM, without their borders. This makes sense, as the colour of the borders makes sense only within Qubes, not for another meeting participant who joined the meeting from a different computer. The rest of the shared screen is white, as is to be expected, because the VM is not allowed to see other portions of the screen.

[ehanoc]

For me, the file is ~/snap/zoom-client/current/.config/zoomus.conf.

Screen sharing shows all windows under control of the VM, without their borders. This makes sense, as the colour of the borders makes sense only within Qubes, not for another meeting participant who joined the meeting from a different computer. The rest of the shared screen is white, as is to be expected, because the VM is not allowed to see other portions of the screen.

No, the toolbar im referring is the one you have only when sharing on the top of the screen. And that is blanked out. Nothing to do with the colours of the window of the VM.

[ioleo]

Had the same issue. Using latest Zoom Version 5.4.7 (57450.1220) and Fedora-30 VM.
The trick to get it working was to:

• go to Zoom -> Settings -> Share Screen
• untick (turn off) Show green border around the shared content box

[timdiels]

Another workaround, that applies more generally for applications that need GPU-like capabilities, is to run it in TurboVNC. It's not a full replacement for a GPU but for simple things that try to draw on screen, it's usually sufficient. (I have had problems with Zoom screen sharing not showing anything; I don't recall whether it was a white screen but it sounds like the same issue I had). It's more work to set up than the above trick, e.g. have to run another desktop environment, but once set up you can use it for Zoom, Teams, websites which want webgl sometimes works too, ...

[DemiMarie]

Another workaround, that applies more generally for applications that need GPU-like capabilities, is to run it in TurboVNC. It's not a full replacement for a GPU but for simple things that try to draw on screen, it's usually sufficient. (I have had problems with Zoom screen sharing not showing anything; I don't recall whether it was a white screen but it sounds like the same issue I had). It's more work to set up than the above trick, e.g. have to run another desktop environment, but once set up you can use it for Zoom, Teams, websites which want webgl sometimes works too, ...

You can also use Xephyr for the same trick I think.

[andrewdavidwong]

Is this still a problem in 4.1?

[github-actions]

This issue is being closed because:

• This issue is believed to affect only Qubes OS 4.1 (and possibly earlier).
• Qubes OS 4.1 has reached end-of-life (EOL).

If anyone believes that this issue should be reopened, please leave a comment saying so.
(For example, if a bug still affects Qubes OS 4.2, then the comment "Affects 4.2" will suffice.)