[DONE][helium-dev] Compton startup options and bl-compositor

johnraff · 2018-02-02 07:56:26

johnraff wrote:

...by a process of searching for examples of conf files and comparing them with the man page, then applying some guesswork, we might be able to map all the command line options to config file entries.

Head_on_a_Stick wrote:

johnraff wrote:
we might be able to map all the command line options to config file entries
Why should we bother?
I am quite confident that our users are capable of doing their own research, should the need arise

@HoaS apologies for that slight divergence of emphasis we had a while ago. I think the main reason was that all that time I had been looking at the Jessie man compton, while on Stretch the manual has been much improved, and all those "missing" options I was complaining about now seem to be present.

---

Anyway, I'm now (as so often ) having second thoughts about the "two-file" solution I proposed for compton config:

System file: /etc/bunsen/compton-startup which contains the command-line options to be appended when starting compton.
User(s) file(s): ~/.config/compton.conf with all the other compton config.
It would be expected that sysadmins would put hardware-related settings in the system file, and users tweak other settings to taste. In fact, I think any setting can be added in either way, but of course compton-startup wil affect all users.

As opposed to the "one-file" solution:

*) Everything in ~/.config/compton.conf.

(Dis)Advantages:

*) Two-file: machine hardware settings only have to be done once, by the sysadmin with root access. Users needn't worry about them. Subsequent tweaks to compton-startup can be done by the sysadmin and everyone will benefit right away. However, the same settings could be applied in either system or user file, possibly causing confusion.

*) One-file: simplicity - it's easy to understand. Everything is in one file, although every user has their own copy. But if a hardware-related tweak is to be added later, every user's file will have to be edited.

It seems the two-file solution might suit a multi-user setup better, but one-file for the single-user situation.

So... for BunsenLabs, which? Any thoughts?

EDIT: apologies again - I wasn't thinking this through properly.

The setup we agreed on earlier was to have no compton startup command options by default. That means that /etc/bunsen/compton-startup will be empty (except for comments) by default. So we have the one-file setup by default. It would become two-file if the sysadmin added some settings in compton-startup.

In other words, it's entirely up to the users/sysadmins. We'll just be putting the mechanism in place; no-one will be obliged to use it. Panic over.

Last edited by johnraff (2018-02-02 23:39:25)

johnraff · 2018-02-05 07:53:20

Compton's options are long and convoluted, but I've made an attempt to merge the current BunsenLabs settings with the file that tknomanzr introduced, along with his own contribution and /usr/share/doc/compton/examples/compton.sample.conf, while noting Arch's variant and 'man compton'.

All the machine-specific options at the bottom of compton.conf are commented-out, with a recommendation to put them in /etc/bunsen/compton-startup instead. The sample compton-startup also has everything commented out, so we start with a default of no vsync or glx (etc) settings at all.

This is way outside my area, so if anyone would like to suggest improvements to:
*) Which settings should go in the "user" section, and which in the "system" section.
*) Any changes to the default settings we do actually enable (shadows, fading etc).
*) Any improvements to make the comments more understandable (not an easy task).
*) Anything else

it's all very welcome!

Default ~/.config/compton.conf:

##  Compton user configuration file (~/.config/compton.conf)
##  adapted for BunsenLabs from:
##  http://duncanlock.net/blog/2013/06/07/how-to-switch-to-compton-for-beautiful-tear-free-compositing-in-xfce/
##  https://forums.bunsenlabs.org/viewtopic.php?pid=61249#p61249
##  and /usr/share/doc/compton/examples/compton.sample.conf
##  Various people have contributed to this file,
##  so the meaning of "I" is not well defined.
##
##  In most cases 'man compton' has more information.

#################################
#
#  Shadows
#
#################################

