[dev] [dwm] Window focus problems

[Jernej Jakob]

I'm having 2 window focus problems that started recently:

- quasselclient window is always on top of all other windows

When I put quasselclient and any other window on the same tag,
quasselclient is always on top in monocle or floating layout.
I can move it to the side and then focus and input to the window
underneath it fine

- with 2 monitors, if I switch with mod1-,/. to the other screen than
where the mouse pointer is, and the screen and tag currently focused
has no window, the mouse will pull the focus back to the other
screen's window without changing the focused window/tag, so typing
on the keyboard will go into the window underneath the mouse pointer,
but any dwm command (say mod1-p for dmenu) will go to the focused
screen/tag as it should.

For example: say the mouse pointer is currently on the right screen
above a st window which is currently focused, and the left screen is
on a tag that has no windows. I press mod1-, to focus the left
screen. The focused screen switches and the previously focused st
window on the right screen loses focus, but in a fraction of a
second, it regains focus. Typing anything other than a dwm command
will go into the st window on the right screen, while the left screen
is still focused.

I have no patches applied.

I can't point to a particular thing that could have caused them, as I only
noticed after a reboot which restarted the X session.

My recent x11-* merge history:

Wed Feb 11 14:31:47 2026 >>> x11-base/xorg-proto-2025.1
Wed Feb 11 14:35:59 2026 >>> x11-libs/libxkbcommon-1.13.1
Wed Feb 11 14:40:47 2026 >>> x11-apps/xkbcomp-1.5.0-r1
Wed Feb 11 14:41:46 2026 >>> x11-apps/xauth-1.1.5
Wed Feb 11 14:42:25 2026 >>> x11-libs/libdrm-2.4.131
Wed Feb 11 14:57:06 2026 >>> x11-wm/dwm-6.8
Wed Feb 11 14:59:16 2026 >>> x11-base/xorg-server-21.1.21
Wed Feb 11 14:59:45 2026 >>> x11-drivers/xf86-input-libinput-1.5.0
Thu Feb 12 09:25:35 2026 >>> x11-wm/dwm-6.8
Wed Feb 25 03:41:49 2026 >>> x11-libs/vte-0.80.4-r1
Wed Mar 4 04:41:42 2026 >>> x11-apps/xkbcomp-1.5.0-r2
Sat Mar 21 21:27:24 2026 >>> x11-libs/libpciaccess-0.18.1
Sun Mar 22 01:04:17 2026 >>> x11-libs/wxGTK-3.2.8.1-r2
Sun Apr 5 00:41:57 2026 >>> x11-misc/compose-tables-1.8.13
Sun Apr 5 00:42:46 2026 >>> x11-libs/libX11-1.8.13
Sun Apr 5 00:43:05 2026 >>> x11-libs/libXext-1.3.7
Sun Apr 5 00:43:25 2026 >>> x11-libs/libXmu-1.3.1
Sun Apr 5 00:43:46 2026 >>> x11-libs/libXpm-3.5.18
Sun Apr 5 00:48:30 2026 >>> x11-libs/libXrandr-1.5.5
Sun Apr 5 00:48:57 2026 >>> x11-libs/libXinerama-1.1.6
Sun Apr 5 00:49:09 2026 >>> x11-libs/libXdamage-1.1.7
Sun Apr 5 00:49:44 2026 >>> x11-libs/libXcomposite-0.4.7
Sun Apr 5 00:49:56 2026 >>> x11-libs/libXxf86vm-1.1.7
Sun Apr 5 00:50:10 2026 >>> x11-libs/libxkbfile-1.2.0
Sun Apr 5 00:50:22 2026 >>> x11-libs/libfontenc-1.1.9
Sun Apr 5 01:01:05 2026 >>> x11-misc/xkeyboard-config-2.47
Tue Apr 21 20:31:55 2026 >>> x11-apps/xdpyinfo-1.4.0
Tue Apr 21 21:03:29 2026 >>> x11-libs/libnotify-0.8.7
Tue Apr 21 21:03:50 2026 >>> x11-misc/xdg-utils-1.2.1-r10
Tue Apr 21 21:33:21 2026 >>> x11-libs/wxGTK-3.2.8.1-r2
Sun Apr 26 02:01:27 2026 >>> x11-misc/xdotool-4.20260303.1

[Ricardson]

Hi,

These look like two unrelated issues. Some thoughts and
diagnostics below.

> quasselclient window is always on top of all other windows

This is almost certainly Quassel itself, not dwm. Quassel has an
"always on top" option that asserts _NET_WM_STATE_ABOVE, which
dwm honors via updatewindowtype(). To confirm:

xprop _NET_WM_STATE

and click the quasselclient window. If _NET_WM_STATE_ABOVE is
listed, toggle the setting in Quassel (tray menu or
~/.config/quassel-irc.org/quasselclient.conf) and it should go
away.

