Silvan Jegen wrote: > From what I understand, in case that the client does not have focus > already, with this patch we call XGrabButton twice compared to before the > patch. I assume that corresponds to the advertised functionality.
Heyho, Not only twice but multiple times per button mapping and possible modifier mask. I'm not sure why this is needed, but I tested it with several slight modifications and none of them worked. > On Sat, Jan 07, 2017 at 05:21:29PM +0100, Markus Teich wrote: > > @@ -932,17 +934,16 @@ grabbuttons(Client *c, int focused) > > unsigned int i, j; > > unsigned int modifiers[] = { 0, LockMask, numlockmask, > > numlockmask|LockMask }; > > XUngrabButton(dpy, AnyButton, AnyModifier, c->win); > > - if (focused) { > > - for (i = 0; i < LENGTH(buttons); i++) > > - if (buttons[i].click == ClkClientWin) > > - for (j = 0; j < LENGTH(modifiers); j++) > > - XGrabButton(dpy, > > buttons[i].button, > > - buttons[i].mask | > > modifiers[j], > > - c->win, False, > > BUTTONMASK, > > - GrabModeAsync, > > GrabModeSync, None, None); > > - } else > > + if (!focused) > > XGrabButton(dpy, AnyButton, AnyModifier, c->win, False, > > - BUTTONMASK, GrabModeAsync, GrabModeSync, > > None, None); > > + BUTTONMASK, GrabModeSync, GrabModeSync, > > None, None); > > Here we pass "GrabModeSync" instead of "GrabModeAsync" as the "pointer > mode". According to https://tronche.com/gui/x/xlib/input/XGrabPointer.html > if the mode is "GrabModeSync", > > "the state of the pointer, as seen by client applications, appears to > freeze, and the X server generates no further pointer events until > the grabbing client calls XAllowEvents() or until the pointer grab > is released." > > Since we are calling XAllowEvents on buttonpress that should make sure > that only the focused client gets any pointer events, I assume? In my understanding the point of the XAllowEvents call is to replay the event on the client under the cursor after it has been focused. > I have been runnig with this patch for most of the day and haven't > encountered any issues. > > > + for (i = 0; i < LENGTH(buttons); i++) > > + if (buttons[i].click == ClkClientWin) > > + for (j = 0; j < LENGTH(modifiers); j++) > > + XGrabButton(dpy, buttons[i].button, > > + buttons[i].mask | > > modifiers[j], > > + c->win, False, BUTTONMASK, > > + GrabModeAsync, > > GrabModeSync, None, None); > > } > > } Disclaimer: This patch is a bit of a grey area for my understanding of the grabbing mechanics. While preparing the user-patch for unsloppy focusing I noticed this bit from Erics patch is used to fix a bug which is also present in vanilla dwm. It's a little improbable to hit this bug in vanilla dwm, which is why it probably hasn't been discovered previously. So I just took the bug-fix part from Erics patch, applied it to vanilla dwm, also tested it for a while and it worked as I intend it to. However I would be very thankful if someone with more knowledge of the grabbing semantics could explain why exactly the bug occurs before this patch, why the changes in this patch fix that behavior and ultimately approve this patch for merging. --Markus