Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state

From: David Phillips <david_AT_sighup.nz>
Date: Tue, 28 Aug 2018 10:24:43 +1200

On Mon, Aug 27, 2018 at 02:16:38PM -0400, Michael Spradling wrote:
> Currently if the first character pressed is the shift key, slock moves
> to the failed state. The failed state can modify the display and
> provide incorrect feedback to the user and also gives away that your
> first character required the shift key.
> ---
> slock.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/slock.c b/slock.c
> index 5ae738c..e9dd1ad 100644
> --- a/slock.c
> +++ b/slock.c
> _AT_@ -154,7 +154,9 @@ readpw(Display *dpy, struct xrandr *rr, struct lock **locks, int nscreens,
> IsKeypadKey(ksym) ||
> IsMiscFunctionKey(ksym) ||
> IsPFKey(ksym) ||
> - IsPrivateKeypadKey(ksym))
> + IsPrivateKeypadKey(ksym) ||
> + ksym == XK_Shift_L ||
> + ksym == XK_Shift_R)
> continue;
> switch (ksym) {
> case XK_Return:
> --
> 2.18.0
>

The patch Michael Buch linked should work for you. For background, I
created it because previous discussion hereabout 2 years ago showed
that the community rather keep slock extremely paranoid and ready to
trip to the failed state at any keypress in order to indicate any
form of tampering.

The control-clear patch tones that down a bit for those users who
don't need this fine a trigger.

Thanks,
David
Received on Tue Aug 28 2018 - 00:24:43 CEST