Issue 456 in xmonad: xmonad partially eats key events comprising a WM shortcut
Status: New Owner: ---- New issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 When I invoke a keyboard shortcut of XMonad this happens: Mod key down (eg. Super) is received by application action key down (eg. C) is eaten by XMonad <At this point Mod release should be sent to application> , action is performed. action key release and Mod key release is eaten by XMonad Mod is stuck down in application XMonad should send key release for modifiers it ate to the application. It should do so before performing the action bound to the key because at that point it is known the key will be eaten and the application that received the bogus key down is still active. If the action is some WM action that switches windows the only time when this fixup can reasonably happen is before performing the action.
Comment #1 on issue 456 by daniel.w...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 It's wrong for an application to assume that a key stays down until it receives an up message -- X makes no promises to deliver such messages to non-focused windows. If you have an application making that assumption, it's a bug in that application, not in xmonad.
Comment #2 on issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 The application is focused.
Comment #3 on issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 OK, to make it clear, you say that in the case when application loses focus as a result of invoking a keyboard shortcut blame should be placed on the application because it should not expect to receive key events that might have happened while it was not focused. However, if the keyboard shortcut does not result in focus change then the blame is to be placed on XMonad for eating the key events asymmetrically.
Comment #4 on issue 456 by daniel.w...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 Well, X makes no promises anyway, regardless of focus. Sorry for putting that red herring in my message.
Comment #5 on issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 Can you, please, explain where it is stated that X generates key events at random without any relation to keys physically pressed on the keyboard? Searching around the Web I found a piece of Xlib manual detailing keyboard events here: http://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html It says that key events may lag if input processing is frozen but not that key events are randomly lost in X server. If you have a manual stating otherwise then please share where it is located. Otherwise I would say that the observed behaviour points to an issue with XMonad - the application is very capable of tracking the key state unless a key event is eaten by XMonad. Thanks
Comment #6 on issue 456 by daniel.w...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 It is located here. http://tronche.com/gui/x/xlib/input/XGrabKeyboard.html In particular, "Further key events are reported only to the grabbing client.".
Comment #7 on issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 Meaning that XMonad is using a grab and although the window is rendered with focused frame all the time it should receive a focus out and focus in when the key shortcut is invoked. Therefore if the application performs a query of key state every time it is focused it should work as expected.
Comment #8 on issue 456 by daniel.w...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 Yes, that sounds correct. I also just tested with xev, and it does indeed report FocusOut and FocusIn events when I whack keys bound by xmonad (but not when I whack keys not bound by xmonad).
Comment #9 on issue 456 by hramr...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 I also tested in notepad with Ctrl key and focus-follows-mouse and it gives the same symptoms without any XMonad involvement whatsoever. Wine issue.
Updates: Status: Duplicate Mergedinto: 276 Comment #10 on issue 456 by daniel.w...@gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 (No comment was entered for this change.)
participants (1)
-
codesite-noreply＠google.com