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

johnraff · 2017-09-17 04:28:32

Revisiting this old topic.
Reference:
https://forums.bunsenlabs.org/viewtopic … 869#p52869
https://forums.bunsenlabs.org/viewtopic.php?id=3140
https://github.com/BunsenLabs/bunsen-pi … t-22476086
https://github.com/chjj/compton/wiki/vsync-guide

Currently bl-compositor sets the compton startup command EXECXCOMP like this:

EXECXCOMP='compton -b'
if glxinfo | egrep -iq 'direct rendering: yes'; then
    EXECXCOMP+=' --vsync opengl'
fi

Now, the -b option (daemonize) has been found to be buggy in certain cases (glx) so we've already agreed to drop it and fork off the process instead: 'EXECXCOMP &'
(This requires a bit of sleep before the next command to make sure compton is up and running.)

One user at least had issues with the '--vsync opengl' option, while others got better results using '--backend glx' (with or without vsync). What seems clear is:
1) Users have widely different optimum compton startup settings, depending on their hardware.
2) At the moment, to tweak those settings means editing /usr/bin/bl-compositor as root, and their changes will be overwritten on the next upgrade of bunsen-pipemenus.

User @kafran suggested sending the startup options to bl-compositor as arguments, from ~/.conf/openbox/autostart. I was also thinking of adding a commented-out "cookie" to ~/.config/compton.conf that bl-compositor could read (allowing everything to be set in one file) and got some prototype code working... but, in fact, these settings can be put in compton.conf directly, can't they?

Does anyone know:

Exactly what compton command options listed in 'man compton' can be put in compton.conf instead? (The manual says "Most commandline switches each could be replaced with an option in configuration file, thus documented above." Although I couldn't find anything useful "above".)
If there are likely to be any users whose experience will be significantly worse if compton is launched as plain 'compton', ie without '--vsync opengl'?

I'm guessing that, for example, the -b option can't go in compton.conf, but I don't know about the other one-letter options. OTOH, it's possible to put in:

vsync = "opengl";
backend = "glx";

and compton does not complain (and presumably enacts the options).

So, suggestion: drop all compton options from bl-compositor, and leave it to users to put them in compton.conf?

Any hidden snags?

Last edited by johnraff (2018-02-08 06:32:16)

Head_on_a_Stick · 2017-09-17 09:54:15

johnraff wrote:

suggestion: drop all compton options from bl-compositor, and leave it to users to put them in compton.conf?

Yes, much better idea, it's seems silly to split the configuration and we already use compton.conf

We could either provide a commented-out list of the options or simply refer the user to the VSYNC_METHOD explanation provided for the --vsync option in compton(1).

I don't fully understand that text myself so it would be pure hubris for me to presume to offer advice to others on the matter 8)

EDIT: from personal experience, compton works best on my Intel Haswell laptop with opengl-mswc, especially with MESA v17 but even then it's not as good as the Intel DDX driver's inbuilt TearFree option so I don't even use it.

Last edited by Head_on_a_Stick (2017-09-17 10:07:38)

johnraff · 2017-09-18 01:39:23

(Personal experience: with my old Nvidia graphics card, just plain 'compton' seems to work as well as anything. ATM I'm using --vsync opengl though. )

So, remaining question: are all the options that users might want to set available in compton.conf?
( eg the single-letter options like -r )

Sub-questions:
1) Are there likely to be any users who would suffer badly enough from a default compton with no options at all that they'd be put off the distro altogether?
2) Any suggestions for testbenching compton, and algorithms for finding the best options for particular hardware - for devs and users alike?
2a) Any way to get verbose output from compton, to see if an option has even been recognized?

---
If it should turn out that some options are only available from the command line, I have already put together a usable mechanism for bl-compositor to read "hidden" options from comments in compton.conf and use them to launch compton, like:

# compton configuration file for BunsenLabs Helium
#
# Add custom startup options here
# examples:
# --vsync opengl
# --backend glx
# Everything after the = will be added to compton's command line.
# KEEP THE LINE COMMENTED
# BL_cookie: compton_start_options =

...rest of file