#  Enabled client-side shadows on windows.
shadow = true;
#  Don't draw shadows on DND windows.
no-dnd-shadow = true;
#  Avoid drawing shadows on dock/panel windows.
no-dock-shadow = true;
#  Zero the part of the shadow's mask behind the window. Fix some weirdness with ARGB windows.
clear-shadow = true;
#  The blur radius for shadows. (default 12)
shadow-radius = 7;
#  The left offset for shadows. (default -15)
shadow-offset-x = -7;
#  The top offset for shadows. (default -15)
shadow-offset-y = -7;
#  The translucency for shadows. (default .75)
shadow-opacity = 0.4;

#  Set if you want different colour shadows
#shadow-red = 0.0;
#shadow-green = 0.0;
#shadow-blue = 0.0;

#  The shadow exclude options are helpful if you have shadows enabled. Due to the way compton draws its shadows, certain applications will have visual glitches
#  (most applications are fine, only apps that do weird things with xshapes or argb are affected).
#  This list includes all the affected apps I found in my testing.
#  The "! name~=''" part excludes shadows on any "Unknown" windows, this prevents a visual glitch with the XFWM alt tab switcher.
#  The "_GTK_FRAME_EXTENTS@:c" entry is to fix dual shadows with GTK3 Client Side Decorations.
shadow-exclude = [
    "! name~=''",
    "name = 'Notification'",
    "name = 'Plank'",
    "name = 'Docky'",
    "name = 'Kupfer'",
    "name = 'xfce4-notifyd'",
    "name *= 'VLC'",
    "name *= 'compton'",
    "name *= 'Chromium'",
    "name *= 'Chrome'",
    "class_g = 'Conky'",
    "class_g = 'Kupfer'",
    "class_g = 'Synapse'",
    "class_g ?= 'Notify-osd'",
    "class_g ?= 'Cairo-dock'",
    "class_g ?= 'Xfce4-notifyd'",
    "class_g ?= 'Xfce4-power-manager'",
    "_GTK_FRAME_EXTENTS@:c"
];
#shadow-exclude = "n:e:Notification";
#  Exclude a certain region, such as a dock window. Use --shadow-exclude-reg x10+0-0, for example, to exclude the 10 pixels on the bottom of the screen.
#shadow-exclude-reg = "x10+0+0";
#  Crop shadow of a window fully on a particular Xinerama screen to the screen.
#xinerama-shadow-crop = true;
#  Avoid drawing shadow on all shaped windows (see also: --detect-rounded-corners)
shadow-ignore-shaped = false;

#################################
#
#  Opacity
#
#################################

menu-opacity = 1;
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;
alpha-step = 0.06;

#  Dim inactive windows. (0.0 - 1.0)
#inactive-dim = 0.2;
#  Do not let dimness adjust based on window opacity.
#inactive-dim-fixed = true;
#  Blur background of semi-transparent / ARGB windows. Bad performance with X Render backend. GLX backend is preferred.
#blur-background = true;
#  Blur background of opaque windows with transparent frames as well. Implies --blur-background. Bad in performance, with driver-dependent behavior.
#blur-background-frame = true;
#  Specify the blur convolution kernel.
blur-kern = "3x3box"
#blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1"
#  Do not let blur radius adjust based on window opacity.
blur-background-fixed = false;
blur-background-exclude = [
    "window_type = 'dock'",
    "window_type = 'desktop'",
    "_GTK_FRAME_EXTENTS@:c"
];
#  Specify a list of opacity rules.
#opacity-rule = [ "80:class_g = 'URxvt'" ];

#################################
#
#  Fading
#
#################################

#  Fade windows during opacity changes.
fading = true;
#  The time between steps in a fade in milliseconds. (default 10).
fade-delta = 4;
#  Opacity change between steps while fading in. (default 0.028).
fade-in-step = 0.03;
#  Opacity change between steps while fading out. (default 0.03).
fade-out-step = 0.03;
#  Fade windows in/out when opening/closing
#no-fading-openclose = true;
#  Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
#no-fading-destroyed-argb = true;
#  Specify a list of conditions of windows that should not be faded.
fade-exclude = [ ];

#################################
#
#  Other
#
#################################

