question

PhilbyJohn-5821 avatar image
2 Votes"
PhilbyJohn-5821 asked CarstenHaitzler-4775 edited

Regression: Desktop screensharing not working for Linux

Desktop screen sharing was working fine in teams for Linux version : teams-1.3.00.5153-1.x86_64 (20-Mar-2020)
Desktop screen sharing shows a black screen of death for latest Linux version: teams-1.3.00.16851-1.x86_64 (29-Jun-2020)

Only option then is to kill teams and then restart.

office-teams-linux-itpro
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

MichaelMassee-9029 avatar image
3 Votes"
MichaelMassee-9029 answered MichaelMassee-9029 commented
· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I did now and it works! I do not use i3wm but kwin_x11

 root@:Notebook# rpm -qil i3.x86_64
 package i3.x86_64 is not installed

Thanks a lot for pointing to the workaround.

2 Votes 2 ·
PhilbyJohn-5821 avatar image
0 Votes"
PhilbyJohn-5821 answered

What's been tried and failed?
1. complete erase and reinstall
2. disabling GPU h/w acceleration in Settings -> General -> Disable GPU hardware acceleration



Reverting back to teams-1.3.00.5153-1.x86_64 works. Clicking on "Desktop" icon presents a black screen with a red border. Would need to hit Alt+F4 to kill the screen.

11334-msteams-desktop-share.png






5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Michael-2022 avatar image
0 Votes"
Michael-2022 answered Michael-2022 commented

Hi, I experience the exactly same issue: Screensharing stopped working with the latest version of teams-insiders (1.3.00.16851). So I needed to downgrade to the previous version (1.3.00.14051). I just see a black window with a red border (this is exactly what is shared). I can see all tooltips, but not the main content. Like described by the previous posters.

I currently run an up-to-date Debian Unstable system. The package is retrieved via apt: 'deb [trusted=yes] https://packages.microsoft.com/repos/ms-teams stable main'

I have a notebook with the same debian version and 'similar' packages installed, where screensharing is still working (Lenovo X1 Carbon 2nd gen: Intel CPU, Intel graphics, X-Server, KDE/Plasma).

Summary of the setup where screensharing stopped working:

  • Hardware

  • CPU: AMD Ryzen Threadripper 1920X 12-Core Processor

  • Mainboard: MSI X399 Gaming Pro Carbon AC

  • Graphics-Card: MSI Radeon RX 560 Aero ITX OC 4GB

  • Single monitor setup (1920x1200)

  • Sofware versions

  • QT-Version: 5.14.2

  • KDE Plasma: 5.17.5

  • X-Server: X.org 7.7

  • Kernel: 5.7.6

  • GPU-Module: amdgpu 19.1.0 (open-source version)

In contrast the Notebook where screen sharing is working:

  • Hardware

  • CPU: Intel(R) Core(TM) i7-3667U

  • GPU: Integrated Graphics: Intel HD 4000

  • Lenovo Thinkpad X1 Carbon 2nd Gen (2012)

  • Notebook monitor only (1600x900)

  • Software versions

  • SW-Versions are the same as on the system with the bug, except the graphics module

  • GPU-Module: i915/intel 2.99.917

Feel free to reach out for further information











· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Have you tried the method mentioned by @MichaelMassee-9029 above?


$ sudo mv /usr/share/teams/resources/app.asar.unpacked/node_modules/slimcore/bin/rect-overlay /usr/share/teams/resources/app.asar.unpacked/node_modules/slimcore/bin/bad-rect-overlay


1 Vote 1 ·

Perfect, thanks. That's exactly the issue.
If I start rect-overlay via eg 'rect-overlay -p 0x0 -s 100x100' directly on the described notebook the overlay is working properly and on the described desktop machine the screen turns black.

1 Vote 1 ·
Michael-2022 avatar image
1 Vote"
Michael-2022 answered Michael-2022 commented

jfyi: On my KDE/Plasma environment switching the compositor on solved the issue without having to move 'react-overlay' out of the way

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

hmm... i already have the compositor enabled. Could you paste your settings here please. Here's mine.

11434-kde-compositor.png


0 Votes 0 ·
kde-compositor.png (26.3 KiB)

Looks the same as my config options. I changed it to opengl 3.1 later, but it was working with 2.0 as well.
Don't know if there is a way to see if compositing is used by kwin. You can toogle compositing with Alt+Shift+F12 and check the '$HOME/.xsession-errors' (eg via tail -f ~/.xsession-rrors) file for an indicator if compositing is not used, even if tried to switched on.

0 Votes 0 ·
JimmyYang-MSFT avatar image
0 Votes"
JimmyYang-MSFT answered ChristopherRamos-6938 commented

Hi!

Thanks for sharing solution about this issue!

Have a nice day!

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

This rect-overlay solution did not fix screen sharing on my linux mint machine. I used screen sharing the end of Jul, August it stopped working.

2 Votes 2 ·
ChristopherRamos-6938 avatar image ChristopherRamos-6938 WedgiePhilipCIVDCMAHQUSA-3233 ·

