-b flag in openbox/autostart breaks --shadow-exclude

[zakkak]

The following line causes conky and docky to have shadows dispite the shadow-exclude arguments compton -f -D3 -cC -m0.8 -z --shadow-exclude 'n:a:Conky' --shadow-exclude 'n:e:Docky' -b replacing it with compton -f -D3 -cC -m0.8 -z --shadow-exclude 'n:a:Conky' --shadow-exclude 'n:e:Docky' & fixes the problem.

I am not sure though if this is really a problem of the daemon implementation or something else.

[richardgv]

1. Really, -b has nothing to do with --shadow-exclude. This sounds like a timing-related issue. Another possibility is the parameters are not passed to compton correctly. I could not reproduce the problem, with conky or docky. And in general, dealing with a problem that I could not reproduce is going to be a lengthy and painful process.
2. Please make sure you are using the latest version from master or richardgv-dev branch.
3. Does it always happen when you use -b, or just sometimes? "Sometimes happen" is a sign of a timing-related issue.
4. Compton will not quit even if it discovers an error in the value of --shadow-exclude (but this behavior is to change). Depending on how you start compton, you may or may not be able to see the warning message it prints out. And using -b will also hide most warning messages from you. Please check if the parameters are passed correctly to compton, if, for example, compton is not started from a shell or a shell script.
5. Does starting compton with -b manually (in a terminal) works?
6. Do you have a configuration file that could interfere compton's operations? You could try compton --config /dev/null -cC --shadow-exclude 'n:ai:docky'.
7. Conky is known to work badly with pcmanfm desktop painting. ( https://github.com/chjj/compton/issues/63#issuecomment-10541587 ) How did you manage to run it correctly under LXDE?
8. -C should be enough to disable shadow for Docky window (docky-2.1.4 at least sets the window type correctly). So if there's a problem in compton, it might be in client window detection.
9. As compton -b disables all output, thus hides all debug messages, it would be tricky to debug in such a case. I guess you would have to use gdb.

By the way, compton and xcompmgr seemingly misbehaves when editing Docky settings. Will look into that later.

Update: The problem I met when editing Docky settings is probably caused by fvwm. Never mind.

[zakkak]

1. Yes it makes sense :)
2. Yes I am using the latest version from master
3. Always
4. It appears it starts fine
5. Yes
6. No there is no configuration file
7. I am not using LXDE this is a pure openbox session.
8. I don't know about this i replaces docky with cairo-dock
9. I think you should print errors to some log file when running in -b :)

My current setup is using cairo-dock instead of docky which seams to be working fine. Conky also works fine (but even with the & it sometimes gets shadows). This shows that this is a timing problem but i can't understand why timing should matter. If start Conky and compton from a terminal emulator it always works no matter which one i start first.

Thank you very much for your reply

[richardgv]

Well, now let's do some painful remote debugging...

1. Make sure you have compton built with debugging symbols, and you have restarted compton after recompiling it.

   make clean; CFLAGS='-ggdb' make
   killall compton
   ./compton

2. When compton is giving shadow to a shadow-excluded window, please figure out the window ID of the frame window of the problematic window, by running xwininfo -frame and select it. Write the window ID somewhere. For example, if the output is this, the frame window ID is 0xc000c8:

   xwininfo: Please select the window about which you
            would like information by clicking the
            mouse in that window.
   
   xwininfo: Window id: 0xc000c8 (has no name)
   
    Absolute upper-left X:  0
    Absolute upper-left Y:  55
    Relative upper-left X:  0
    Relative upper-left Y:  55

3. Figure out the client window ID, too, by running xwininfo and select the window. For windows with no frames, this is probably the same as the frame window ID. In my case, it's 0x800001.

   xwininfo: Please select the window about which you
            would like information by clicking the
            mouse in that window.
   
   xwininfo: Window id: 0x800001 "Conky (home)"
   
    Absolute upper-left X:  0
    Absolute upper-left Y:  55
    Relative upper-left X:  0
    Relative upper-left Y:  0

4. Use gdb to attach to compton:

   gdb path/to/compton $(pgrep compton)

   At this point, you have to operate in a virtual console. Debugging compton will make the screen freeze.

5. Look up the window by its frame window ID:

   (gdb) p find_win(ps_g, 0xc000c8)
   $1 = (win *) 0xd7aa80

6. If found, check if its recorded name, class, and client window ID are correct:

   (gdb) p find_win(ps_g, 0xc000c8)->name
   $2 = 0xd7aa40 "Conky (home)"
   (gdb) p find_win(ps_g, 0xc000c8)->class_instance 
   $3 = 0xd79d10 "Conky"
   (gdb) p find_win(ps_g, 0xc000c8)->class_general 
   $4 = 0xd7adf0 "Conky"
   (gdb) p/x find_win(ps_g, 0xc000c8)->client_win 
   $5 = 0x800001

