Incompatibility with xcompmgr -f

[divVerent]

xsecurelock is currently not compatible with xcompmgr -f; with this combination, the screen is not blanked while locked because both xcompmgr and xsecurelock are drawing to the same destination.

Currently no fix is known; possible workarounds seem to be:

• compton -f (but without -i option, apparently)
• compton -f --backend glx --paint-on-overlay (allows -i option)
• passing XSECURELOCK_NO_COMPOSITE=1 to xsecurelock (which may make transparent notifications show up on top of the lockscreen)

[divVerent]

We may want to use https://stackoverflow.com/questions/33195570/detect-if-compositor-is-running to implement a compositor blacklist mechanism.

[divVerent]

What's interesting is that xcompmgr does not actually request the Composite Overlay Window. It manages to draw on top of XSecureLock without using that.

This leaves only two possibilities:

• It manages to redirect XSecureLock's subwindows of the COW, or
• The XRender extension, even though targeted at the root window, actually draws above the COW.

[divVerent]

Issue reproduces with both nvidia and nouveau, so it's probably not a graphics driver bug.

Next step will be trying to find out if xcompmgr can see XSecureLock's window, and if we can prevent it from seeing it.

[divVerent]

After adding some debugging prints to xcompmgr's code: out of all possible windows it could be redirecting, xcompmgr redirects the composite overlay window itself.

Probably not much that can be done there, then. Simply incompatible.

[tycho-kirchner]

Hi and sorry for necrobumping. I wanted to use xsecurelock with my fork of xcompmgr/compton and realized that indeed it does not work.

Probably not much that can be done there, then. Simply incompatible

If that was true, why does it work in gnome-/mate-screensaver? Additionally, these screensavers do not draw notifications on the lockscreen, while this happens indeed as described in xsecurelock's README. Possibly realted: #97