tknomanzr · 2017-09-18 03:06:59

Compton Wiki

I think it is more a situation where you start with safe and sane defaults, then tweak from there, truthfully. There is also some benchmarking guidelines in there. This is just one of those things where performance tuning is really hardware dependent.

Bearded_Blunder · 2017-09-18 05:48:49

Just guess at something "Average" those with really low-spec hardware (ME) will apt-get remove compton anyhow... those with reasonable hardware will tweak settings

Head_on_a_Stick · 2017-09-18 06:30:06

johnraff wrote:

are all the options that users might want to set available in compton.conf?

compton(1) wrote:

Most commandline switches each could be replaced with an option in configuration file

https://manpages.debian.org/stretch/com … TION_FILES

Try

pager /usr/share/doc/compton/examples/compton.sample.conf

johnraff wrote:

Are there likely to be any users who would suffer badly enough from a default compton with no options at all that they'd be put off the distro altogether?

No, the flags under discussion just control vsync and it's better to do without that if at all possible.

johnraff wrote:

Any suggestions for testbenching compton, and algorithms for finding the best options for particular hardware - for devs and users alike?

YouTube videos, perhaps?

I find the tearing particularly noticeable when scrolling up and down the forums with the light Hydrogen theme, the banding it produces is intolerable for my eyes

johnraff · 2017-09-18 08:35:49

tknomanzr wrote:

start with safe and sane defaults

Bearded_Blunder wrote:

something "Average"

This is what we're trying to establish here. Right now, the setting we inherited from #! is to do that glxinfo test in the OP and, if it passes, to add '--vsync opengl' to the startup command. I'm asking if it will be OK to remove that and just use a plain 'compton' by default until the user adds things to compton.conf.

