Picom not excluding toolbars and capture frame when sharing desktop in Zoom

[arielnmz]

Platform

Fedora release 31 (Thirty One) Kernel 5.8.18-100.fc31.x86_64

Environment

awesome v4.3 (Too long) • Compiled against Lua 5.3.5 (running with Lua 5.3) • D-Bus support: ✔ • execinfo support: ✔ • xcb-randr version: 1.6 • LGI version: 0.9.2

picom version

vgit-3680d

Other details

Is there a way to correctly target these kind of windows to exclude shadows and blur? This is how Zoom's shared desktop look like, for example:

I tried excluding the frame's window from the rules by targeting the name (output of xprop):

WM_NAME(STRING) = "cpt_frame_window"

And I can also exclude the top toolbar's weird blur with the name again (also xprop):

WM_NAME(STRING) = "as_toolbar"

But is there a simpler way to do it? How can I make picom target only "normal" windows?

[konecny-ondrej]

I think we'd need to take the _MOTIF_WM_HINTS into account. They can, too, influence the window decoration. The problem is that they are bitfields and I haven't found a way to read the individual bits in the property in picom.conf Edit: I have found at least some info on what the bits mean: https://people.gnome.org/~tthurman/docs/metacity/xprops_8h.html

[arielnmz]

Is there a way to peek at those values? Like with xprop or something? I have zero experience with WMs and don't know what I'm looking at

[konecny-ondrej]

Yes, you can see the _MOTIF_WM_HINTS in xprop, but not all the applications set it. For example Zoom does. However all you'll see is five numbers like this (taken from a menu in Zoom):

_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0

I think it means this (my best guess based on the link I posted earlier):

flags = MWM_HINTS_DECORATIONS   (1L << 1)
functions = MWM_FUNC_ALL   (1L << 0)
decorations = 0 (disabled)
input_mode = MWM_INPUT_MODELESS   (0)
status = 0 (no idea what that means)

Edit: I tried to put this in my shadow-exclude in picom.conf, but it does not seem to have the desired effect.

"_MOTIF_WM_HINTS@[2]:c = 0"

[arielnmz]

Thanks! I think that's a good start, let me see if I can find something

[arielnmz]

Hmmm... so according to this function: https://people.gnome.org/~tthurman/docs/metacity/window-props_8c-source.html#l00603 it uses the MWM_HINTS_DECORATIONS bit to know whether to decorate the window, so I think we'd want to exclude those who set that value to 0, right? like you attempted with

"_MOTIF_WM_HINTS@[2]:c = 0"

But what effect did it have?

[konecny-ondrej]

But what effect did it have?

It had no effect, unfortunately. But there is a DECORATIONS bit in flags and there is whole DECORATIONS field, which specifies what to do with decorations on each side. So I think the window should be undecorated if either the bit or the field are zero. Also notice that the undecorated Zoom windows set the decorations bit to 1.

[arielnmz]

I think the decorations bit part in the flags is only used to know whether to try and read decorations (this line)

if (hints->flags & MWM_HINTS_DECORATIONS)

And then it uses the actual decorations field to know what do do:

if (hints->decorations == 0)
    window->mwm_decorated = FALSE;
/* some input methods use this */
else if (hints->decorations == MWM_DECOR_BORDER)
    window->mwm_border_only = TRUE;

I believe zoom sets the decorations flag but doesn't set any decorations in the decorations field (the 0x2 and 0x0 we see, respectively), but that should be fine

My bet is that it has to do with how picom parses such values, I think it's a bug because it also seems to not respect other similar fields like _XEMBED_INFO, which I mention in the other issue: https://github.com/yshui/picom/issues/616

By the way, know of any way to import this project into Clion? I think the meson build system doesn't play nice with the IDE

[Hi-Angel]

By the way, know of any way to import this project into Clion? I think the meson build system doesn't play nice with the IDE

There's a documentation here.

---

Let me note, that the issue still persists. Today I was sharing a screen via ZOOM and it was all blue. I thought it's some ZOOM bug, but in the end figured out it's Picom and found this report.