#2432·conky

[Bug]: wayland: desktop widgets are hidden by "Show Desktop" on KDE Plasma

Author: sniper1720Created Aug 13, 2026Updated Aug 13, 2026
Labelsbugtriage

What happened?

On KDE Plasma under Wayland, my conky desktop widgets (own_window_type = 'desktop') disappear the moment I hit Meta+D (Show Desktop) — just like any normal window. On X11 the same config stays on screen like wallpaper. The widget is mounted on the background layer, but KWin still classifies it as a normal window.

Reproduction

  1. Run conky with own_window_type = 'desktop' on KDE Plasma Wayland.
  2. Press Meta+D.
  3. The widget vanishes with all the normal windows.

On X11 the same config produces _NET_WM_WINDOW_TYPE_DESKTOP and survives Show Desktop, so this defect is Wayland-only.

Root cause

wlr-layer-shell's get_layer_surface takes a namespace argument, defined by the protocol as "a name identifying the compositor role of the layer surface". conky hardcodes "conky":

cc
conky::create_shell_surface<conky::layer_shell_surface>({
    on_close,
    global_window->surface,
    wl_globals.layer_shell,
    static_cast<uint32_t>(layer_for_window()),
    "conky",
});

KWin derives the window type from exactly this field. In src/wayland/layershellwindow.cpp:

cc
static WindowType scopeToType(const QString &scope)
{
    static const QHash<QString, WindowType> scopeToType{
        {QStringLiteral("desktop"), WindowType::Desktop},
        ...
    };
    return scopeToType.value(scope.toLower(), WindowType::Normal);
}

"conky" isn't in that map, so every conky layer surface gets classified WindowType::Normal — no matter which layer it sits on. And normal windows are exactly what Workspace::setShowingDesktop() hides. So even though the widget is on the BACKGROUND layer (selected correctly by layer_for_window() at display-wayland.cc:473), it still gets hidden.

Expected behavior

own_window_type = 'desktop' on Wayland should behave like its X11 sibling: stay on screen during Show Desktop. The namespace should follow the same logic as the layer mapping.

Proposed direction

At the layer-shell create site, pick the namespace from the configured window type:

cc
own_window_type.get(*state) == window_type::DESKTOP ? "desktop" : "conky"

Non-desktop conky windows keep the "conky" namespace, so nothing else changes.

References

  • wlr-layer-shell spec — zwlr_layer_shell_v1.get_layer_surface namespace.
  • KWin layershellwindow.cppscopeToType(): unknown scope defaults to WindowType::Normal; "desktop"WindowType::Desktop.
  • KWin Workspace::setShowingDesktop() — desktop-type windows are exempt.

Related existing reports

  • #2306 [Bug]: On KDE wayland, conky hides when clicking on the desktop, with own_window_type desktop (closed as not planned, env: xwayland) — the closest report. It is not this bug: the reporter runs the X11 backend through XWayland (out_to_x = true, conky: drawing to created window (0x1400001)), while this report is about the native Wayland layer-shell backend. Different path, different root cause, and it was closed without a fix — the native-Wayland case was never addressed.
  • #2340 [Bug]: own_window_type desktop rendering (open) — same config on Wayland, but a different symptom (double-rendering/black background on XWayland), not the Show-Desktop hiding I'm reporting here.
  • #2304 [Bug]: Openbox hides normal conky window when ToggleShowDesktop is used; desktop window type doesn't work (closed) — the X11/Openbox analogue of this report, marked wontfix.
  • #145 (2015, closed) — KDE/X11 desktop-type behavior; historical context.

I didn't find any open report covering Wayland + KDE + Show-Desktop specifically.

Version

conky git master (Wayland build, as of 1affe0297 / June 2026), compiled with -DBUILD_WAYLAND=ON.

Which OS/distro are you seeing the problem on?

Arch Linux

Conky config

lua
conky.config = {
    own_window = true,
    own_window_type = 'desktop',
    -- no 'above'/'below' hint
}

Stack trace

gdb
N/A — not a crash; a behavior defect.

Relevant log output

bash
Nothing relevant to log — the widget just hides with the windows. The layer/stacking is correct; only KWin's classification is wrong, and that comes from the namespace string. A patched build is needed until this is fixed upstream.