Regression: Desktop screensharing not working for Linux

Question

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.

Answer 1

Did you try ? ->

https://learn.microsoft.com/en-us/answers/questions/42095/sharing-screen-not-working-anymore-bug.html

Answer 2

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

Answer 3

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