awesome.restart kills _NET_WM_CM property

[timroes]

It seems, that restarting awesome via awesome.restart() resets a _NET_WM_CM property a compositor have set beforehand.

If I start compton via my config and with the flag -b it runs as a daemon in background; awesome.composite_manager_running will return true from now on.

If you now restart awesome compton keeps running (and working), but awesome.composite_manager_running will return false after the restart.

A simple workaround is to kill compton and start it every time awesome comes up, but it would be nicer if I could just start it once and it will keep the _NET_WM_CM property over an awesome restart.

I am not much into xcb so I don't know if this behavior is intentional or is a side effect of any of the xcb methods during awesome_atexit or the startup phase. Do you have any ideas about that?

[blueyed]

Reminds me of #181 (but not really related).

It needs maybe the same handling as in 4aa6c33 - remembering this across restarts.

[timroes]

Just out of curiosity what exactly loses the variable? Is the storage of that kind of variable in X linked to the running WM or is it a side effect of one of the methods used during cleanup?

[blueyed]

Probably the former, but I do not know.

[blueyed]

Reading http://standards.freedesktop.org/wm-spec/1.4/ar01s08.html reminds me again of #181..

[psychon]

I don't really agree with your theories, sorry.

Here is mine:
@timroes run_once doesn't really work and when he restarts awesome, the new awesome starts a new compton instance. Looking at compton's source code, I think that it registers itself for _NET_CM_Sn before checking if another composite manager is already running. So when a second compton starts, it gets the _NET_CM_Sn selection, then gets an error from the X11 server telling it that it cannot become the composite manager, then it exits ( https://github.com/chjj/compton/blob/master/src/compton.c#L3321-L3325 ). This will destroy the window used for registering the selection and thus the _NET_CM_Sn selection becomes unowned.

@timroes Could you start compton from a terminal while awesome is running and another compton is already running, tell me which error message it prints and if this then causes awesome.composite_manager_running to become false?

If this really explains the problem, then compton should follow ICCCM with its selection:

• It should not just blindly acquire the selection, but check if the selection is already owned first (and then exit with an error, if needed)
• When it loses the selection, it should exit according to ICCCM

As @blueyed already found in EWMH:

For each screen they manage, compositing manager MUST acquire ownership of a selection named _NET_WM_CM_Sn, where n is the screen number. Compositing managers MUST comply with the conventions for "Manager Selections" described in section 2.8 of the [ICCCM].

[timroes]

@psychon You were right about your assumption. compton exits with "Another composite manager is already running" and awesome.composite_manager_running will switch to you false from that on.

So compton should fix it, but looking at their "most recent" release history I will likely not rely on a new release there and since I am anyway refactoring large parts of my config I was anyway going to write a proper functioning run_once method.

[blueyed]

@timroes

proper functioning run_once method

Why not just use ~/.xsessionrc for this?
I have been using a run_once method myself, but migrated in the meantime.

[psychon]

Was this reported to compton? If yes, where exactly? If no, I will do so.

[timroes]

@psychon Haven't reported it. Please feel free to do so (you could anyway explain it better).

[psychon]

Fix available at chjj/compton#320.