#  Try to detect WM windows and mark them as active.
mark-wmwin-focused = true;
#  Mark all non-WM but override-redirect windows active (e.g. menus).
mark-ovredir-focused = true;
#  Use EWMH _NET_WM_ACTIVE_WINDOW to determine which window is focused instead of using FocusIn/Out events.
#  Usually more reliable but depends on a EWMH-compliant WM. (openbox should be OK)
use-ewmh-active-win = true;
#  Detect rounded corners and treat them as rectangular when --shadow-ignore-shaped is on.
detect-rounded-corners = true;

#  Detect _NET_WM_OPACITY on client windows, useful for window managers not passing _NET_WM_OPACITY of client windows to frame windows.
#  This prevents opacity being ignored for some apps.
#  For example without this enabled my xfce4-notifyd is 100% opacity no matter what.
detect-client-opacity = true;

#  Specify refresh rate of the screen.
#  If not specified or 0, compton will try detecting this with X RandR extension.
refresh-rate = 0;

#  Specify a list of conditions of windows that should always be considered focused.
#focus-exclude = [ "class_g = 'Cairo-clock'" ];

#  Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
#  Known to cause flickering when redirecting/unredirecting windows.
#  paint-on-overlay may make the flickering less obvious.
unredir-if-possible = true;

#  Use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time.
detect-transient = true;
#  Use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time.
#  WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
detect-client-leader = true;

#################################
#
#  Window type settings
#
#################################

#wintypes:
#{
#  tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; };
#};


########################################################################
###  "advanced" machine specific options  ###

#  It is recommended to set these in /etc/bunsen/compton-startup
#  where they will be applied for all users, but can be set here.
########################################################################


#################################
#
#  Backend
#
#################################

#  Backend to use: "xrender", "glx" or "xr_glx_hybrid". xrender is the default one.
#  GLX backend is typically much faster but depends on a sane driver.

#backend = "glx";


#  Set VSync method. VSync methods currently available:
#  none: No VSync
#  drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some drivers.
#  opengl: Try to VSync with SGI_video_sync OpenGL extension. Only work on some drivers.
#  opengl-oml: Try to VSync with OML_sync_control OpenGL extension. Only work on some drivers.
#  opengl-swc: Try to VSync with SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the effect of --sw-opti unlike other methods. Experimental.
#  opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
#  (Note some VSync methods may not be enabled at compile time.)

#  --vsync opengl does NOT cause lag with Nvidia vsync disabled. I can turn
#  Nvidia vsync on after launching compton with --vsync opengl and I do not
#  get lag, but if I do it in the other order, I do get lag.
#  It still tears though in both situations.
#  I have seen various reports like the above.
#  Some nvidia drivers seem to create significant slowdowns.
#  Sometimes it might be useful to visit nvidia-settings if running
#  nvidia's proprietary drivers.

#vsync = "opengl";

#################################
#
#  GLX backend
#
#################################

#  GLX backend: Avoid using stencil buffer. This may not work with --blur-background. Tests show a 15% performance boost. Recommended.
#glx-no-stencil = true;

#  GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
#  My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
#  but a 20% increase when only 1/4 is.
#  My tests on nouveau show terrible slowdown.
#  Useful with --glx-swap-method, as well.
#glx-copy-from-front = false;

#  GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
#  My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
#  May break VSync and is not available on some drivers.
#  Overrides --glx-copy-from-front.
#glx-use-copysubbuffermesa = true;

#  GLX backend: Avoid rebinding pixmap on window damage.
#  Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
#  Recommended if it works.
#glx-no-rebind-pixmap = true; < -- This option causes lockups in Virtualbox.

#  GLX backend: GLX buffer swap method we assume: undefined/exchange/copy/3/4/5/6/buffer-age
#  Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
#  undefined is the slowest and the safest, and the default value.
#  copy is fastest, but may fail on some drivers,
#  2-6 are gradually slower but safer (6 is still faster than 0).
#  Usually, double buffer means 2, triple buffer means 3.
#  buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
#  Useless with --glx-use-copysubbuffermesa.
#  Partially breaks --resize-damage.
#  Defaults to undefined.
#  I am using double-buffering here. This is a typical scenario wherein the
#  screen is drawn into memory before being painted on the screen.
#  Better machines might want to use triple buffering if they have native
#  hardware support for it on their graphics card.
#
#glx-swap-method = "exchange";