> with 2 monitors, if I switch with mod1-,/. to the other screen

> [...] the mouse will pull the focus back

This one is more interesting. My guess: focusmon on an empty
monitor lands input focus on the root window (focus(NULL) finds
no client to focus). Shortly after, an EnterNotify is delivered
for the window under the pointer on the other monitor, and
enternotify() sees m != selmon and yanks selmon back. That would
explain the asymmetry you describe -- dwm keybindings still act
on the "new" selmon briefly, but X input focus has reverted, so
typing goes to the pointed-at window.

The timing (after the xorg-server 21.1.21 / xf86-input-libinput
1.5.0 update) is suggestive -- enter event delivery semantics
have shifted there before.

A couple of things that would help confirm:

1. Run xev over the previously-focused window and press mod1-,
to the empty monitor. Is an EnterNotify delivered right after
the switch?

2. As a quick test, stub out the body of enternotify() (just
return immediately), rebuild dwm, and see if the pull-back
disappears. If it does, the diagnosis holds and the real fix
would be a guard in enternotify() -- e.g. ignoring synthetic
enters where the pointer hasn't actually moved since the last
keyboard event.

3. Worth checking dmesg / Xorg.0.log for anything libinput-
related around the same time.

Hope that helps narrow it down.

----
Kind regards,
Ricardson (r1w1s1)

[Jernej Jakob]

On Tue, 05 May 2026 18:01:28 -0300
Ricardson <r1w...@fastmail.com> wrote:
> > quasselclient window is always on top of all other windows
>
> This is almost certainly Quassel itself, not dwm. Quassel has an
> "always on top" option that asserts _NET_WM_STATE_ABOVE, which
> dwm honors via updatewindowtype(). To confirm:
>
> xprop _NET_WM_STATE
>
> and click the quasselclient window. If _NET_WM_STATE_ABOVE is
> listed, toggle the setting in Quassel (tray menu or
> ~/.config/quassel-irc.org/quasselclient.conf) and it should go
> away.

I can't reproduce it any more. I've rebooted again since then, so that
may have fixed it.

When it was acting up, I looked at xprop and there was nothing that
would make the window be on top, definitely wasn't _NET_WM_STATE_ABOVE.

>
> > with 2 monitors, if I switch with mod1-,/. to the other screen
> > [...] the mouse will pull the focus back
>
> This one is more interesting. My guess: focusmon on an empty
> monitor lands input focus on the root window (focus(NULL) finds
> no client to focus). Shortly after, an EnterNotify is delivered
> for the window under the pointer on the other monitor, and
> enternotify() sees m != selmon and yanks selmon back. That would
> explain the asymmetry you describe -- dwm keybindings still act
> on the "new" selmon briefly, but X input focus has reverted, so
> typing goes to the pointed-at window.
>
> The timing (after the xorg-server 21.1.21 / xf86-input-libinput
> 1.5.0 update) is suggestive -- enter event delivery semantics
> have shifted there before.
>
> A couple of things that would help confirm:
>
> 1. Run xev over the previously-focused window and press mod1-,
> to the empty monitor. Is an EnterNotify delivered right after
> the switch?

KeyRelease event, serial 18, synthetic NO, window 0x1600005,
root 0x22e, subw 0x0, time 456912380, (347,474), root:(2268,494),
state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 bytes: (0d) "
XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0x1600005,
root 0x22e, subw 0x0, time 456915668, (347,474), root:(2268,494),
state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0x1600005,
root 0x22e, subw 0x0, time 456915668, (347,474), root:(2268,494),
state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

### here I press Alt_R + ,

FocusOut event, serial 21, synthetic NO, window 0x1600005,
mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 21, synthetic NO, window 0x1600005,
mode NotifyWhileGrabbed, detail NotifyAncestor

FocusOut event, serial 21, synthetic NO, window 0x1600005,
mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 21, synthetic NO, window 0x1600005,
mode NotifyUngrab, detail NotifyPointer

KeymapNotify event, serial 21, synthetic NO, window 0x0,
keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 16 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

PropertyNotify event, serial 21, synthetic NO, window 0x1600005,
atom 0x23 (WM_HINTS), time 456916968, state PropertyNewValue

### this is where it ends up after pressing Alt_R + ,

>
> 2. As a quick test, stub out the body of enternotify() (just
> return immediately), rebuild dwm, and see if the pull-back
> disappears. If it does, the diagnosis holds and the real fix
> would be a guard in enternotify() -- e.g. ignoring synthetic
> enters where the pointer hasn't actually moved since the last
> keyboard event.

I'll try later, I don't want to reboot dwm right now.

>
> 3. Worth checking dmesg / Xorg.0.log for anything libinput-
> related around the same time.

Nothing is logged at that time.