Mode should be updated based on DPMS status
Submitted by tes..@..il.com
Assigned to Ali Abdallah @ali
Description
It would be ideal to have the Mode (Normal or Presentation) updated based on the current status of DPMS. For example, if Presentation Mode is selected and xflock4 is activated, DPMS will be re-enabled and the Mode will still be displayed as Presentation.
Version: 1.2.0
Activity
(In reply to tesoro302 from comment 0)
It would be ideal to have the Mode (Normal or Presentation) updated based on the current status of DPMS. For example, if Presentation Mode is selected and xflock4 is activated, DPMS will be re-enabled and the Mode will still be displayed as Presentation.
Which locker do you use by xflock4?
It would be even more ideal, if after locking screen by xflock4 DPMS state would be reverted to the previous state when screen is unlocked. In the current implementation of xflock4, "xset dpms force off" is used when starting conventional lockers. That enables DPMS and I think it is impossible to revert the DPMS state upon unlocking with them, if xflock4 is supposed to fork. So maybe removing "xset dpms force off" from xflock4 would be a good idea. If mouse or keyboard activity occurs, display will be turned on anyway, and if DPMS is enabled and nonzero timeout is set, it will turn display off anyway after the timeout.
-
I can reproduce this in 1.4.4
On the other hand, it is good to enable DPMS while locking display.
xflock4 may enable DPMS features and it may not revert to the settings that were before calling xflock4. The power manager setting does not follow this change nor does the power manager return the change. Is there a way to know if screen is locked in general case?
-
@ochosisaid:Neither did I add that portion to xflock4 about DPMS nor do I have any clue as to why it was added - I can only presume that those lockers take care of re-enabling DPMS. (If not we would have seen tons of bugreports against this particular feature of xflock4 ages ago already.) Keep in mind that we're just calling a dumb script here and the only way of "knowing" (in fact: assuming) whether locking succeeded is its return code.
So yeah, I don't see any way to reliably track (successful) locking in any given locker, plus locking is actually another application's responsibility.
-
(In reply to Simon Steinbeiss from comment 5)
Neither did I add that portion to xflock4 about DPMS nor do I have any clue as to why it was added - I can only presume that those lockers take care of re-enabling DPMS. (If not we would have seen tons of bugreports against this particular feature of xflock4 ages ago already.)
That was added to save monitor/energy when some locker that does not handle turning off monitors by themselves, is used. And what is the problem here, is that in this way they do not disable DPMS after locking quits, in case it was disabled before the locking starts. We can use a wrapper script to handle restoring the DPMS state.
However DPMS state may be altered elsewhere, thus confusing the Normal/Presentation mode of power manager.
-
(In reply to Jarno Suni from comment 6)
That was added to save monitor/energy when some locker that does not handle turning off monitors by themselves, is used. And what is the problem here, is that in this way they do not disable DPMS after locking quits, in case it was disabled before the locking starts. We can use a wrapper script to handle restoring the DPMS state.
I have equipped xflock4 by such a wrapper in some attachments of Bug #10217. The DPMS hack works with lockers that do not fork and do not change DPMS settings themselves.
mentioned in issue #56 (closed)
unassigned @ali
added 5. Presentation Mode label
added 2. Feature 3. Won't Fix labels
Screensaver management has been removed from xfce4-power-manager while presentation mode has been made consistent with inhibited mode, so I think it's all pretty outdated now. Also, what was mentioned above about tracking the screensaver and/or lock status seems to be a very bad idea, and unfeasible on Wayland. Closing.