Control: retitle -1 pinentry-gtk-2 frequently fails to grab the pointer under fvwm Control: tags -1 -unreproducible
since it is reproducible with fvwm (now mentioned in the bug title) and the reason is clearly given in the fvwm(1) man page. On 2017-01-11 01:47:53 -0500, Daniel Kahn Gillmor wrote: > Unfortunately, i don't know enough about fvwm and how it might affect > kbd grabbing to know what the right thing to do here is. Note that pinentry-gtk-2 and pinentry-qt both grab the keyboard and are successful in doing it, possibly after several tries, but this seems to be independent from the window manager: 2016-08-01 Justus Winter <jus...@g10code.com> gtk2: Be more persistent trying to grab the keyboard. We seem to get the 'visibility-notify' event before X is willing to let us grab the keyboard, insisting that the target window is not viewable (sic). I think that this behavior is expected. Without locking mechanism, there's a race condition between X and the application. BTW, this is even mentioned in the Debian changelog (apparently more issues in the past): pinentry (0.7.5-2.1) unstable; urgency=low * Non-maintainer upload. * gtk+-2/pinentry-gtk-2.c: apply patch to avoid keyboard grab race on SMP systems (closes: #401957). -- Pierre Habouzit <madco...@debian.org> Mon, 20 Oct 2008 15:11:18 +0200 What is specific to Fvwm is pointer grabbing, not keyboard grabbing. And this is where pinentry-gtk-2 fails (CRITICAL instead of WARNING). I've updated the title of the bug. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)