#################################

#  Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
#  Reported to have no effect, though.
#dbe = false;

#  Painting on X Composite overlay window. Recommended.
#paint-on-overlay = true;

#  Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
#  This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
#  unless you wish to specify a lower refresh rate than the actual value.
#sw-opti = true;

Default /etc/bunsen/compton-startup:

#  custom startup options for compton

#  System administrators can add startup options for compton here.
#  Any words - space, tab, or newline separated - will be appended to
#  compton's command line when it is started by bl-compositor.
#  (Any content after a # symbol is treated as a comment and ignored.)
#
#  While any of the options in 'man compton' will be applied,
#  it is recommended to leave settings related to desktop appearance
#  (shadows, transparency, fading etc.) for individual users to set
#  in ~/.config/compton.conf, and to use this file only for
#  system-wide settings to optimize performance on this machine's hardware.
#
#  Settings here will take priority over users' ~/.config/compton.conf.
#
#  NB Do not use the -b (daemonize) option: it is buggy.
#  bl-compositor forks compton in a subshell anyway.
#
#  Examples:
#  vsync can be used to control screen tearing:
#  --backend glx will activate the OpenGL backend for superior performance,
#  search for VSYNC_METHOD in compton(1) for details of the various methods available.
#
#  These settings are reported to work well with Intel Haswell hardware:
#  --vsync opengl-mswc
#  --backend glx

#################################
#
#  Backend
#
#################################

#  Backend to use: "xrender", "glx" or "xr_glx_hybrid". xrender is the default one.
#  GLX backend is typically much faster but depends on a sane driver.

#--backend glx


#  Set VSync method. VSync methods currently available:
#  none: No VSync
#  drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some drivers.
#  opengl: Try to VSync with SGI_video_sync OpenGL extension. Only work on some drivers.
#  opengl-oml: Try to VSync with OML_sync_control OpenGL extension. Only work on some drivers.
#  opengl-swc: Try to VSync with SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the effect of --sw-opti unlike other methods. Experimental.
#  opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
#  (Note some VSync methods may not be enabled at compile time.)

#  --vsync opengl does NOT cause lag with Nvidia vsync disabled. I can turn
#  Nvidia vsync on after launching compton with --vsync opengl and I do not
#  get lag, but if I do it in the other order, I do get lag.
#  It still tears though in both situations.
#  I have seen various reports like the above.
#  Some nvidia drivers seem to create significant slowdowns.
#  Sometimes it might be useful to visit nvidia-settings if running
#  nvidia's proprietary drivers.

#--vsync opengl

#################################
#
#  GLX backend
#
#################################

#  GLX backend: Avoid using stencil buffer. This may not work with --blur-background. Tests show a 15% performance boost. Recommended.
#--glx-no-stencil

#  GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
#  My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
#  but a 20% increase when only 1/4 is.
#  My tests on nouveau show terrible slowdown.
#  Useful with --glx-swap-method, as well.
#--glx-copy-from-front

#  GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
#  My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
#  May break VSync and is not available on some drivers.
#  Overrides --glx-copy-from-front.
#--glx-use-copysubbuffermesa

#  GLX backend: Avoid rebinding pixmap on window damage.
#  Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
#  Recommended if it works. < -- This option causes lockups in Virtualbox.
#--glx-no-rebind-pixmap

#  GLX backend: GLX buffer swap method we assume: undefined/exchange/copy/3/4/5/6/buffer-age
#  Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
#  undefined is the slowest and the safest, and the default value.
#  copy is fastest, but may fail on some drivers,
#  2-6 are gradually slower but safer (6 is still faster than 0).
#  Usually, double buffer means 2, triple buffer means 3.
#  buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
#  Useless with --glx-use-copysubbuffermesa.
#  Partially breaks --resize-damage.
#  Defaults to undefined.
#  I am using double-buffering here. This is a typical scenario wherein the
#  screen is drawn into memory before being painted on the screen.
#  Better machines might want to use triple buffering if they have native
#  hardware support for it on their graphics card.
#
#--glx-swap-method exchange

