corrupted desktop background when root background is a pixmap with RetainTemporary

[gijsbers]

Environment

icewm window manager version 3.something on Linux.

picom version

vgit-dd85c

Diagnostics

**Version:** vgit-dd85c

Extensions:

• Shape: Yes
• RandR: Yes
• Present: Present

Misc:

• Use Overlay: No (Another compositor is already running)
• Config file used: None

Drivers (inaccurate):

modesetting

Backend: glx

• Driver vendors:
• GLX: Mesa Project and SGI
• GL: Intel Open Source Technology Center
• GL renderer: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
• Accelerated: 1

Backend: egl

[ 06/19/23 10:59:29.155 egl_init ERROR ] EGL version too old, need at least 1.5. Cannot initialize this backend

Configuration:

picom -f -I 0.09 -O 0.09

Steps of reproduction

1. ~/.icewm/prefoverride contains: DesktopBackgroundImage="/path/to/same/background.jpg"
2. ~/.icewm/preferences contains: Alpha=1
3. Have several workspaces with application windows, like terminals, browsers, etc.
4. start icewm and picom
5. restart icewm
6. go to other workspaces and restart icewm again.

Expected behavior

The desktop background should be identical to the background.jpg image.

Current Behavior

The desktop background is corrupted with partial areas of application windows. They disappear by moving a window over the corrupted areas.

When picom is not running this problem doesn't occur.

By setting a single background image, the icewmbg process install a root pixmap with the background image using XSetCloseDownMode(display(), RetainTemporary); and exits.

[absolutelynothelix]

does this happen with picom built from 7fc9436a0c0562fb3d659db3d9f538a5ae3dbc7c?

[gijsbers]

I think this picom was built from dd85c3e175d275912e751f79668c6a4c9a7e1ae5.

[absolutelynothelix]

according to your picom version, yes. can you build it from 7fc9436a0c0562fb3d659db3d9f538a5ae3dbc7c and check if the issue persists?

[gijsbers]

$ picom --version vgit-7fc94 Same thing. No improvement.

[gijsbers]

This bug was also present in the version from Jan 11, 2022.

[absolutelynothelix]

is it possible to reproduce this behavior with icewmbgonly? i'm setting the background in different ways with it and all of them seem to work fine.

[gijsbers]

No idea. The way that icewm restarts may create the proper conditions for this bug to occur?

[absolutelynothelix]

i tried one more time but i'm still unable to reproduce this issue. the only thing i could think of that could cause the described behavior is that under certain conditions icewmbg frees the pixmap the _XROOTPMAP_ID root window property points to. does this happen with the glx backend (--backend=glx)?

[gijsbers]

No, not with --backend=glx. If I try that then the background starts flashing after i restart icewm. I have to change workspaces and switch back to stop that.

Did you try with a released icewm, like 3.4.0 or 3.3.5?

[sigprof]

Apparently a similar problem happens with Awesome WM (https://github.com/awesomeWM/awesome/issues/3843 — the issue there is closed, but the problematic behavior can still be reproduced). And the problem is not related with how Awesome WM sets the root background (actually it happens when the Awesome WM configuration does not contain any wallpaper-related parts, so the WM does not try to change the root background during restart).

In the Awesome WM case the problem happens when I first set the root background using either feh --bg-fill some.png or (even simpler) hsetroot -solid gray30 (hsetroot actually sets _XROOTPMAP_ID, so it usually works with picom, apart from this corner case), and then restart the Awesome WM. During the WM restart windows from all workspaces are temporarily mapped when the old instance of the WM shuts down, and then get unmapped again when the new instance of the WM manages them and assigns them to the appropriate workspaces; but when picom is running, the areas which don't end up occupied by windows on the first workspace don't get redrawn properly. However, the background pixmap still exists — dragging some windows around in the bad state results in proper redrawing of the newly exposed areas of the root window, and restarting picom also fixes things without the need to set the background again.

Also running picom with the --no-use-damage option avoids the problem — restarting the WM does not result in the background corruption in that case. Switching backends does not change anything though.

[sigprof]

Also I can reproduce this on NixOS with the 10.2 release (from nixos-23.11), the 11.2 release (from nixos-unstable), and even with the most recent code (using nix run github:yshui/picom); the system is mostly on nixos-23.11 though.

❯ nix run github:yshui/picom -- --diagnostics
**Version:** v11

### Extensions:

* Shape: Yes
* RandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: None

### Drivers (inaccurate):

modesetting

### Backend: glx

* Driver vendors:
 * GLX: Mesa Project and SGI
 * GL: Intel
* GL renderer: Mesa Intel(R) UHD Graphics 630 (CML GT2)
* Accelerated: 1

### Backend: egl

* Driver vendors:
 * EGL: Mesa Project
 * EGL driver: iris
 * GL: Intel
* GL renderer: Mesa Intel(R) UHD Graphics 630 (CML GT2)

[yshui]

@sigprof hi i tried your steps on awesome, (hsetroot then restart awesome) but i can't reproduce the problem you described.

i do have use-damage = true. maybe some other config is different? what's your config?

[sigprof]

The default rc.lua needs to have this part removed for this test:

screen.connect_signal("request::wallpaper", function(s)
    awful.wallpaper {
        screen = s,
        widget = {
            {
                image     = beautiful.wallpaper,
                upscale   = true,
                downscale = true,
                widget    = wibox.widget.imagebox,
            },
            valign = "center",
            halign = "center",
            tiled  = false,
            widget = wibox.container.tile,
        }
    }
end)

(Setting the wallpaper this way hides the problem, apparently because the awful.wallpaper code delays the actual setting, and with that delay the wallpaper is set after all unrelated windows had been unmapped, therefore there is no source of corruption anymore.)

[yshui]

@sigprof ok i see it now.

[yshui]

my current guess is that, if a window is mapped and unmapped right away, its window is not added to damage.

[yshui]

@sigprof can you try #1215 ?

[sigprof]

Yes, #1215 seems to work for me (with github:yshui/picom/f5abccb29ce0c1a9fbe9601583a247dbb8c83144 Awesome WM restarts without leaving garbage on the screen, github:yshui/picom/617354fb3bb37457ac163ed5e6b26445af3df54c (the parent commit) fails as before).