Incorrect handling of _NET_WM_CM_Sn selection

[psychon]

Originally reported at https://github.com/awesomeWM/awesome/issues/419

The awesome window manager switches between fake transparency (drawing the wallpaper as the background of windows) and real transparency (translucent pixels with an alpha component != 1) based on the _NET_WM_CM_Sn selection (= "Is a compositing manager running?").

When running compton and then starting a second compton in a termal, this second compton will error out with Another composite manager is already running and the _NET_WM_CM_Sn selection becomes unowned.

This happens because during startup, compton acquires this selection before it tries to XCompositeRedirectSubwindows. When the error about this request comes in, compton just exits ( https://github.com/chjj/compton/blob/master/src/compton.c#L3324-L3328 ). The X11 server will destroy all of compton's window and the selection becomes unowned.

To fix this properly, EWMH and ICCCM should be followed. EWMH specifies that Compositing managers MUST comply with the conventions for "Manager Selections" described in section 2.8 of the [ICCCM]. For handling selections, ICCCM specifies:

• Before acquiring a selection, a selection manager should check if the selection is already owned and only "steal" the selection if the user told it to do so (e.g. some WMs have a --replace command line option). (Note that this also means that compton should never get an error from XCompositeRedirectSubwindows, because any other compositing manager should also own the selection. So I think that error message should be changed indicating that something doesn't follow the spec.)
• When losing a selection, the selection manager should "stop". (I guess this means SelectionClear and SelectionNotify events, but I'm not totally sure; in the case of this bug this would have made it more evident that something "fishy" is going on)

I think that compton doesn't do any of this. Note that I only wrote this from memory and I surely missed something. Better check ICCCM §2.8.

[richardgv]

Thanks for the report and extensive explanation! I could reproduce the issue, and the logic of registration, inherited from xcompmgr at 2007. is indeed not following the standard. Since the issue appears only in very specific cases (not many people start compton twice then launch a program that uses X selection to determine if a compositor is running, isn't it?), I will start working on it after I take care of other, more severe bugs.