Black surface drawn on outward-facing sides of cube

[quequotion]

tl;dr: compiz should not render an empty x11 root window as a black surface; it should render _nothing_ instead.

Compiz draws a black surface on all outward-facing sides of the cube--even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.

In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.

For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome-desktop 19+ (3.36.0).

I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?).

[quequotion (quequotion)]

I should say that I do not believe compiz itself is responsible for applying this background, which appeared after an update that did not include compiz. However, it does not seem there is anywhere else to do anything about it: removing the packages that were updated do not remove the background, but leave it "default black"; attempting to change the root window background with utilities like hsetroot and xsetroot proved similarly useless. I've set everything to how it was before and back again many times over, but this will not go away. It would seem the only solution is to change how compiz renders the cube to prevent this from happening.

[quequotion (quequotion)]

This bug came back, since I have been unable to compile gnome-settings-daemon-compat to resolve it.

Some API was removed from libgnome-desktop recently:

https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/56

Among these, was gnome_bg_get_surface_from_root, which had featured this comment:

>If the _XROOTPMAP_ID is not set, then a black surface is returned.

That sounds very much like what I am seeing.

How does compiz interpret _XROOTPMAP_ID and _XROOTMAP_ID?

[Alberts Muktupāvels (muktupavels)]

What session are you using?

What is gnome-settings-daemon-compat? And how/why it helped previously?

[quequotion (quequotion)]

gnome-settings-daemon-compat is actually some parts of gnome-settings-daemon 3.6.1, repackaged as "gnome-fallback-[component]-helper". In particular, the background, media keys, and automount plugins were packaged this way. This was, at one time, used by GNOME Fallback, Unity, and other DEs to replace functionality that had gone missing from gnome-settings-daemon.

It has recently become impossible to build a working version of this since GNOME 3.36 introduced a fatal API break (effectively deprecating xorg's built-in background management):

https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/56#note_705813

What this means for compiz is that it can no longer render a transparent cube in sessions managed (only) by gnome-settings-daemon. Rather, it will render the empty X11 root window as a black surface on the outward-facing sides of the cube (or inward facing sides when using "inside cube"). That's something I'd like to see fixed in compiz, and the goal of this bug report: don't render an empty x11 root window this way; render _nothing_ instead.

What it means for every other DE relying on gnome-settings-daemon is that they have to develop their own, ad-hoc background management. I note that this has already happened in elementary OS, Linux Mint, MATE, etc. A workaround, for example, is to use cinnamon-settings-daemon's background plugin.

[Alberts Muktupāvels (muktupavels)]

Can you post screenshot/image with problem? And ideally one with how it should look if that is possible.

Oh, did not know about gnome-settings-daemon-compat... Anyway you might want try gnome-flashback for that. From GSettings you might disable many things if not needed. For background handling you might want desktop enabled or root-background.

Xorg's built-in background management? Removed API was creating pixmap with background image and setting _XROOTPMAP_ID property on root window referencing created pixmap. That pixmap then is used by window managers to draw background. Your linked MR did remove API but actual functionality was already removed in MR 53.

There is no such thing as session managed by gnome-settings-daemon. And GNOME Settings Daemon has never been intended as universal settings daemon for all desktop environments...

Anyway I have removed related properties from root window and restarted compiz but I still don't see / understand problem.