It's important because it would be quite unusual for an app to allow something in the config file to overrule a command line option, so once '--vsync opengl' was added to the command I don't think the user could easily remove it except by editing bl-compositor (as root). Life will be simpler if there are no options on the command line. (Though that "hidden" option thing I referred to above would get round that, if it turned out to be the only way.

The other question is if there are any command-line options that cannot be set in compton.conf.

Head_on_a_Stick wrote:

compton(1) wrote:
Most commandline switches each could be replaced with an option in configuration file

Yes I quoted that same line in the OP , but most != all, and the manual does not explain the syntax change needed.

However:

Try

pager /usr/share/doc/compton/examples/compton.sample.conf

Thanks, I did overlook that, and it contains a couple of hints like:

shadow-offset-x = -7; # not in the manual, but presumably the equivalent of -l -7
shadow-radius = 7; # possibly -r, described as "The blur radius for shadows"?
fade-in-step = 0.03; # presumably -I 0.03
no-dock-shadow = true; # -C
vsync = "none"; # interesting?

So 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 · 2017-09-18 18:16:18

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

I would suggest the following changes:

$ diff compton.conf.orig compton.conf.new                                                  
--- compton.conf.orig
+++ compton.conf.new
@@ -34,7 +34,6 @@
 detect-rounded-corners = true;
 detect-client-opacity = true;
 #refresh-rate = 0;
-#vsync = "none";
 dbe = false;
 paint-on-overlay = false;
 sw-opti = false;
@@ -44,3 +43,13 @@
 #{
 #  tooltip = { fade = true; shadow = false; opacity = 0.85; };
 #};
+
+# 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";
+
+# Any desired command flags not covered by this file can be applied by copying
+# /usr/bin/bl-compositor to ~/bin and adding them to the EXECXCOMP variable.

$ diff bl-compositor.orig bl-compositor.new                                       
--- bl-compositor.orig
+++ bl-compositor.new
@@ -56,11 +56,8 @@
 
 declareDependencies compton
 
-# ------------- Set compton command options -----------------------------------
-EXECXCOMP='compton -b'
-if glxinfo | egrep -iq 'direct rendering: yes'; then
-    EXECXCOMP+=' --vsync opengl'
-fi
+# ------------- Add compton command options before ampersand ------------------
+EXECXCOMP='compton &'
 
 forcekill_compton() {
     killall -q compton

Last edited by Head_on_a_Stick (2017-09-18 19:12:02)

tknomanzr · 2017-09-18 18:45:30

This is the man page
https://github.com/chjj/compton/blob/ma … 1.asciidoc

Then this is the config file I use as my reference:
http://duncanlock.net/blog/2013/06/07/h … g-in-xfce/

I think you should be able to see how things are mapped from these two documents. I tinkered around with compton a lot early on but truthfully, as long as it is doing its job I don't mess with it that much these days. In fact, opengl on this system is currently broken (I need to reinstall the driver. Long story), but compton is still running. On low end machines though, I could see going after the hardware support for sure. I just felt like, from my early experiences that tuning compton is something that is individual to each machine as much as it is to user preference.

Information is sparse on the subject. It might be useful to start documenting configurations on particular architectures. For me, tuning was a lot of guess-work, with occasional crashes and I finally got the desktop where I wanted, then I get on the laptop with an Intel gpu and it needs tweaking. The desktop settings are too aggressive with it and lock it up. I wish I had a clearer map to offer you but the above two documents were my reference for the testing.

Last edited by tknomanzr (2017-09-18 18:46:05)

Head_on_a_Stick · 2017-09-18 19:07:22

tknomanzr wrote:

Then this is the config file I use as my reference:
http://duncanlock.net/blog/2013/06/07/h … g-in-xfce/

That really is most excellent

We could perhaps use that as a template for compton.conf with our own settings added in.

tknomanzr · 2017-09-18 21:54:31

Yeah. I like how he documented each option. This is a good start toward both establishing a sane default and encouraging people to tweak their config. As for the sane default, I am pondering how useful a setup script would be to detect specific hardware and setup the Compton config for that hardware. At the very least, some opengl detection and an offer to turn it on in Compton might be useful.

johnraff · 2017-09-19 03:34:00

tknomanzr wrote:

tuning compton is something that is individual to each machine as much as it is to user preference.

I think we're all agreed on that.

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

Why should we bother doing anything? Maybe our users would be quite capable of configuring openbox and tint2, should they want to...
But here

tknomanzr wrote:

Information is sparse on the subject.

and really that information should be in man compton IMO. Some of those conffile<>manpage maps are non-intuitive. Why should people be expected to re-invent that wheel every time someone installs BL on their machine? For the good of their souls or something?

No-one is required to bother with anything they don't feel like doing, but lack of documentation is always the weakest point with free software, because it's less fun than making something new. I think that a list of cli options vs conffile entries might save some people some time. Isn't that what we're doing here, basically?

Head_on_a_Stick wrote:

tknomanzr wrote:
Then this is the config file I use as my reference:
http://duncanlock.net/blog/2013/06/07/h … g-in-xfce/
That really is most excellent
We could perhaps use that as a template for compton.conf with our own settings added in.

Yes, let's do that. Thanks @tknomanzr!

tknomanzr wrote:

It might be useful to start documenting configurations on particular architectures. For me, tuning was a lot of guess-work, with occasional crashes and I finally got the desktop where I wanted, then I get on the laptop with an Intel gpu and it needs tweaking.

Would it be worthwhile opening a new thread "Post your compton hardware settings" for people to post what hardware they're using and what compton settings they ended up using after going through all that guesswork, testing and crashing? Might save those who come after some time.

tknomanzr wrote:

As for the sane default, I am pondering how useful a setup script would be to detect specific hardware and setup the Compton config for that hardware. At the very least, some opengl detection and an offer to turn it on in Compton might be useful.

This kind of auto-detection is what I hoped we could move away from to be honest. bl-welcome running some tests and putting entries in the user's compton.conf might be possible, but it's likely to be complicated. If we can get away with plain

compton

as the default command, that would really save everyone a lot of "bother".

Of course, really, hardware is something system-wide, so while fading, shadows etc are quite appropriate for user config files, the low-level stuff like vsync and glx ought to be set at the system level, if there was some mechanism for doing that.

Head_on_a_Stick · 2017-09-19 06:03:48

johnraff wrote:

Why should we bother doing anything?

There is a fine line between guidance and spoonfeeding and I think researching lists of configuration file options most definitely falls the wrong side of that line.

My suggested changes allows the user to add any flags to ~/bin/bl-compositor if needed thus making said research entirely unnecessary.

johnraff wrote:

low-level stuff like vsync and glx ought to be set at the system level, if there was some mechanism for doing that.

As I have already mentioned, the vsync methods employed by compton should only be used as a last resort, the problematic Intel cards that suffer worst with screen tearing have a "TearFree" option in xserver-xorg-video-intel that works *much* better than compton and should always be preferred. NVIDIA cards have a "ForceFullCompositionPipeline" option that has the same effect, not sure about AMD (our laptop doesn't suffer from tearing so perhaps it isn't a problem with that hardware).

johnraff · 2017-09-19 07:25:36

@HoaS I appreciate your POV, and this is probably a difference of degree rather than a fundamental clash of philosophies. Anyway, in reverse order:

Head_on_a_Stick wrote:

johnraff wrote:
low-level stuff like vsync and glx ought to be set at the system level, if there was some mechanism for doing that.
As I have already mentioned, the vsync methods employed by compton should only be used as a last resort...

Sorry, I think you might have misunderstood my purpose here. I'm not advocating setting vsync or anything else by default. (I have no idea what they do TBH.) What I was saying was that if vsync, glx or any other settings that relate to the machine's hardware - not to the way the user's desktop was displayed - were to be set for a certain machine, it would be nice if there was some mechanism that the sysadmin could use to set them on a system-wide level.
Maybe we could add support in bl-compositor for an optional file under /etc that sysadmins could use to set custom startup options?

Head_on_a_Stick wrote:

My suggested changes allows the user to add any flags to ~/bin/bl-compositor if needed thus making said research entirely unnecessary.

I think asking the user to copy a system file to ~/bin and edit it is a messy way of handling things, only for last resort cases. (/usr/bin/bl-compositor will be overwritten by upgrades of course, while the user's copied file will miss out on any improvements.)

BTW outputs of diff might be easily read by software and programmers, but I find them as hard on my eyes as those scrolling effects with Light Hydrogen are on yours. Yes they're decipherable, but it's not pleasant. For little things like this would a code fragment be acceptable instead?

Head_on_a_Stick wrote:

johnraff wrote:
Why should we bother doing anything?
There is a fine line between guidance and spoonfeeding and I think researching lists of configuration file options most definitely falls the wrong side of that line.

I'm afraid we continue to differ on this one. I don't think doing that research once so that every user will be spared having to reinvent that wheel would constitute spoon-feeding. If we had a definitive list up it might be a useful resource for others too.

But enabling sysadmins to add custom compton startup options would bypass that whole discussion. By the end of this post I'm coming round more and more to having bl-compositor look for a file under /etc and use that to add options, if the file exists. Then it would be up to the sysadmin to tweak Nvidia, tweak their whatever driver, and perhaps tweak compton.

EDIT: This (in bl-compositor) seems to work:

sys_conf='/etc/compton-bl-startup'
EXECXCOMP='compton'

# Look for system startup file
[[ -r $sys_conf ]] && {
    options=()
    while read -r line
    do
        options+=(${line%%\#*})
    done < "$sys_conf"

    for i in "${options[@]}"
    do
        EXECXCOMP+=" $i"
    done
}

While compton-bl-startup contains the wanted options, space or line separated, comments ignored. We could supply such a file - empty except for useful comments such as what HoaS posted earlier - or leave it up to sysadmins to make one if they want.

Last edited by johnraff (2017-09-23 04:26:38)

Head_on_a_Stick · 2017-09-19 17:40:27

johnraff wrote:

outputs of diff might be easily read by software and programmers, but I find them as hard on my eyes as those scrolling effects with Light Hydrogen are on yours. Yes they're decipherable, but it's not pleasant. For little things like this would a code fragment be acceptable instead?

Yes of course, sorry.

having bl-compositor look for a file under /etc and use that to add options, if the file exists

Sounds good to me

tknomanzr · 2017-09-19 18:10:44

^ This sounds good. I was also able to find a small amount of benchmarking information in phoronix.

I was also able to find one of my old compton.conf files for my desktop, back when we were transitioning from #! to Bunsenlabs. Unfortunately, I did not document it well, so am not sure why some things are commented out.

I am willing to begin documenting things on whatever hardware I can scrape up (A desktop running Nvidia GTX 980, the Surface Pro IV running in a virtual machine, a low-end laptop, possibly another as well). In addition to annotating options, I could run Phoronix benchmarks against them and hopefully get builds tuned for specific gpu sets. I've even got a AMD R9 sitting in my girlfriend's case. I could setup a BL instance on it and get it tuned as well so I can guarantee Nvidia, AMD, older Intel, and I think this Surface Pro IV has Intel Haswell graphics stack. This stuff would be more useful as a forum topic than anything but would also serve to document the features in Compton.

Bearded_Blunder · 2017-09-19 20:43:25

I'm liking where this seems to be heading, systemwide settings under /etc in a well commented file.
If there's a forum thread for tweaks, examples for particular brands and classes of hardware, then providing the url as part of the comments also sounds good.

To be fair, I'm not so far a tweaker of compton, machines I throw bl at tend to be so old that if i can stand the result of killall compton I tend to apt-get remove it, on newer systems I've never yet felt the need to tweak it, maybe I have a high tolerance for iffy displays. Else I've just been lucky.

johnraff · 2017-09-19 23:53:38

tknomanzr wrote:

I am willing to begin documenting things on whatever hardware I can scrape up...
This stuff would be more useful as a forum topic than anything but would also serve to document the features in Compton.

Great!

I'm away a couple of days, but if HoaS doesn't mind too much, I might publish somewhere a list of compton's undocumented long options - at least what documented short options they correspond to.

This is the kind of case where a wiki would be useful, but of course that issue has been thoroughly discussed and dismissed, for good reasons.

Head_on_a_Stick · 2017-09-20 06:23:43

johnraff wrote:

if HoaS doesn't mind too much, I might publish somewhere a list of compton's undocumented long options

Please don't let my emotional state dictate your chosen strategies, I am somewhat unbalanced at the best of times

I would however question whether such activities would constitute an effective use of your time given that:

johnraff wrote:

enabling sysadmins to add custom compton startup options would bypass that whole discussion

If we are going to add a custom configuration file to /etc then surely such research would be entirely superfluous?

But you are, of course, free to spend your time however you see fit.

johnraff · 2017-09-23 02:51:15

Head_on_a_Stick wrote:

I would however question whether such activities would constitute an effective use of your time given that:
...If we are going to add a custom configuration file to /etc then surely such research would be entirely superfluous?

But you are, of course, free to spend your time however you see fit.

Both true.

And also:

Head_on_a_Stick wrote:

if you think that some of the documentation does not explain things well enough for you then you should do some research and then extend the documentation so that it satisfies your needs, this effort will benefit the entire community.

And the time spent would still be small compared with what goes into posting on this forum...

EDIT
BTW a few posts back:

Head_on_a_Stick wrote:

(in compton.conf) ...provide a commented-out list of the options...

This would of course have required knowing what the long-form options were.

Last edited by johnraff (2017-09-23 04:36:35)

#1 2017-09-17 04:28:32

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

#2 2017-09-17 09:54:15

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

#3 2017-09-18 01:39:23

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

#4 2017-09-18 03:06:59

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

#5 2017-09-18 05:48:49

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

#6 2017-09-18 06:30:06

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

#7 2017-09-18 08:35:49

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

#8 2017-09-18 18:16:18

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

#9 2017-09-18 18:45:30

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

#10 2017-09-18 19:07:22

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

#11 2017-09-18 21:54:31

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

#12 2017-09-19 03:34:00

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

#13 2017-09-19 06:03:48

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

#14 2017-09-19 07:25:36

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

#15 2017-09-19 17:40:27

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

#16 2017-09-19 18:10:44

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

#17 2017-09-19 20:43:25

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

#18 2017-09-19 23:53:38

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

#19 2017-09-20 06:23:43

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

#20 2017-09-23 02:51:15

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

Board footer