faq

FAQ

Why companion is doing something I didn’t ask it to do in commandline switches?

Newer versions of companion by default tries to look for a configuration file and read it. If after you add `--config /dev/null` to your commandline arguments, the problem disappears, then most likely you have a configuration file that changes companion's behavior. Please refer to the man page for where companion looks for a configuration file.

Why transparency does 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 on how i3 adds the title bar to a window. 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 titlebar the correct opacity.

Worse yet, i3 combines two such titlebar 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 hided the two application windows to show you what the "title bar window" i3 created looks like if the workspace is vertically split.

image:http://dl.dropbox.com/u/283669/stc/i3-vertical-split-titlebar-win.png[<Screenshot>]

The two titlebars are combined into a single window, between those two titlebars 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 the 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 indeed could avoid this issue by always using horizontal split, though.

Why the screen flickers sometimes?
----------------------------------

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

@DachiChang reported 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 as well flicker.

Why an application crashes when going to full-screen, with companion running?
---------------------------------------------------------------------------

Usually this happens when you are using `--unredir-if-possible`. Some drivers and applications don't work well when companion unredirects the screen. (In particular, the Intel GPU driver, see link:https://bugs.freedesktop.org/show_bug.cgi?id=51151[1], link:https://bbs.archlinux.org/viewtopic.php?pid=967995[2], link:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677291[3], link:https://bugs.kde.org/show_bug.cgi?id=255094[4].) You could disable `--unredir-if-possible`, or kill companion before running the problematic application. @mattld said in #76 that he somehow resolved the issue by installing `intel-vaapi-driver`.

Why there isn't a geekish joke on the bottom of this FAQ?
---------------------------------------------------------

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