I am experiencing the same issue with Ubuntu 20.04. Beginning of August it stopped working.

0 Votes 0 ·
Dave-1364 avatar image
0 Votes"
Dave-1364 answered

Rect-overlay solution did not fix my screen sharing issue either. It stopped working around the end of July/beginning of August.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

CarstenHaitzler-4775 avatar image
0 Votes"
CarstenHaitzler-4775 answered CarstenHaitzler-4775 edited

EDIT

After some LD_PRELOADs to look at rectangle-overlay (due to no source)... it does set an empty region... but i still see the below rect, but i now know why - there is a bug in e that accidentally SETS the shape input rect on override-redirect windows (it works fine with regular client windows) - i've fixed it in git and will be in the next release.

END EDIT

I'm a Window Manager and Compositor developer and a user just complained that teams screen sharing is broken (in the app - I've used the web instance of teams without trouble). Here is what is broken, why and what teams is doing wrong and how it can be fixed:

When you share a screen, at least if you have multiple screens (in X11), teams opens an override-redirect window (these bypass the window manager and do not get intercepted for normal sizing and placement). This window is the size of the screen you want to share and fills it. Teams ASSUMES you are using a compositor and just draws a window that is almost entirely empty (0 pixel values - thus transparent if composited). this means that the screen is covered with this big mostly black (with red border) window on top - thus hiding everything. This window ALSO happens to steal all events so you can't click on anything else as all mouse events will be going to this window.

You can partly solve the problem by running a compositor. But this then leads to the second half of the problem which is what I've hit.

This window covers the screen absorbing ALL input from a mouse. You can't click on or interact with anything because all input goes here. Teams does not describe either any shape rectangles for the window bounding shape nor any shape input rectangles to limit input regions only to the rectangle edges or just set an empty shape input rectangle list (thus no input goes to this window - it's used for output/rendering only). The window manager and compositor have no idea that anything special has to happen with input (the way my WM/compositor works is it uses a big input only window with shape input rectangles to cut out holes to let input go through to windows underneath and it uses the shape and shape input rects of windows to do this even for override-redirect windows). Teams is also getting this wrong by stealing the entire screen for input effectively. There is no workaround for this like running a compositor above. Just because a pixel is fully transparent does NOT mean it should not be collecting input. The way X is designed is to be explicit about this and you can have a transparent window sit there collecting input - you can't see it but it's there and has 1 or more input rectangles. This is the intended design.

You could argue compositors should read all pixel values with the CPU every time a window updates and create a list of shape rectangle to match the pixel values. In X11 they have to because input is processed by the xserver and not compositor thus the Xserver has to be told of the regions that collect input or not. This SHOULD have been done by teams, but has not been. Reading back all the pixels then to form a list of region rectangles from it to then set is incredibly costly and will put a big strain on a CPU and is not how input is meant to be handled in X11 even with compositing. Teams is fundamentally not understanding how X11, WM's and compositors work here.

This MAY happen to work with some Wayland compositors that use color buffer picking and rendering color regions per window in an extra buffer to do window-picking, and then by LUCK it happens to work, but this is also not cheap - it's another color buffer that needs rendering to that you never see and needs updating every time the screen updates as it has to mirror ARGB values that may change. Every input event has to read-back the pixel value at a specific coordinate to figure out which window it goes to. Normally display systems will maintain lists of rectangles to do this with and do all the region intersection logic CPU-side because it's much cheaper to do this for most common cases. The color buffer solution is what you use when you start to do crazy transforms (rotate a window in 3D space or wrap it around a 3D teapot). It's a game-engine solution for an arbitrary and complex 3D scene rendering, not for 2D. Either way it's drastically more efficient for teams to provide the input region directly and it should.

So the solution for teams is to go set an empty (no rectangles) shape input rect list on this window, then it will be invisible to input.

For the compositing problem, teams should check the selection owner for then _NET_WM_CM_Sxxxx atoms (where xxxx is the screen number like 0, 1, 2 etc.) - see https://specifications.freedesktop.org/wm-spec/1.4/ar01s08.html .. This will tell them if a compositor is running or not. If it's not then you can't assume an alpha channel works. Certainly you can't do that for intrusive windows like this big black + red border one. If there is no window when getting the selection owner, then no compositor is running. If no compositor is running teams should try an alternate solution - either use full shape bounding rectangles for the window (this defines the entire input AND output rendering region of a window as a series of rectangles so in this case just include 4 rectangles defining the borders of the window so the middle is empty and will not be drawn to - also input will pass through this hole as well), or compose this screen border out of 4 separate windows and just place them around the screen edges (this is actually the most efficient solution) or perhaps do what e.g. Crhome does and just pop up a little window/box at the bottom of the screen with information that that screen is shared with controls on it to stop sharing etc..

It'd be really nice if this comment here was forwarded to teams developers responsible for the Linux client as the above is all they need to fix this properly. I otherwise know of now way to ensure anything gets to them. I also posted in ideas hoping it'll get through:

https://microsoftteams.uservoice.com/forums/908686-bug-reports/suggestions/44319009-screen-sharing-linux

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.