Bug#914544: xss-lock: Fails to run locker with -n and cycle time 0
Control: tag -1 +patch Ian Campbell wrote: [...] > So I believe the correct fix would be to skip the notifier if > the cycle time is zero since "The locker is started after the > first screen saver cycle". In that case a cycle time of 0 would > imply to me that the locker should be started immediately, > skipping the notifier. That would also seem to be implied by > the lack of a XCB_SCREENSAVER_STATE_CYCLE event in this case. Yes, you're right, this is the correct behavior. I forked one of the copies of xss-lock in github and implemented this solution. It's in the latest two commits of this repo: https://github.com/tpikonen/xss-lock (The 3 commits before that could also be interesting, at least they improved my usage of xss-lock) Best, Teemu
Bug#914544: xss-lock: Fails to run locker with -n and cycle time 0
Control: tag -1 +help Thanks for you report. On Sat, 2018-11-24 at 18:26 +0200, Teemu Ikonen wrote: > I think the correct behaviour in the case of cycle time = 0 would be > to run the notification and locker commands one after the other. I suppose when cycle time = 0 the XCB_SCREENSAVER_STATE_CYCLE case in screensaver_event_cb() is never called (only XCB_SCREENSAVER_STATE_ON is)? Are you able to debug that to confirm which events you are actually seeing? The docs say: -n cmd, --notifier=cmd Run *cmd* when the screen saver activates because of user inactivity. Shell-style quoting is supported. The notifier is killed when X signals user activity or when the locker is started. The locker is started after the first screen saver cycle, as set with ``xset s TIMEOUT CYCLE``. This can be used to run a countdown or (on laptops) dim the screen before locking. For an example, see the script *@CMAKE_INSTALL_PREFIX@/share/doc/xss-lock/dim-screen.sh*. So I believe the correct fix would be to skip the notifier if the cycle time is zero since "The locker is started after the first screen saver cycle". In that case a cycle time of 0 would imply to me that the locker should be started immediately, skipping the notifier. That would also seem to be implied by the lack of a XCB_SCREENSAVER_STATE_CYCLE event in this case. Looking at [0] and all the related interfaces though I don't see how to spot the case when cycle time is 0 (neither statically nor it changing dynamically). Unfortunately upstream seems to have been moribund and I'm not find any active forks (nor any inactive ones with a relevant looking fix). If you can come up with a plausible & tested patch I'd be happy to take a look with a view to applying but I do not have the time to become upstream for this software. In the meantime I'm afraid I would take the view that using the -n with cycle time = 0 (either explicitly or implicitly via something like xfce4-power-manager messing with it) is not supported, so if you want to use xfce4-power-manager then you should not use the -n option, sorry. I suppose I could clarify the documentation on this point. Ian. [0] https://xcb.freedesktop.org/manual/structxcb__screensaver__notify__event__t.html
Bug#914544: xss-lock: Fails to run locker with -n and cycle time 0
Package: xss-lock Version: 0.3.0-5 Severity: normal Tags: upstream When the X screensaver extension cycle time (as in 'xset s TIMEOUT CYCLE') is set to 0 and xss-lock is run with a notification command (the -n option), the locker command is not being run at all when timeout is reached. This of course has some security implications. This would perhaps not be a big problem, but xfce4-power-manager seems to really want to set the screensaver cycle time to 0 on startup, or whenever the 'Blank after' time is changed on the GUI. I think the correct behaviour in the case of cycle time = 0 would be to run the notification and locker commands one after the other. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xss-lock depends on: ii libc62.24-11+deb9u3 ii libglib2.0-0 2.50.3-2 ii libxcb-screensaver0 1.12-1 ii libxcb-util0 0.3.8-3+b2 ii libxcb1 1.12-1 xss-lock recommends no packages. xss-lock suggests no packages. -- no debconf information
