PICOM(1)

📦
version 13 · 13 versions
, in fedora 43, fedora 44

💖 PICOM(1) 💖

okay bestie, listen up — this is the manual page for picom, from the User Commands section. it's a whole icon, and we're gonna get through it together. no cap.

✨ NAME ✨

picom — a compositor for X11 🦋

🌸 SYNOPSIS 🌸

picom [OPTIONS]

💅 DESCRIPTION 💅

so picom is a compositor, right? and it's built on top of Dana Jansens' version of xcompmgr — which, plot twist, was itself written by Keith Packard. the lore is real. 📜

it comes with some glow-ups over the original xcompmgr, like window frame opacity and inactive window transparency. it's giving upgrades. it's giving main character. 👑

🎀 OPTIONS 🎀

here's every single flag, bestie. buckle in, hydrate, we're going the whole way. 💧

  • -h, --help — get the usage text that's baked right into the program code. ngl, this might be more up-to-date than this man page itself, so it's worth a peek. 👀
  • -r, --shadow-radius=RADIUS — the blur radius for shadows, in pixels. (defaults to 12)
  • -o, --shadow-opacity=OPACITY — how see-through the shadows are. (0.0 - 1.0, defaults to 0.75)
  • -l, --shadow-offset-x=OFFSET — the left offset for shadows, in pixels. (defaults to -15)
  • -t, --shadow-offset-y=OFFSET — the top offset for shadows, in pixels. (defaults to -15)
  • -I, --fade-in-step=OPACITY_STEP — how much the opacity changes between steps while fading in. (0.01 - 1.0, defaults to 0.028)
  • -O, --fade-out-step=OPACITY_STEP — how much the opacity changes between steps while fading out. (0.01 - 1.0, defaults to 0.03)
  • -D, --fade-delta=MILLISECONDS — the time between steps in a fade step, in milliseconds. (> 0, defaults to 10)
  • -c, --shadow — enables client-side shadows on windows. ⚠️ heads up though: desktop windows (the ones with _NET_WM_WINDOW_TYPE_DESKTOP) never get a shadow, unless you explicitly ask for it with the wintypes option.
  • -f, --fading — fade windows in and out when they open/close, and when opacity changes — unless --no-fading-openclose is used. ✨
  • -i, --inactive-opacity=OPACITY — the opacity of inactive windows. (0.1 - 1.0, defaults to 1.0). using this option is discouraged, fr — check the WINDOW RULES section for the recommended way to set window-specific opacity. 🫶
  • -e, --frame-opacity=OPACITY — the opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
  • -b, --daemon — daemonize the process. it forks to the background after initialization. 🏃‍♀️💨 this one can only be set from the command line — setting it in the configuration file will have no effect. periodt.
  • --log-level — set the log level. possible values are "TRACE", "VERBOSE", "DEBUG", "INFO", "WARN", "ERROR", in increasing level of importance. case doesn't matter. if you're using the "TRACE" log level, it's better to log into a file using --log-file, since it can generate a huge stream of logs. 😭 like, a LOT.
  • --log-file — set the log file. if --log-file is never specified, logs get written to stderr. otherwise, logs get written to the given file — though some of the early logs might still go to stderr. when setting this option from the config file, it's recommended to use an absolute path. 📁
  • --show-all-xerrors — show all X errors (for debugging). 🐛
  • --config PATH — look for the configuration file at the path. see the CONFIGURATION FILES section below for where picom looks for a configuration file by default. use /dev/null to avoid loading a configuration file entirely. 💀
  • --write-pid-path PATH — write the process ID to a file. it's recommended to use an absolute path.
  • --plugins PATH — specify plugins to load. plugins get searched in the current working directory first (unless it's specified in the config file, in which case this step is skipped), then in $XDG_CONFIG_HOME/picom/plugins, then in $XDG_CONFIG_DIRS/picom/plugins. if all of the above fail, the plugin name is passed directly to the dynamic loader. can be specified multiple times to load more than one plugin. 🔌✨
  • --shadow-color STRING — color of shadow, as a hex string (e.g. #000000)
  • --shadow-red VALUE — red color value of shadow (0.0 - 1.0, defaults to 0).
  • --shadow-green VALUE — green color value of shadow (0.0 - 1.0, defaults to 0).
  • --shadow-blue VALUE — blue color value of shadow (0.0 - 1.0, defaults to 0).
  • --inactive-opacity-override — let the inactive opacity set by -i override the _NET_WM_WINDOW_OPACITY values of windows. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific opacity. 🫶
  • --active-opacity OPACITY — default opacity for active windows. (0.0 - 1.0, defaults to 1.0). using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific opacity.
  • --inactive-dim VALUE — dim inactive windows. (0.0 - 1.0, defaults to 0.0). using this option is discouraged, see the WINDOW RULES section for the recommended way to set window-specific dim levels.
  • --corner-radius VALUE — sets the radius of rounded window corners. when > 0, the compositor rounds the corners of windows. does not interact well with --transparent-clipping. (defaults to 0). 🎀
  • --corner-radius-rules RADIUS:CONDITION — specify a list of corner radius rules. overrides the corner radii of matching windows. this option takes precedence over the --rounded-corners-exclude option, and also overrides the default exclusion of fullscreen windows. the condition has the same format as --opacity-rule. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific corner radius.
  • --rounded-corners-exclude CONDITION — exclude conditions for rounded corners. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific corner radius.
  • --no-frame-pacing — disable vsync-aware frame pacing. by default, the compositor tries to make sure it only renders once per vblank interval, and also makes the render happen as late as possible to minimize the latency from updates to the screen. however, this can sometimes cause stuttering, or even a lowered frame rate. 😭 this option can be used to disable frame pacing.
  • --mark-wmwin-focused — try to detect WM windows (a non-override-redirect window with no child that has WM_STATE) and mark them as active. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific rules.
  • --mark-ovredir-focused — mark override-redirect windows that don't have a child window with WM_STATE as focused. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific rules.
  • --no-fading-openclose — do not fade on window open/close. 🚫
  • --no-fading-destroyed-argb — do not fade destroyed ARGB windows with WM frame. this is a workaround for bugs in Openbox, Fluxbox, etc. 🐛
  • --shadow-ignore-shaped — do not paint shadows on shaped windows. ⚠️ note: "shaped windows" here means windows setting their shape through the X Shape extension. those using an ARGB background are beyond our control. deprecated, see the WINDOW RULES section for the recommended way to set window-specific shadow.
  • --detect-rounded-corners — try to detect windows with rounded corners and not consider them shaped windows. unfortunately the accuracy is not very high. 🙈
  • --detect-client-opacity — detect _NET_WM_WINDOW_OPACITY on client windows. useful for window managers that don't pass _NET_WM_WINDOW_OPACITY of client windows to frame windows.
  • --vsync, --no-vsync — enable/disable VSync. ⚡
  • --use-ewmh-active-win — use EWMH _NET_ACTIVE_WINDOW to determine the currently focused window, rather than listening to the 'FocusIn'/'FocusOut' event. might be more accurate, provided that the WM supports it. 👀
  • --unredir-if-possible — unredirect all windows in some cases. known to cause flickering when redirecting/unredirecting windows. currently, unredirecting is triggered by the following conditions:
    • if the top level window is taking up the entire screen. in a multi-monitor setup, this means ALL monitors. 🖥️🖥️
    • if there is no window.
    • if a window is fullscreen according to its WM hints. (can be disabled with --no-ewmh-fullscreen).
    • if a window requests to bypass the compositor (_NET_WM_BYPASS_COMPOSITOR). windows are also unredirected unconditionally when monitors are powered off, regardless of whether --unredir-if-possible is set. 💀
  • --unredir-if-possible-delay MILLISECONDS — delay before unredirecting the window, in milliseconds. defaults to 0.
  • --unredir-if-possible-exclude CONDITION — conditions of windows that shouldn't be considered full-screen for unredirecting the screen. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific unredirect.
  • --shadow-exclude CONDITION — specify a list of conditions of windows that should have no shadow. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific shadow.
  • --clip-shadow-above CONDITION — specify a list of conditions of windows that should have no shadow painted over them, like a dock window. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific shadow clipping.
  • --fade-exclude CONDITION — specify a list of conditions of windows that should not be faded. using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific fading.
  • --focus-exclude CONDITION — specify a list of conditions of windows that should always be considered focused. using this is discouraged, see the WINDOW RULES section for the recommended way for doing this.
  • --inactive-dim-fixed — use a fixed inactive dim value, instead of adjusting according to window opacity.
  • --detect-transient — use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time. 👯
  • --detect-client-leader — use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time. this usually means windows from the same application will be considered focused or unfocused at the same time. WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
  • --blur-method, --blur-size, --blur-deviation, --blur-strength — parameters for background blurring. see the BLUR section for more information. 🌫️
  • --blur-background — blur the background of semi-transparent / ARGB windows. bad for performance, with driver-dependent behavior. ⚠️ the name of the switch may change without prior notification.
  • --blur-background-frame — blur the background of windows when the window frame is not opaque. implies --blur-background. bad for performance, with driver-dependent behavior. the name may change. ⚠️
  • --blur-background-fixed — okay so this one uses a fixed blur strength for a window during fading. It only applies to the --fading option, and it's a no-op if you're using animation scripts. So if you're fading and want the blur to stay steady? This is your girl. ✨
  • --blur-kern MATRIX — bestie, this lets you specify the blur convolution kernel, and the format is literally:
WIDTH,HEIGHT,ELE1,ELE2,ELE3,ELE4,ELE5...

In other words, the matrix is a list of comma separated numbers. The first two numbers must be integers, and they specify the width and height of the matrix. They must be odd numbers. Then the following width * height - 1 numbers specify the numbers in the matrix, row by row, excluding the center element. 🧚

The elements are finite floating point numbers. The decimal pointer has to be . (a period), and scientific notation is not supported. 💀

The element in the center will either be 1.0 or varying based on opacity, depending on whether you have --blur-background-fixed. Yet the automatic adjustment of blur factor may not work well with a custom blur kernel. 🙈

A 7x7 Gaussian blur kernel (sigma = 0.84089642) looks like:

--blur-kern '7,7,0.000003,0.000102,0.000849,0.001723,0.000849,0.000102,0.000003,0.000102,0.003494,0.029143,0.059106,0.029143,0.003494,0.000102,0.000849,0.029143,0.243117,0.493069,0.243117,0.029143,0.000849,0.001723,0.059106,0.493069,0.493069,0.059106,0.001723,0.000849,0.029143,0.243117,0.493069,0.243117,0.029143,0.000849,0.000102,0.003494,0.029143,0.059106,0.029143,0.003494,0.000102,0.000003,0.000102,0.000849,0.001723,0.000849,0.000102,0.000003'

May also be one of the predefined kernels: 3x3box (default), 5x5box, 7x7box, 3x3gaussian, 5x5gaussian, 7x7gaussian, 9x9gaussian, 11x11gaussian. All Gaussian kernels are generated with sigma = 0.84089642 . If you find yourself needing to generate custom blur kernels, you might want to try the new blur configuration (see the BLUR section). 💅

  • --blur-background-exclude CONDITION — this is where you exclude conditions for background blur. So if you don't want blur on certain windows, this is your vibe check. 🚫
  • --invert-color-include CONDITION — specify a list of conditions of windows that should be painted with inverted color. But bestie, it's resource-hogging, and it's not well tested. Using this is discouraged, see the WINDOW RULES section for the recommended way to do this. So like, maybe don't? 🙈
  • --opacity-rule OPACITY:CONDITION — specify a list of opacity rules, in the format PERCENT:PATTERN, like 50:name *= "Firefox". picom-trans is recommended over this. Note we don't make any guarantee about possible conflicts with other programs that set _NET_WM_WINDOW_OPACITY on frame or client windows. Using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific opacity. 💅
  • --crop-shadow-to-monitor — crop shadow of a window fully on a particular monitor to that monitor. This is currently implemented using the X RandR extension. So if you want shadows to stay in their lane, this is it. ✂️
  • --backend BACKEND — specify the backend to use: xrender or glx. xrender is the default one. 👑
    • xrender — performs all rendering operations with X Render extension. It is what xcompmgr uses, and is generally a safe fallback when you encounter rendering artifacts or instability. So like, reliable bestie. 🫶
    • glx (OpenGL) — performs all rendering operations with OpenGL. It is more friendly to some VSync methods, and has significantly superior performance on color inversion (--invert-color-include) or blur (--blur-background). It requires proper OpenGL 3.3 support from your driver and hardware. You may wish to look at the GLX performance optimization options below. --xrender-sync-fence might be needed on some systems to avoid delay in changes of screen contents. 🔥
  • --no-use-damage — disable the use of damage information. This cause the whole screen to be redrawn every time, instead of the part of the screen has actually changed. Potentially degrades the performance, but might fix some artifacts. So it's a trade-off, bestie. 💀
  • --xrender-sync-fence — use X Sync fence to sync clients' draw calls, to make sure all draw calls are finished before picom starts drawing. Needed on nvidia-drivers with GLX backend for some users. So if you're on NVIDIA and seeing delays, try this. ✨
  • --force-win-blend — force all windows to be painted with blending. Useful if you have a window shader that could turn opaque pixels transparent. So if your shader is doing too much, this is the fix. 💅
  • --dbus — enable remote control via D-Bus. See the D-BUS API section below for more details. So you can control picom from other apps, periodt. 🎀
  • --benchmark CYCLES — benchmark mode. Repeatedly paint until reaching the specified cycles. So you can stress test and see those numbers. 🔥
  • --benchmark-wid WINDOW_ID — specify window ID to repaint in benchmark mode. If omitted or is 0, the whole screen is repainted. So if you want to benchmark just one window, here you go. 🪟
  • --no-ewmh-fullscreen — do not use EWMH to detect fullscreen windows. Reverts to checking if a window is fullscreen based only on its size and coordinates. So it's like old school detection. 👀
  • --max-brightness — dimming bright windows so their brightness doesn't exceed this set value. Brightness of a window is estimated by averaging all pixels in the window, so this could comes with a performance hit. Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0) So if you have a bright window that's blinding you, this is the vibe. 😎
  • --transparent-clipping — make transparent windows clip other windows like non-transparent windows do, instead of blending on top of them. So they cut instead of blend. ✂️
  • --transparent-clipping-exclude CONDITION — specify a list of conditions of windows that should never have transparent clipping applied. Useful for screenshot tools, where you need to be able to see through transparent parts of the window. So screenshot besties, this is for you. 📸
  • --window-shader-fg SHADER — specify GLSL fragment shader path for rendering window contents. Shader is searched first relative to the directory the configuration file is in, then in the usual places for a configuration file. See section SHADER INTERFACE below for more details on the interface. So custom shaders? We love. 🎨
  • --window-shader-fg-rule SHADER:CONDITION — specify GLSL fragment shader path for rendering window contents using patterns. Similar to --opacity-rule, arguments should be in the format of SHADER:CONDITION, e.g. "shader.frag:name = 'window'". Leading and trailing whitespaces in SHADER will be trimmed. If SHADER is "default", then the default shader will be used for the matching windows. (This also unfortunately means you can't use a shader file named "default"). Using this is discouraged, see the WINDOW RULES section for the recommended way to set window-specific shaders. So like, it works, but maybe don't? 🙈
  • --root-pixmap-shader SHADER — specify GLSL fragment shader path for rendering the root pixmap. The root pixmap usually is your desktop wallpaper, though for some desktop environment this is not the case. Shader is searched first relative to the directory the configuration file is in, then in the usual places for a configuration file. See section SHADER INTERFACE below for more details on the interface. So you can shader your wallpaper? Iconic. 🌈
  • --dithered-present — use higher precision during rendering, and apply dither when presenting the rendered screen. Reduces banding artifacts, but might cause performance degradation. Only works with OpenGL. So if you hate banding and have OpenGL, this is your girl. 💅

💖 WINDOW RULES 💖

okay bestie, THIS is the good stuff. window rules let you set options that are specific to individual windows, so you can change how a window looks based on conditions it meets. yes there are other options that also kinda cover some window-rule functionality, but window rules are more flexible and way more powerful. and like, if you're making a fresh config file? the recommendation is literally to use window rules instead of those other options. no cap. 🫶

here's the full list of options that window rules supersede:

  • --shadow-ignore-shaped
  • -i
  • --inactive-opacity=OPACITY
  • --active-opacity OPACITY
  • --inactive-opacity-override
  • --inactive-dim VALUE
  • --mark-wmwin-focused
  • --mark-ovredir-focused
  • --invert-color-include CONDITION
  • --shadow-exclude CONDITION
  • --fade-exclude CONDITION
  • --focus-exclude CONDITION
  • --rounded-corners-exclude CONDITION
  • --blur-background-exclude CONDITION
  • --opacity-rule OPACITY:CONDITION
  • --corner-radius-rules RADIUS:CONDITION
  • --window-shader-fg-rule SHADER:CONDITION
  • --clip-shadow-above CONDITION

plus the wintypes configuration file option. 💅

if you use the window rules option, none of the above options will have any effect. and warning messages will be issued. periodt.

and when the window rules option is used, the compositor also behaves a little differently in certain cases. one such case: fullscreen windows will no longer have their rounded corners disabled by default. 😱 (yes really, they're just gonna be round now, deal with it.)

if you're currently using some of those old options and you wanna switch to window rules, or if you just wanna keep the existing behavior, check out the Migrating old rules section below for how to convert them. 🌈

✨ Syntax ✨

window rules are only available in the configuration file. to set them, you set the rules option in the config file to something like this:

rules = (
        { match = "focused"; opacity = 1; },
        { match = "name = 'firefox'"; shadow = true; },
        # ... and so on
)

rules = ( ... ) sets the option to a list, which can contain multiple sub-items. for rules, each sub-item has to be a group (i.e. { key = value; ... }), and that group represents a condition plus a set of options to apply when the condition is met. these sub-items get matched in the order they appear in the configuration file, and options are applied as the conditions are matched. if the same option gets set multiple times, the last one takes effect. 💅

within each sub-item, these keys are available:

  • match — the condition string to match windows with. peep the FORMAT OF CONDITIONS section below for the syntax of condition strings. if you don't specify it, the rule will always match. 🎯
  • shadow — whether to draw shadow under the matching window.
  • full-shadow — controls whether shadow is drawn under the parts of the window that you normally won't be able to see. super useful when the window has transparent parts and you still want shadows in those areas. 🦋
  • shadow-color — color of the shadow. same syntax as --shadow-color STRING.
  • fade — whether to fade the matching window in/out when opening/closing it. when animations are used, this has no effect. this can only be used to disable fading animations enabled by option -f, --fading.
  • opacity — opacity of the matching window. (0.0 - 1.0). if not explicitly set by a rule, the opacity value from the window properties (e.g. _NET_WM_WINDOW_OPACITY) will be used.
  • blur-opacity — opacity of the background blur. (0.0 - 1.0). if not explicitly set by a rule, this will be 1.0. ignored if blur-background is not enabled. (yes the original says "Ignored by blur-background is not enabled", we all know what it meant 💀)
  • dim — dim level of the matching window. larger value means more dimming. (0.0 - 1.0).
  • corner-radius — corner radius of the matching window in number of pixels. 0 means no corner rounding.
  • blur-background — whether the background of the matching window should be blurred.
  • invert-color — whether to invert the color of the matching window. 🙃
  • clip-shadow-above — whether to prevent the matching window from being painted over by shadows.
  • unredir — whether the matching window should cause the compositor to unredirect the screen, and whether it should trigger the screen to be redirected again if it's currently unredirected. this could be a boolean value: if true, the screen will be unredirected if the matching window meets certain conditions; if false, it will never cause the screen to be unredirected. if the screen is currently unredirected, and there's no other window that will trigger unredirection, both of these choices will cause the screen to be redirected again. to control that behavior as well, you can set unredir to either preferred — such windows will not cause the screen to be redirected in this situation, and will behave like true otherwise — or passive, which not only won't cause redirection in this case, but also won't actively cause the screen to be unredirected. the last possible value for this option is forced, and any window having its unredir set to forced will cause the screen to be unredirected unconditionally. the value of the _NET_WM_BYPASS_COMPOSITOR property on the window will be considered iff unredir is not explicitly set by any rule.
  • transparent-clipping — whether to make the matching window clip other windows like opaque windows do, instead of blending on top of them. when applied to transparent windows, this means nothing will be painted under the transparent parts of the window, essentially cuts a hole in the screen. 🕳️
  • shader — GLSL fragment shader specification for rendering window contents. see the SHADER INTERFACE section below for more deets on the interface. this option can be a simple path to the shader file, but you can also specify extra options to the shader. currently the only extra options supported are macro defines. syntax:
shader = {
        path = "path/to/shader.glsl";
        defines = {
                COLOR = "vec4(1.0, 0.0, 0.0, 1.0)";
        };
};

this will prepend #define COLOR vec4(1.0, 0.0, 0.0, 1.0) to your shader (note the lack of double quotes). the value of a define MUST be a string, any string will be accepted and no sanitization is performed. 😭

  • animations — define window-specific animation scripts. the format of this option is the same as the top-level animations option. you can find more info in the ANIMATIONS section. if animation scripts are defined in multiple matching rules, they will be merged together. if multiple matching rules contain animation scripts for the same trigger, the last one takes effect, same as other options. 💫

🧚 Migrating old rules 🧚

most of the rule options should map 1:1 to the new window rules. here's a list of the non-trivial ones and how to achieve the same effect with window rules. 🫶

Inactive dimming and opacity

this includes options -i, --inactive-opacity=OPACITY, --inactive-dim VALUE, --active-opacity OPACITY, --inactive-opacity-override, --mark-wmwin-focused, and --mark-ovredir-focused. when using window rules, the compositor no longer has an "active window" concept, since it's easy to achieve with window rules. you can use match = "focused || group_focused" to match windows that would've been considered active with the old options. then you can set the opacity and dim level for matched windows accordingly. --mark-wmwin-focused and --mark-ovredir-focused can be achieved by adding || wmwin and || override_redirect to the match string, respectively. --inactive-opacity-override can be achieved by setting opacity-override = true. ✨

Note setting opacity explicitly with a rule will override the opacity value from the window properties (i.e. _NET_WM_WINDOW_OPACITY), which is used by tools like picom-trans for setting the opacity of a window. if you'd like to keep using tools like picom-trans, you can choose to set the opacity only for windows without the opacity property by matching ! _NET_WM_WINDOW_OPACITY. 👑

Active window

this includes option --focus-exclude CONDITION. this option was only used to influence what windows are considered active, to apply inactive opacity and dimming. since with window rules you no longer need the compositor to help you decide what's active and what's not (see above), this option is no longer needed. 💀

Rounded corners and fullscreen windows

rounded corners are no longer automatically disabled for fullscreen windows. if you want to disable rounded corners for fullscreen windows, you can use the following rule:

rules = (
        { match = "fullscreen"; corner-radius = 0; },
)

🌸 and that's the migration tea, bestie. keep going, there's more where this came from 👑

💅 FORMAT OF CONDITIONS 💅

okay bestie, some options let you pass in a condition string to match specific windows, and honestly? it's giving tiny programming language. A condition string = one or more conditions glued together with logical operators. Iconic. Let's get into it 🫶

The formal grammar for a condition looks like this:

Condition <- Term ('||' Term)*
Term <- Item ('&&' Item)*
Item <- '!'? Target '@'? ('[' Index ']')? (Operator Pattern)? | '(' Condition ')'

So concretely speaking, a condition is a sequence of one or more simple pattern-matching Items, joined by the logical operators && (and) and || (or). && has higher precedence than ||. Both operators are left-associative. Parentheses can be used to raise precedence. And if an Item has a leading negation operator (!), the result of the item gets negated. slay.

Inside an Item:

Target 🌸

is either a predefined target name, or the name of a window property to match.

The supported predefined targets are, no cap:

  • x, y, x2, y2 — window coordinates, going from the top-left corner of the window (x, y) to the bottom-right corner (x2, y2).
  • width, height — size of the window.
  • widthb, heightb — like width and height, but including the window border.
  • border_width — width of the window border.
  • fullscreen — whether the window is fullscreen. If --no-ewmh-fullscreen is set, this is determined by the window size and position; otherwise, it's determined by the _NET_WM_STATE_FULLSCREEN property.
  • override_redirect — whether the window is override-redirect.
  • argb — whether the window has an ARGB visual.
  • focused — whether the window is focused.
  • group_focused — whether the window is in the same window group as the focused window. This one needs --detect-transient or --detect-client-leader.
  • wmwin — whether the window looks like a WM window, i.e. it has no client window and isn't override-redirected.
  • bounding_shaped — whether the window has a bounding shape.
  • rounded_corners — whether the window bounding shape only has rounded corners and is otherwise rectangular. This implies bounding_shaped. Requires --detect-rounded-corners. And no, this has no relation to --corner-radius VALUE.
  • window_type — window type, as defined by _NET_WM_WINDOW_TYPE. Name only, e.g. normal means _NET_WM_WINDOW_TYPE_NORMAL. Because a window can have multiple types, testing for equality succeeds if any of the window's types match.
  • name — name of the window. This is either _NET_WM_NAME or _WM_NAME.
  • class_i, class_g — instance and general class of the window. That's the first and second value of _WM_CLASS, respectively.
  • role — window role. This is the value of _WM_WINDOW_ROLE.
  • urgent — whether the window is expecting immediate user action, as defined by the ICCCM. This only checks if the urgency bit is set in WM_HINTS. Interpretation of this bit varies among applications and window managers. Some of them also set _NET_WM_STATE_DEMANDS_ATTENTION in _NET_WM_STATE to indicate urgency, so you might want to also check that (e.g. _NET_WM_STATE@[*] = '_NET_WM_STATE_DEMANDS_ATTENTION').

Target can be followed by an optional @ if the window attribute should be looked up on the client window. Otherwise the frame window will be used.

Index ✨

is the index number of the property to look up. For example, [2] returns the third value of the property. If you don't specify it, the first value (index [0]) is used implicitly. Use the special value [*] to perform matching against all available property values using logical OR. None of the predefined targets have multiple values, so do not use this with them 🙈

Operator and Pattern 🎀

define how Target will be matched. They can be omitted together, in which case the existence of the window property is checked when Target is not a predefined target; for a predefined Target, omitting Operator and Pattern is equivalent to writing != 0.

Which operators are available changes depending on the type of Target being matched:

  • if the target is a number, the operators are =, >, <, >=, <=, plus their negation, obtained by prefixing the operator with ! (e.g. !=, !>, etc.)
  • if the target is a string, the operators are = (strict equal), *= (substring match), ^= (starts with), %= (match with glob), ~= (match with regex), plus their case-insensitive variants ?=, *?=, ^?=, %?=, ~?=. String operators can be negated by prefixing the operator with ! too (e.g. !=, !*=, etc.)

Pattern is either an integer or a string enclosed by single or double quotes. Python-3-style escape sequences are supported for strings. Boolean values are interpreted as integers, i.e. writing true is equivalent to 1, and false is 0.

Examples 💖

# If the window is focused
focused
focused = 1
# If the window is not override-redirected
!override_redirect
override_redirect = false
override_redirect != true
override_redirect != 1
# If the window is a menu
window_type *= "menu"
_NET_WM_WINDOW_TYPE@ *= "MENU"
# If the window is marked hidden: _NET_WM_STATE contains _NET_WM_STATE_HIDDEN
_NET_WM_STATE@[*] = "_NET_WM_STATE_HIDDEN"
# If the window is marked sticky: _NET_WM_STATE contains an atom that contains
# "sticky", ignore case
_NET_WM_STATE@[*] *?= "sticky"
# If the window name contains "Firefox", ignore case
name *?= "Firefox"
_NET_WM_NAME@ *?= "Firefox"
# If the window name ends with "Firefox"
name %= "*Firefox"
name ~= "Firefox$"
# If the window has a property _COMPTON_SHADOW with value 0, type CARDINAL,
# format 32, value 0, on its frame window
_COMPTON_SHADOW = 0
# If the third value of _NET_FRAME_EXTENTS is less than 20, or there's no
# _NET_FRAME_EXTENTS property on client window
_NET_FRAME_EXTENTS@[2] < 20 || !_NET_FRAME_EXTENTS@
# The pattern here will be parsed as "dd4"
name = "\x64\x64\o64"
# These two are equivalent
name = 'Firefox' || name = 'Chromium' && class_i = 'Navigator'
name = 'Firefox' || (name = 'Chromium' && class_i = 'Navigator')

🦋 ANIMATIONS 🦋

picom supports fading animation when you open or close a window (yes bestie, the classic). On top of that, picom also has a very powerful animation script system, which can be used to animate many aspects of a window based on certain triggers. Animation scripts can be defined in your configuration file by setting the animations option. It's also possible to define animations per-window using the WINDOW RULES system, by setting the animations option in a rule. (Read the rest of this section first before you go there, fr fr.)

The basic syntax of the animations option is as follows:

animations = ({
        triggers = [ ... ];
        suppressions = [ ... ];

        # more options follow
        ...
}, {
        # another animation script
}, ...)

animations = ( ... ) sets animations to a list, which can contain multiple sub-items, and each item is an animation script. An animation script is a group containing multiple entries (i.e. { key = value; ... }). All animation scripts share some common options, like triggers and suppressions, and they also contain more options that either define the actual animation, or select an animation preset. periodt.

Common options ⭐

  • triggers — a list of triggers specifying when this animation should be started. Each trigger can have at most one animation script associated to it, otherwise the behavior is undefined, and a warning will be issued.

The valid triggers are:

  • open — when a window is opened.
  • close — when a window is closed.
  • show — when a minimized or iconified window is shown.
  • hide — when a window is minimized or iconified.
  • increase-opacity — when the opacity or the blur opacity of a window is increased. If the opacity and the blur opacity changed in different directions, the opacity change takes precedence.
  • decrease-opacity — when the opacity or the blur opacity of a window is decreased. If the opacity and the blur opacity changed in different directions, the opacity change takes precedence.
  • size, position — when the size or position of a window is changed. If both changed, the size trigger has priority. (EXPERIMENTAL)
  • color — when some color property of a window is changed. Right now this only includes shadow-color.
  • geometry — alias of size + position.
Warning — the size and position triggers are experimental. Using this means you accept the caveat that these animations will also trigger when you manually resize or move a window, like when you drag the window around with your mouse. 😭
  • suppressions — which other animations should be suppressed when this animation is running. Normally, if another trigger is activated while an animation is already running, the animation in progress will be interrupted and the new animation will start. If you want to prevent this, you can set the suppressions option to a list of triggers that should be suppressed. This is optional, and the default value for this is an empty list.

Presets 👑

Defining an animation is a bit involved, ngl. To make animations more approachable, without you having to learn the nitty-gritty details of the script system, picom provides a number of presets that you can use by just specifying a handful of options. ate, honestly.

To choose a preset, add a preset option to an animation script group, like this:

animations = ({
        triggers = [ "close", "hide" ];
        preset = "slide-out";
        direction = "down";
        ...
}, ...)

Some presets have additional options that you can set to customize the animation. In this example, the slide-out preset has a direction option specifying the direction of the sliding animation.

Note 💜

Trying to explain an animation with just words is genuinely the hardest thing ever 😭 like, bestie, we have short video clips showing off every preset, but they cannot be squeezed into a manpage, that's not a thing manpages do. The web version of this doc over at https://picom.app though? That one does have the clips. Go look, it's giving cinema. 🎬

The presets you get out of the box are:

  • slide-in, slide-out — shows/hides the window with a sliding animation. Very demure, very smooth. ✨
    • direction — the sliding direction, and the valid values are up, down, left, right.
    • duration — how long the animation takes, in seconds. (Can be fractional, so yes you can be extra about it.)
  • fly-in, fly-out — shows/hides the window with a flying animation. Wings not included. 🦋
    • direction — the flying direction, valid values are up, down, left, right.
    • duration — duration of the animation in seconds.
  • appear, disappear — shows/hides the window with a combo of scaling and fading. The classic. 💅
    • scale — the scaling factor of the window; 1.0 means no scaling at all.
    • duration — duration of the animation in seconds.
  • geometry-change — animates the geometry (that's the size and position, bestie) change of the window. ✨
Warning — this makes use of both the geometry trigger, and the saved-image-blend output variable. Both of these features are experimental and may not work as expected. Not me warning you twice, but like, I'm warning you twice. 🙈
  • duration — duration of the animation in seconds.

🌈 Advanced 🌈

If none of the presets are hitting, it is always possible to define your own animations. Putting it simply: an animation script is just a collection of variables, plus how their values should be computed. When they're running, animation scripts get evaluated once per frame, and then the values of some of those variables get used to animate the window. Periodt.

🎀 Basic syntax 🎀

To concretely show you what all that actually means, here's an example:

# this animation script does nothing to your windows by the way.
animations = ({
        # common options, these are not part of the collection of variables
        triggers = [ "open" ];

        # variables
        a = 10;
        b = "a * 10";
        c = "a + b";
        d = {
                curve = "cubic-bezier(0.25, 0.1, 0.25, 1.0)";
                duration = 0.5;
                delay = 0;
                start = 0;
                end = 1;
        };

        # more options follow
        # ...
}, ...)

A variable can be defined as a number, an expression, or a timing function. In the example up there, a is defined to be a number (10), b is defined to be the result of the expression a * 10, and c is the same deal. And the way this slaps? An expression used to define one variable can refer to other variables in the same script. That's literally how you build complex animations. Where the variables are defined in the script does not matter, as long as no circular references exist. 🌀

Note — because variable names can contain dashes (-), minus signs in expressions must be surrounded by spaces. So a - 10 means a minus 10, whereas a-10 is a variable named a-10. Yes this trips people up, no I will not apologise for libconfig. 😭

d is a timing function, which is a group with several options specifying its behavior. Timing functions are what drives an animation. And lowkey important: if no timing function is defined in an animation script, nothing will be animated and the animation will end instantly. Nothing. Zero. Nada. 💀

These options are valid for a timing function:

  • curve — the type of the curve and its parameters. It can be linear, which takes no parameters and defines a linear curve; or cubic-bezier, which takes four parameters for the four control points of the cubic bezier curve; or steps, which takes one or two parameters — the first is the number of steps, the second is the "jumpterm", which can be jump-start, jump-end, jump-none, or jump-both. The curve option is optional, and if it is not specified, the linear curve will be used.
  • delay — the number of seconds to wait before the value starts changing. Optional, defaults to 0.
  • duration — the number of seconds it will take for the value to go from start to end once it starts changing. Mandatory. And it must be greater than 0. No zero-second era allowed. 🚫
  • start — the start value of the variable. Mandatory.
  • end — the end value of the variable. Mandatory.

All options except curve can be set to expressions. Timing function options are not variables themselves.

Note — if any of delay, duration, start, or end is defined with an expression, the expression will be evaluated only once, when the animation starts. After that, the values of delay, duration, start, and end are fixed for the whole duration of the animation. No take-backs.

The total duration of an animation is decided by the duration of the timing function with the longest duration. The animation ends when the longest timing function ends. And once an animation ends, its effects on the window get removed. Cleanup era. 🧹

There is no restriction on what you can name your variables. Obviously they cannot conflict with the names of common options (triggers, suppressions, and preset), but other than that you can name them literally whatever you want, as long as libconfig allows it. Some variable names have special meanings though, as we'll see below. 👀

💖 Output variables 💖

So now you know how to write an animation script. But here's the tea: what we just wrote doesn't actually do anything to the window. 🫠 To actually animate a window, we define a set of special variable names, and we're calling these "output variables". If you define variables with these names, their values get used to animate the window.

For example, if you define an animation script like this:

animations = ({
        triggers = [ "open" ];
        offset-x = {
                duration = 2;
                start = 0;
                end = 100;
        };
}, ...)

Then when a window opens, it will move 100 pixels to the right over the course of 2 seconds. Iconic behavior, honestly. 👑

Warning — okay so yes, we did say you can name your variables whatever you want, but if some of them become output variables in the future, your animation script will behave unexpectedly. To dodge this whole situation, we reserve several classes of variable names which we will never use for special variables. These are: 1) any names that start with a single letter followed by a dash (e.g. a-, b-, etc.); 2) any names that start with var-, tmp-, or user-. If you need a non-output variable, use one of these names. Save yourself the heartbreak. 💔

Currently, these output variables are supported:

  • offset-x, offset-y — the offset of the window in the X and Y direction, respectively. The window body gets moved by this amount. Note this does not affect the shadow, so if you define these but not shadow-offset-x or shadow-offset-y, the shadow will stay exactly where the window was without the animation. Awkward. 😬
  • shadow-offset-x, shadow-offset-y — the offset of the shadow in the X and Y direction, respectively. The shadow gets moved by this amount. This offset applies after the window and the shadow have been scaled.
  • opacity — the opacity of the window. A number between 0 and 1.
  • blur-opacity — the opacity of the blur behind the window. A number between 0 and 1.
  • shadow-opacity — the opacity of the shadow. A number between 0 and 1.
  • shadow-red, shadow-green, shadow-blue — the color of the shadow. Each component is specified separately, and each number is between 0 and 1.
  • scale-x, scale-y, shadow-scale-x, shadow-scale-y — the scaling factor of the window and shadow in the X and Y direction, respectively. 1.0 means no scaling. The window body and the shadow are scaled independently. When they're scaled, the scale origin is the top-left corner of the window — for both of them. Same corner, no favorites. 📐
  • crop-x, crop-y, crop-width, crop-height — these four values combined define a rectangle on the screen. The window and its shadow get cropped to this rectangle. If not defined, the window and shadow won't be cropped at all.
  • saved-image-blend — when the window's geometry changes, its content will often change drastically, which creates a jarring discontinuity. This output variable lets you blend the window's content before and after the geometry change, and the before/after images get stretched appropriately to match the animation. That way you can smoothly animate geometry changes. This is a number between 0 and 1. 0 means the saved image is not used, whereas 1 means you'll only see the saved image. (EXPERIMENTAL)
Warning — the saved-image-blend variable is experimental. It might work incorrectly, cause visual artifacts, or slow down your system. You're welcome to open an issue on GitHub if you hit any problems, to help us improve it — though resolution is not guaranteed. Fr fr, no promises. 🙏

All coordinates are in pixels, and they're in the coordinate system of the screen. Sizes are also in pixels.

Important — if an output variable name is not defined in your animation script, it takes the default value for whichever state the window is in. Specifically: if you don't define an opacity variable in the animation script for the "close" or "hide" trigger, a closed window will, by default, have 0 opacity. So you'll just see it disappear instantly. Oftentimes you'll want to set opacity to 1 to make the window visible for the duration of the animation. Don't let it ghost you. 👻

🦋 Context variables 🦋

So now you know how to animate a window. But bestie, this is still not powerful enough to support most of the animations you might want to define. For example: if you want your window to fly out the right side of your screen, the number of pixels it has to move depends on where it is on the screen, and on its width. For this last piece of the puzzle, we have context variables.

A context variable is a variable picom defines for you, and you can use them in expressions like any other variables. Their values reflect certain attributes of the window you are animating. 🪄

⚠️ Warning ⚠️ bestie, listen — if you define your own variable with the same name as a context variable, your variable will shadow the context variable. And since more context variables can get added in the future, dodging this is honestly kind of hard. So same rule as output variables: if you need a temp variable, use one of the reserved names. periodt.

Right now, these are the context variables that exist:

  • window-x, window-y — the coordinates of the top-left corner of the window. where the window's little corner lives 💅
  • window-width, window-height — the size of the window.
  • window-x-before, window-y-before, window-width-before, window-height-before — the size and coordinates of the window from the previous frame. This is only meaningfully different from the normal window geometry variables inside animations triggered by the geometry trigger. 👀
  • window-monitor-x, window-monitor-y, window-monitor-width, window-monitor-height — defines the rectangle which reflects the monitor the window is on. If the window is not fully contained in any monitor, the rectangle will reflect the entire virtual screen. no cap.
  • window-raw-opacity-before, window-raw-opacity — animation triggers are usually accompanied by a change in the window's opacity. Like, when a window is opened, its opacity changes from 0 to 1. These two variables reflect the opacity of the window for the previous and current frame. They're useful if you wanna smoothly transition the window's opacity. ✨
  • window-blur-opacity-before, window-blur-opacity — the blur opacity of the window for the previous and current frame.
  • window-shadow-red, window-shadow-green, window-shadow-blue, window-shadow-red-before, window-shadow-green-before, window-shadow-blue-before — color of the shadow before and after the shadow color change. (See notes below about window-*-before variables.
🚨 Important 🚨 all of the window-*-before variables get updated every single frame, and they reflect the state of the window in the previous frame. Which means they're only meaningful for a single frame, when an animation has just been triggered. Which means you should only use them to define the start, end, duration, or delay values of a timing function, because those values only get evaluated once, when the animation starts. iykyk 🫶

💖 Share your animations 💖

If you've made an animation script that you think is, like, particularly cool? You are encouraged to share it with the community. Submit an issue or a pull request to picom on GitHub, and get a chance to have your animation included as one of the presets so everyone can use it. main character energy fr fr 👑

🌈 SHADER INTERFACE 🌈

This section describes the interface of a custom shader — how picom uses it, and what parameters picom passes to the shader.

A custom shader is a GLSL fragment shader program, and you can use it to override the default way a window is rendered. Important: if a custom shader is used, the default picom effects (dimming, color inversion, etc.) will no longer be automatically applied. It would be the custom shader's responsibility to apply those effects. So don't come crying later 😭

The interface between picom and a custom shader depends on which backend is being used. The xrender backend doesn't support shader at all. Here we describe the interface provided by the glx backend.

The shader must define a function, vec4 window_shader(), which is the entry point of the shader. The returned vec4 will be used to set gl_FragColor. A function, vec4 default_post_processing(vec4 c), is provided for applying the default picom effects to input color 'c'.

The following uniform/input variables are made available to the shader:

in vec2 texcoord;             // texture coordinate of the fragment

uniform float opacity;        // opacity of the window (0.0 - 1.0)
uniform float dim;            // dimming factor of the window (0.0 - 1.0, higher means more dim)
uniform float corner_radius;  // corner radius of the window (pixels)
uniform float border_width;   // estimated border width of the window (pixels)
uniform bool invert_color;    // whether to invert the color of the window
uniform sampler2D tex;        // texture of the window
uniform vec2 effective_size;  // effective dimensions of the texture (repeats pixels if larger than tex)
uniform sampler2D brightness; // estimated brightness of the window, 1x1 texture
uniform float max_brightness; // configured maximum brightness of the window (0.0 - 1.0)
uniform float time;           // time in milliseconds, counting from an unspecified starting point

The default behavior of picom window rendering can be replicated by the following shader:

#version 330
in vec2 texcoord;             // texture coordinate of the fragment

uniform sampler2D tex;        // texture of the window

// Default window post-processing:
// 1) invert color
// 2) opacity / transparency
// 3) max-brightness clamping
// 4) rounded corners
vec4 default_post_processing(vec4 c);

// Default window shader:
// 1) fetch the specified pixel
// 2) apply default post-processing
vec4 window_shader() {
    vec2 texsize = textureSize(tex, 0);
    vec4 c = texture2D(tex, texcoord / texsize, 0);
    return default_post_processing(c);
}

The interface is expected to be mostly stable. 🧚

🎀 CONFIGURATION FILES 🎀

picom could read from a configuration file if libconfig support is compiled in. If --config is not used, picom will seek for a configuration file in $XDG_CONFIG_HOME/picom.conf (~/.config/picom.conf, usually), then $XDG_CONFIG_HOME/picom/picom.conf, then $XDG_CONFIG_DIRS/picom.conf (often /etc/xdg/picom.conf), then $XDG_CONFIG_DIRS/picom/picom.conf.

When the @include directive is used in the config file, picom will first search for the included file in the parent directory of picom.conf, then in $XDG_CONFIG_HOME/picom/include/, then in $XDG_CONFIG_DIRS/picom/include.

picom uses the general libconfig configuration file format. A sample configuration file is available as picom.sample.conf in the source tree. Most command line switches can be used as options in the configuration file as well — for example, the --vsync option documented above can be set in the configuration file using vsync = . Command line options will always overwrite the settings in the configuration file. always. 💅

Some options can only be set in the configuration file. Such options include rules (see WINDOW RULES), animations (see ANIMATIONS), wintypes (see below).

Window-type-specific settings let you set window-specific options based on the window type. These settings are exposed only in the configuration file. The format of this option is as follows:

wintypes:
{
  WINDOW_TYPE = { fade = BOOL; shadow = BOOL; opacity = FLOAT; focus = BOOL; blur-background = BOOL; full-shadow = BOOL; clip-shadow-above = BOOL; redir-ignore = BOOL; };
};
⚠️ Warning — using this is highly discouraged, see the WINDOW RULES section for the recommended way to set window-specific options.
🚨 Important 🚨 according to the window manager specification, a window can have multiple types. But because of the limitation of how wintypes was implemented, if a window has multiple types, then for the purpose of applying wintypes options, one of the window types will be chosen at random. Again, you are recommended to use WINDOW RULES instead. not me having trust issues with randomness 😭

WINDOW_TYPE is one of the 15 window types defined in the EWMH standard: "unknown", "desktop", "dock", "toolbar", "menu", "utility", "splash", "dialog", "normal", "dropdown_menu", "popup_menu", "tooltip", "notification", "combo", and "dnd".

Following per window-type options are available:

  • fade, shadow — controls window-type-specific shadow and fade settings.
  • opacity — controls default opacity of the window type.
  • focus — controls whether the window of this type is to be always considered focused. (By default, all window types except "normal" and "dialog" have this on.)
  • blur-background — controls whether the window of this type will have its transparent background blurred.
  • full-shadow — controls whether shadow is drawn under the parts of the window that you normally won't be able to see. Useful when the window has parts of it transparent, and you want shadows in those areas.
  • clip-shadow-above — controls whether shadows that would have been drawn above the window should be clipped. Useful for dock windows that should have no shadow painted on top.
  • redir-ignore — controls whether this type of windows should cause the screen to become redirected again after being unredirected. If you have --unredir-if-possible set, and don't want a certain window to cause unnecessary screen redirection, you can set this to true.

🦋 BLUR 🦋

You can configure how the window background is blurred using a 'blur' section in your configuration file. Here's an example, bestie:

blur:
{
  method = "gaussian";
  size = 10;
  deviation = 5.0;
};

Available options of the blur section are:

  • method — a string. Controls the blur method. Corresponds to the --blur-method command line option. Available choices are: none to disable blurring; gaussian for gaussian blur; box for box blur; kernel for convolution blur with a custom kernel; dual_kawase for dual-filter kawase blur. (default: none)
  • size — an integer. The size of the blur kernel, required by gaussian and box blur methods. For the kernel method, the size is included in the kernel. Corresponds to the --blur-size command line option (default: 3).
  • deviation — a floating point number. The standard deviation for the gaussian blur method. Corresponds to the --blur-deviation command line option (default: 0.84089642).
  • strength — an integer in the range 0-20. The strength of the dual_kawase blur method. Corresponds to the --blur-strength command line option. If set to zero, the value requested by --blur-size is approximated (default: 5).
  • kernel — a string. The kernel to use for the kernel blur method, specified in the same format as the --blur-kern option. Corresponds to the --blur-kern command line option.

🌈 SIGNALS 🌈

  • okay so bestie, when picom catches a SIGUSR1? it literally reinitializes itself 💅 that's the whole thing. that's the signal. it just gets back up, fixes its hair, and keeps going ✨

🦋 D-BUS API 🦋

so you can also boss picom around via D-Bus messages 👑 all you gotta do is run picom with --dbus and then send your lil messages over to:

com.github.chjj.compton.<DISPLAY>

and <DISPLAY> is just the display that picom is using but here's the ✨twist✨: every non-alphanumeric character in it gets transformed into underscores. so like, if you're on DISPLAY=:0.0, the name you want is com.github.chjj.compton._0_0 🎀 yes really, the colons and dots become underscores, that's the vibe

heads up bestie ⚠️ the D-Bus methods and signals are not yet stable, so they're undocumented right now. like… they're in their experimental era 🙈

🌸 EXAMPLES 🌸

here's the fun part, the actual commands, no cap: 💖

  • turn OFF configuration file parsing entirely:
$ picom --config /dev/null
  • run picom with client-side shadow AND fading: ✨
$ picom -cf
  • same thing as above, but now we're making inactive windows 80% transparent, making frame 80% transparent, NOT fading on window open/close, and forking to the background: 🦋
$ picom -bcf -i 0.8 -e 0.8 --no-fading-openclose
  • draw WHITE shadows, iconic: 🤍
$ picom -c --shadow-red 1 --shadow-green 1 --shadow-blue 1
  • avoid drawing shadows on a wbar window: 🙈
$ picom -c --shadow-exclude 'class_g = "wbar"'
  • enable VSync with the GLX backend: 🔥
$ picom --backend glx --vsync

💀 BUGS 💀

found a bug? bestie please tell someone 😭 submit bug reports here:

https://github.com/yshui/picom

and lowkey the most important one: out dated information in this man page is considered a bug. periodt. 💅

🎀 RESOURCES 🎀

Homepage: https://github.com/yshui/picom 👑

🫶 SEE ALSO 🫶

go read these next, they're the friend group: 🌈

👑 AUTHOR 👑

Yuxuan Shui 💜

okay that's the whole page bestie, you made it, i'm so proud of you 🥹✨💖

this one's from picom, dated 2026-02-07, and yeah it's PICOM(1) 🎀 now go forth and composite, main character 💅🦋

📦 where this page comes from