#################################

#  Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
#  Reported to have no effect, though.
#--dbe

#  Painting on X Composite overlay window. Recommended.
#--paint-on-overlay

#  Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
#  This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
#  unless you wish to specify a lower refresh rate than the actual value.
#--sw-opti

tknomanzr · 2018-02-05 17:15:40

This looks pretty good. I will test it on my various BL installs (both bare-metal and virtual) later.

Head_on_a_Stick · 2018-02-05 20:00:11

^^ Fantastic work, that looks pretty much perfect to me.

johnraff wrote:

Which settings should go in the "user" section, and which in the "system" section

Put everything in the user-level file and then just have a commented-out copy of that as the system-level file (with the explanatory header section added to the top), that way it will be obvious what the defaults are when making system-level changes.

johnraff · 2018-02-06 02:50:20

The synatx is slightly different in the two files of course.

Whatever we set as default in the user file can be changed at will at any time, so I'm not sure how useful it would be putting a copy of the upper settings in the system file. ATM it's just the "advanced" settings, starting with "backend".

Head_on_a_Stick · 2018-02-06 08:23:29

johnraff wrote:

The synatx is slightly different in the two files of course

Ah yes, of course.

The files look fine to me as is.

Last edited by Head_on_a_Stick (2018-02-06 08:28:40)

johnraff · 2018-02-07 03:35:10

Oh yes, one final nit to pick:

The menu has Preferences > Compositor > Edit Compositing Settings to edit ~/.config/compton.conf
I guess we should have a similar entry for /etc/bunsen/compton-startup.
Strictly speaking, because it's a system file needing privileges to edit, it should be under the System submenu.
However, I'm thinking separating the two files like that might cause more confusion than it's worth, so maybe make an exception here and put "Edit Compositing System Settings" in the same Compositor submenu under Preferences?

Snippet of bl-compositor:

    # Output Openbox menu
    menuStart
    if ! pidof compton > /dev/null; then
        menuItem 'Enable Compositing' "$0 --start"
    else
        menuItem 'Restart Compositing' "$0 --restart"
        menuItem 'Disable Compositing' "$0 --stop"
        menuSeparator
    fi
    menuItem 'Edit Compositing Settings' "$0 --edit"
    if [[ -f "$sys_conf" ]] && hash bl-text-editor; then
        menuItem 'Edit Compositing system settings' "pkexec bl-text-editor $sys_conf"
    fi
    menuEnd

($sys_conf is /etc/bunsen/compton-startup)

Head_on_a_Stick · 2018-02-07 07:49:29

johnraff wrote:

put "Edit Compositing System Settings" in the same Compositor submenu under Preferences?

Yes, that seems tidier to me.

tknomanzr · 2018-02-07 17:15:35

Keep in mind that one will require root access and one will not. I would likely append (root) to the system-wide label.

johnraff · 2018-02-08 02:57:35

tknomanzr wrote:

append (root) to the system-wide label

OK

hhh · 2018-03-24 20:17:38

Looks great here, the fade-in/out is perfect. Sleek, not slow.

#41 2018-02-02 07:56:26

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#42 2018-02-05 07:53:20

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#43 2018-02-05 17:15:40

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#44 2018-02-05 20:00:11

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#45 2018-02-06 02:50:20

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#46 2018-02-06 08:23:29

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#47 2018-02-07 03:35:10

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#48 2018-02-07 07:49:29

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#49 2018-02-07 17:15:35

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#50 2018-02-08 02:57:35

Re: [DONE][helium-dev] Compton startup options and bl-compositor

#51 2018-03-24 20:17:38

Re: [DONE][helium-dev] Compton startup options and bl-compositor

Board footer