Well, as I found out after SSH'ing in and killing xscreensaver, I had Eye of Gnome (media-gfx/eog) running with an image fullscreened, and then wandered off for a bit. Upon coming back, I found that xscreensaver didn't respond to the keyboard AT ALL. Mouse input woke it up and it prompted me for my password, but I couldn't type it. Neat. Reproducible: Didn't try Steps to Reproduce: 1. eog /path/to/file.jpg 2. hit F11 3. wait for xscreensaver to do its thing Actual Results: see details Expected Results: well, um, let me unlock my screen. good thing I have sshd on all my boxes even the workstations...
Not reproduceable.
Attempted to and successfully reproduced. Just open something in EOG (I was using the collection view feature, where you just run 'eog /path/to/someimages/ &'), press F11 so it fullscreens, and wait for xscreensaver to do its thing. You'll also notice that eog is obnoxious and captures other useful input, like virtually anything I have bound to various functions via my windowmanager (fluxbox). Of course, xscreensaver should be able to cope with this, as it should be capable of doing to eog exactly whatever eog is doing to the rest of my workspace.
Reopening.
also understand that "fullscreened" = hitting F11, not maximizing the eog window. sorry if that caused any confusion before.
reproduced here as well. ssh in and killed eog which gave me my desktop back but still no mouse or keyboard. Only killing xscreensaver gave me control back. FWIW, I am using my ebuild of xscreensaver 4.18.
Potentially a problem with eog not releasing the keyboard, CC'ing gnome team.
taking over, but i think it might be eog or a windowmanager thing
It's sort of an EOG thing, but at this point I've seen xscreensaver specifically say that it can't grab the keyboard, which would be *pretty good* criteria for doing something other than locking the screen w/ password. Obviously, xscreensaver's functionality should probably become part of x.org so that it's not fighting for control at the normal X11 client level.
xscreensaver 4.17 introduced this fix: * I give up: don't blank or lock the screen if we can't get a keyboard grab. In that case, both choices are bad. Perhaps that has fixed your issue. I just added 4.20 to portage, please try and let us know what you find.
Yup, it refuses to even blank now, so there's no longer a CRI bug on xscreensaver's part. However, when I tested it this time around (I'll see if I can find time to do a bit more and see what I can nail down..) eog locked my mouse + keyboard, so I couldn't do anything (which, without VC or SSH support forces a user to kill X and lose data). This bug should probably become one to get upstreamed to the Gnome people, as I don't think any of their other apps do anything quite this stupid. Leaving as CRI; reassigning to gnome@. As for the EOG bug: Clearly this is something that should also be upstreamed to x.org, as they seem to care about problems with X... not being able to interact with your windowmanager/anything else because of an app (even after killing it) is not a good behavior. Still, IMO, this should get fixed in EOG, as the fewer applications we have that trigger the greater problem at hand the less damage it's going to cause. Gthumb, for example, does the same thing without locking KB/mouse input. Also CC:ing x11@ for their input... perhaps the suggestion upstream should be that DPMI be disabled a-la-XINE/etc whenever input is grabbed so this doesn't happen? I may go file a bug w/ xorg once I've looked into the issues involved a bit more.
To all here, Is this bug still an issue 22 months later ? :) Don't hesitate to reopen with new version info if it's still happening. Thanks
