own_window_type='override' never gets an ARGB visual (stuck at Depth 24) while normal/desktop/dock/panel do

Summary

own_window_type = 'override' never obtains a 32-bit ARGB visual, even with a compositor active and own_window_colour set with an alpha channel — while normal, desktop, dock, and panel all correctly obtain a 32-bit ARGB visual under identical conditions. The result is that override windows always render fully opaque, regardless of the alpha specified in own_window_colour.

Environment

• conky version: 1.24.2-pre-50fb32a2 (Arch Linux official conky package, built 2026-09-05)
• X11, awesome window manager
• Compositor: picom (v12, confirmed active — verified as the sole _NET_WM_CM_S0 owner)
• X server confirmed to expose a depth-32 TrueColor visual (xdpyinfo shows depth 32, bits_per_pixel 32)
• NVIDIA proprietary driver, GLX direct rendering confirmed working

Repro

Minimal config, varying only own_window_type:

conky.config = {
    own_window = true,
    own_window_type = 'override',  -- also tested: normal, desktop, dock, panel
    own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
    own_window_colour = '#8fff',   -- and also tested '#aa1a1b26'
    minimum_width = 200,
    minimum_height = 100,
    update_interval = 1,
};
conky.text = [[test]]

Run conky -c <config>, then check the resulting window's visual with xwininfo -id <id>.

Results

override is the only type that fails to get an ARGB visual. This reproduced consistently across repeated runs, with the compositor confirmed active throughout, and independent of whether own_window_colour alpha was given as a 4-digit (#8fff) or 8-digit (#aa1a1b26) hex value.

Expected behavior

Per the log output at startup (ARGB is now always enabled when available — related to the color-management cleanup in #2109 / #2344), override windows should get an ARGB visual whenever the X server and an active compositor support it, same as the other window types. own_window_type='override' only affects whether the window manager manages/decorates the window (per the man page: "If you use own_window_type='override', window manager hints have no meaning and are ignored") — it should have no bearing on visual/compositing capability.

Impact

This silently breaks transparency for any config that relies on own_window_type = 'override' for undecorated, unmanaged always-on-top/below desktop widgets (a common pattern for system-monitor-style conky configs), with no warning or error at startup — the window is simply rendered opaque.

Notes

This is distinct from the (intentional, already-tracked) removal of own_window_argb_visual / own_window_argb_value / own_window_transparent in favor of alpha in own_window_colour (#2109/#2344) — that migration works correctly for every window type except override.