Re: [dev] [slock] won't lock if unclutter grabbed mouse pointer

From: Andreas Doll <fuseki_AT_posteo.de>
Date: Fri, 15 Jan 2016 20:12:41 +0100

On 2016-01-15 at 19:40, Markus Teich wrote:
> I assume this is the same issue for slock. From XGrabKeyboard(3):

> > If the keyboard is actively grabbed by some other client, XGrabKeyboard fails
> > and returns AlreadyGrabbed.

> For screenlockers grabbing the keyboard is a must so no other client can
> intercept the password when entered to unlock the screen. Users of `unclutter
> -grab` could kill the unclutter process before running slock/i3lock and restart
> it after the screen has been unlocked. For i3lock this is not so easy, since the
> i3lock process daemonizes itself and returns immediately, so the naive `pkill
> unclutter && i3lock && unclutter -grab` approach won't work.

By the way, xscreensaver successfully locks the screen, and prints

couldn't grab pointer! (AlreadyGrabbed)

and displays the verification window only upon keyboard activity. Without
unlcutter this window appears also on mouse input.


> > so the issue seems to be caused by unclutter. Hence maybe a manpage entry
> > warning about that behaviour is sufficient. Do you agree, or are you still
> > planning to fix this within slock?

> I don't think it can be fixed in slock. I'm not sure, if we can "blame"
> unclutter for the issue, but if we can, then the hint should go into their man
> page or even better it should be fixed there.

It is not clear to me whether unclutter is actively maintained, Debian links
to a dead ftp repository, Slackware to a sourceforge page, where the code
wasn't modified since more than 2 years.

Personally I'd prefer to have the hint in slocks manpage, as it took me some
time to realize what's going on. The Debian maintainer chose to write a
distro-specific manpage for slock - for now I'll report the behavior to him
and let him decide whether he wants to include this.
Received on Fri Jan 15 2016 - 20:12:41 CET