7. If any of those values are incorrect, it means compton failed to get the values somehow; if all those are correct, the problem is in window matching.

I think you should print errors to some log file when running in -b :)

It's pretty rare that a problem only happens with -b, so it doesn't really worth the trouble, I guess?

This shows that this is a timing problem but i can't understand why timing should matter. If start Conky and compton from a terminal emulator it always works no matter which one i start first.

This is a nanosecond/microsecond level timing issue. You are extremely lucky (or unlucky) to spot such a problem.

[zakkak]

My results are NULL (0x0) for name, class_instance and class_general. Only the client_win field is right.

This is a nanosecond/microsecond level timing issue. You are extremely lucky (or unlucky) to spot such a problem.

So you suspect a race between the two programs. I guess i am really lucky to see this behavior then :). If this is the case could we daemonize compton only after the appropriate initialization is done?

[richardgv]

My results are NULL (0x0) for name, class_instance and class_general. Only the client_win field is right.

Ah, looks like for yet another time I've made a miserable mistake... Please pull from richardgv-dev branch, apply the patch below, and tell us if the problem is still there:

(Yeah, this patch contains a lot of other weird stuffs...)

Update: The patch has been merged into richardgv-dev branch, please clone from the branch and test.

So you suspect a race between the two programs. I guess i am really lucky to see this behavior then :). If this is the case could we daemonize compton only after the appropriate initialization is done?

Well, this is not related to when we daemonize, this is related to a few hundred microseconds daemonization uses. :-) A few hundred microseconds that may have triggered the issue.

[zakkak]

If the following is the right process to build from richardgv-dev then the patch does not work for me

git clone https://github.com/chjj/compton
cd compton/
git checkout origin/richardgv-dev 
git pull origin richardgv-dev
make

[richardgv]

1. If you are using the latest version from richardgv-dev branch, when you run compton -h you will see this:

   compton (git-7188054-2013-01-09)
   usage: compton [options]
   ...

   And just a double check: you did restart X after compton got updated, right?

2. Is the frame window ID the same as client_win, when the bug appears, or is different?
3. Is ps_g->o.track_wdata true when the problem appears?

[richardgv]

Oh, wait, wait, in addition to the three points above:

1. Please try executing xprop WM_STATE on your problematic window when the issue appears, and show me the output.

2. Please try executing win_get_name() on the problematic window in gdb, and check its ->name afterward, like:

   (gdb) p win_get_name(ps_g, find_win(ps_g, 0x4000c8))
   $1 = -1
   (gdb) p find_win(ps_g, 0x4000c8)->name
   $2 = 0x0

[zakkak]

1. Confirmed
2. Yes
3. Yes

Please try executing xprop WM_STATE on your problematic window when the issue appears, and show me the output.

WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0

Please try executing win_get_name() on the problematic window in gdb, and check its ->name afterward, like:

(gdb) p win_get_name(ps_g, find_win(ps_g, 0xa00101))
$1 = 0
(gdb) p find_win(ps_g, 0xa00101)->name
$2 = 0x21b6a60 "Conky (hostname)"

[richardgv]

1. You are answering with too few words that I'm getting uncertain about your meaning, zakkak. Seemingly useless words may provide valuable clues. Please don't be so extreme.
2. win_get_name() returns 0 means compton does know about the name before the win_get_name() call you made, and the name did not change. This conflicts with your previous gdb result, in which compton does not know the window name. Please make sure all your tests are done when the problem is happening, as I requested.

3. I've added --logpath to compton, on richardgv-dev branch, to redirect messages to a file when -b is used. Please pull from richardgv-dev, make sure your version is git-57c5854-2013-01-11, then compile compton with -DDEBUG_CLIENTWIN -DDEBUG_WINDATA:

   make clean; CFLAGS='-ggdb -DDEBUG_CLIENTWIN -DDEBUG_WINDATA' make

   After that, add -b --logpath /tmp/compton-log.log to the commandline arguments, run compton, reproduce the issue, and show me /tmp/compton-log.log and the messages from stdout (messages printed during initialization are still sent to stdout). compton appends to the log file instead of overwriting it, so please remove the file before you start compton.

[richardgv]

Okay, I did some extra changes in git-2165c42-2013-01-12 on richardgv-dev branch. Let's see if I'm lucky enough to fix this annoying issue. If the new version still does not work for you, please follow my suggestions in the last reply.

Update: Now git-e60fe72-2013-01-13 is the latest version.

[zakkak]

Seems to work great :)

Thanks a lot