Re: [dev] [dwm] Focus bug in 5.6 when using unclutter

From: Anselm R Garbe <>
Date: Mon, 3 Aug 2009 09:56:40 +0100

Hi Eivind,

thanks for your investigation. I looked through the code and
remembered that unfocus() sets the input focus to the root window in
order that clients are notified with FocusOut (in terminals this has
the effect that the cursor turns into unfocused state).

So in general there is nothing wrong with setting the input focus to
the root window during unfocus() -- that's also usual practice in
other WM implementations. I suspect there is a side-effect with
unclutter though, haven't looked at its code, but it surely must do
some nasty trick to void the cursor, which might have some side-effect
if it receives FocusIn on the root window, which is why I propose to
look at unclutter next, since I bet the real fix is on that side... ;)

But let's see.

Kind regards,

2009/8/3 Eivind Uggedal <>:
> After updating from 5.5 to 5.6 I encountered a bug relating to unclutter[1].
> Steps to reproduse:
> 1. Start dwm 5.6 with default config and unclutter with default params.
> 2. Open more than one window in the active tag.
> 3. Wait until unclutter hides the cursor.
> 4. Switch to a window not focused by the previously visible cursor using the
> keyboard.
> 5. The window border will start flickering (looking like it gets unfocused
> and focused rapidly in succession).
> 6. The cursor will also start to flicker.
> 7. Using the keboard to focus the window the cursor was focusing when
> visible will stop the flickering. Moving the cursor (so that unclutter
> displays it again) will also stop the flicker until unclutter hides it
> again.
> This bug was introduced in changeset 1418 37e3b2a40f6f [2]. The problem is
> that XSetInputFocus is called through the unfocus() function from focus().
> As I'm not familiar with Xlib I'm not sure how to fix this bug, but I've
> been able to pinpoint the erroneous code and disable the XSetInputFocus call
> when unfocus() is called from focus().
> I've attached a patch against changeset 1477 aefd753cfe9b which does exactly
> this. Note that this was made just to highlight which code path triggers the
> described behavior and is not meant as a patch for fixing the bug.
> [1]:
> [2]:
> --
> Cheers,
> Eivind Uggedal
Received on Mon Aug 03 2009 - 08:56:40 UTC

This archive was generated by hypermail 2.2.0 : Mon Aug 03 2009 - 09:00:02 UTC