On Tue, 05 May 2026 18:01:28 -0300 Ricardson <[email protected]> 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.
pgp5cJ1Je6v1o.pgp
Description: OpenPGP digital signature
