workrave hangs after unlocking with input blocked

I can reproduce this with rest break. I locked and went to shower. When I came
back, I unlocked xscreensaver and workrave had hanged itself.

It was time for a rest break, so I locked the screen, came back and workrave had
hanged. I had to switch to a virtual terminal and kill it. Happened twice today.

Ubuntu 5.10 (Breezy Badger)
workrave 1.6.2-1ubuntu4

my guess is that it doesn't deal well with one or both of other keyboard grabs
or override-redirect windows, and sleeps with what appears to be an exponential
backoff while attempting to regain control. if I move quickly after the
screensaver kicks in, I only have to wait a second or two to regain control. a
few hours, and it's VT switching and killall time. (incidentally, this bug is
humongously frustrating when you've broken XKB and thus can't switch VTs at all.)

workrave seems happier with gnome-screensaver than it was with xscreensaver; is anyone still seeing this problem?

To answer my own question, yes, this is still happening in current Dapper.

When I strace gnome-screensaver when it's in this state, it's in some sort of weird loop in gs_grab_move_mouse where it sleeps and retries again and again. I think this is in fact a gnome-screensaver problem; would someone contact upstream?

It sounds as if both gnome-screensaver (or xscreensaver) and workrave are fighting for access to mouse movements,.

Just to add a confirmation it happens here too (Dapper, current).

If gnome-screensaver locks during the rest break, unlocking it when i'm back blocks the unlock dialog (goes gray without any input possible).

"killall gnome-screensaver" from the VT shows me a (presumably) workrave gray fullscreen (no trace of "rest break text" of buttons).

I killall workrave from the VT, screen is back normal.

=> I have to killall *both* to get back to usable screen.

I can get a working screen by killing just workrave.

Olivier (or someone else) can you please confirm that killing just workrave does _not_ get you back to a usable screen?

Try the following:

- Start restbreak
- Click lock
- Move mouse to open password dialog. Enter correct password.

confirmed in workrave

needs info for gnome-screensaver

sorry for the delay. Doing exactly as you suggest (killing only workrave) gets me to a usable workspace... gnome-screensaver seems not be faulty here.
i've tried 2 times to be sure, killing *only* workrave solved the "hang" problem.

Does not seem to be caused by gnome-screensaver (it happened with xscreensaver as well). Workrave has to be fixed here.

 workrave (1.8.4-1ubuntu1) feisty; urgency=low
 .
   * Merged with Debian, remaining Ubuntu changes:
     - debian/applied-patches/server-file-changes.patch:
       - change applet category and hardcode icon.
     - debian/rules, debian/control:
       - build-depends on intltool and do translation magic.
   * debian/control:
     - changed Maintainer field.
   * debian/applied-patches/update-POTFILES.in:
     - updated po/POTFILES.in to make intltool-update happy again.
 .
 workrave (1.8.4-1) unstable; urgency=low
 .
   * New upstream version
     - KDE applet space fixed (closes: #289382)
     - historystats reader fixed (closes: #390495)
   * Add dependency on libxtst-dev to enable XRecord extension (closes: #388669)

Please sync with the last debian version that close debian bugs: #441930, #416252.
This last version solve a bug about an use of a bogus check to detect which screensaver
locking command to use that i think cause a problem on unlocking when gnome-screen saver and xscreensaver are both installed..

As Debian has a newer upstream version and Ubuntu is in Upstream Version Freeze, this needs an exception from the release team.

If somebody wants to work on the Ubuntu/Debian merge, I'm happy to mentor and sponsor.

Unassigning from MOTU, workrave is in main.

Fixed: ubuntu has 1.8.5 now.