Do not mess with DPMS/blanking

[vincentbernat]

This is the job of the DPMS setting. We only stop children when Xss
blanks the screen or when DPMS blanks the screen. The last part is a
bit inefficient as there is no event associated.

This has been discussed in #84.

Also, I am adding another related commit to optionally not kill saver when DPMS kicks in. I can submit it separately if needed (but the code is highly related to this one).

I would prefer to merge #138 first, then rebase (since this is the code that I am actually running).

[vincentbernat]

I have force pushed an update to match current master. Unfortunately, I think it means it may break #120 (not sure if we can wake up from DPMS without explicit call to DPMS).

[divVerent]

For the use case here, the DPMS integration is essential - so maybe put this change behind a environment variable flag? The reason why it exists is that it seemed a common wish to blank the screen earlier after locking the screen and walking away than when leaving it unlocked - in fact, we see DPMS while unlocked as dangerous as one may think it is locked and go away from an unlocked machine.

…

On Sun, Aug 14, 2022, 14:12 Vincent Bernat ***@***.***> wrote: I have force pushed an update to match current master. Unfortunately, I think it means it may break #120 <#120> (not sure if we can wake up from DPMS without explicit call to DPMS). — Reply to this email directly, view it on GitHub <#139 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5NMGTIDROTJCC4CAWX3DVZEZHVANCNFSM5KZLONQQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[vincentbernat]

This has been discussed a bit in #84. However, when using xss-lock, because suspending Xss also suspends DPMS timer, it does not seem possible to have DPMS on while the screen is not locked (unless XSecureLock did not start). But I understand that for other use cases, it may be preferable to let XSecureLock handle all the blanking.

I can put an environment flag if you are OK with it.

[divVerent]

Good, yeah - let's make this a flag for now and off by default. On a major release we can break compatibility this way and remove DPMS usage if we can find a way to guarantee that xsecurelock always runs when the screen is blanked - even if the system is rather busy.

…

On Sun, Aug 14, 2022, 19:14 Vincent Bernat ***@***.***> wrote: This has been discussed a bit in #84 <#84>. However, when using xss-lock, because suspending Xss also suspends DPMS timer, it does not seem possible to have DPMS on while the screen is not locked (unless XSecureLock did not start). But I understand that for other use cases, it may be preferable to let XSecureLock handle all the blanking. I can put an environment flag if you are OK with it. — Reply to this email directly, view it on GitHub <#139 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5NMCPS32AMN4QPJEISZTVZF4VFANCNFSM5KZLONQQ> . You are receiving this because you commented.Message ID: ***@***.***>

[vincentbernat]

Humm, it seems this setting already exists. XSECURE_BLANK_TIMEOUT could be set to -1. So, no patch needed I think. Looking at the various code paths, I think it does the job.

It still quite an unexpected default and I think this unclear what the goal was. I suppose we could emphasize in the README that the default setup expects XScreenSaver/DPMS to not be enabled by default (in X configuration) and that xsecurelock will handle them. Then, the default setting makes sense.