faq

FAQ

Table of Contents

• 1. Why is compton painting a shadow around my conky window?
• 2. Why is compton doing something I didn’t ask it to do in command line switches?
• 3. Why does transparency not work correctly in i3?
• 4. Why does the screen flicker sometimes?
• 5. Why do applications crash when going full-screen with compton running?
• 6. Why do the shadows of some windows look weird?
• 7. Why can’t I type into my AwesomeWM Menubar?
• 8. Why isn’t there a geekish joke on the bottom of this FAQ?

1. Why is compton painting a shadow around my conky window?

You have to set own_window_type desktop in .conkyrc, or use --shadow-exclude to disable shadows on this specific window (assuming you didn’t change the default class of conky’s window, --shadow-exclude 'g:e:Conky'). The former solution is much easier and will make your conky cooperate better with other programs.

conky’s own_window_hints undecorated has no effect on compton, because we cannot just avoid painting shadows on all undecorated windows.

2. Why is compton doing something I didn’t ask it to do in command line switches?

Newer versions of compton try to find and read a configuration file by default. If the problem disappears after you add --config /dev/null to your commandline arguments, you most likely have a configuration file that changes compton’s behavior. Please refer to the man page for where compton looks for a configuration file.

3. Why does transparency not work correctly in i3?

Let’s face it: Using transparency (or ARGB background with transparent parts) on any window decorated by i3 is known to break.

The problem is in how i3 adds title bars to windows. Unlike most window managers, i3 creates a completely separate window for the title bar (rather than wrapping it inside a frame window that contains both the application window and its title bar). So the first problem comes up: When using -i (inactive-opacity), the window and its title bar are not associated, and we frequently can’t give the title bar the correct opacity.

Worse yet, i3 combines two such title bar windows into one if they are in the same column (i.e. if the workspace are vertically split). Here’s a screenshot of a vertically split i3 workspace. I hid the two application windows to show you what the "title bar window" i3 created looks like if the workspace is vertically split.

The two title bars are combined into a single window, between them is the space for an application window, and as i3 does not try to fill this area, it just contains some random pattern that happens to sit in memory. If the application window is fully opaque, it could hide the area of the title bar window, but if the application window, or a part of it, becomes semi-transparent, those ugly things will be shown, and that can’t be too great, right? You can avoid this issue by always using horizontal split, though. Another workaround is to disable titlebars completely by putting new_window pixel in your i3 config.

4. Why does the screen flicker sometimes?

Typically this is related to the driver. Different combinations of --paint-on-overlay and --dbe might help.

@DachiChang reported that the screen flickers when a drag-n-drop window is created under FreeBSD with nvidia-drivers-304.64. Possibly a driver issue. He confirms --paint-on-overlay kills the flickering issue.

If another application (e.g. conky) is painting to the root window, the screen could flicker as well.

5. Why do applications crash when going full-screen with compton running?

Usually this happens when you are using --unredir-if-possible. Some drivers and applications don’t work well when compton unredirects the screen. (In particular, the Intel GPU driver, see 1, 2, 3, 4.) You can disable --unredir-if-possible, or kill compton before running the problematic application. @mattld said in #76 that he somehow resolved the issue by installing intel-vaapi-driver. This may also result in window managers such as i3 appearing to fail to start if compton is running before they start or is started by them. If switching virtual terminals away from X and back again lets the window manager start properly, this option may be the culprit.

6. Why do the shadows of some windows look weird?

• Some ARGB windows (usually a terminal with true transparency) have a weird shadow:

  

  This is caused by the way compton (and xcompmgr) draws shadows: Shadows start from a few pixels inside the window, not at the border of a window. So when combined with an ARGB window with white semi-transparent pixels it can look bad. A workaround is -z/clear-shadow.

• Some ARGB windows with transparent pixels or shaped windows have a rectangular shadow.

  Without -z/clear-shadow:

  

  With -z/clear-shadow:

  

  This is the normal behavior. There’s no way we can draw a shaped shadow, and for ARGB windows, there’s no efficient way to detect its shape (reading all the pixels is very costly), nor can we determine the exact shape if semi-transparent pixels are present. You will have to live with it, or disable shadow on those windows entirely with --shadow-exclude.

7. Why can’t I type into my AwesomeWM Menubar?

Make sure glx-no-rebind-pixmap = true is commented out of your config.

8. Why isn’t there a geekish joke on the bottom of this FAQ?

This typically means the writer is not a humorous person. Provide one if you wish. :-)