I frequently need to enter key combinations that require pressing and holding both the Shift and Alt (Meta) keys. An example would be the Emacs mark-word command (bound to M-@ by default): to enter it, I would press and hold Shift, press and hold Alt, and then press the @/2 key on the keyboard. In xorg-x11-drv-keyboard-1.0.1.3-1.2 (the Fedore Core 5 package), the state modifiers depend on the order in which the keys are pressed. Specifically, if I press Alt-Shift-@, the state modifier returned on the keypress event is 0x9 (0x1 = Shift, 0x8 = Alt) according to xev: KeyPress event, serial 28, synthetic NO, window 0x3e00001, root 0x4c, subw 0x0, time 3094865719, (86,91), root:(90,110), state 0x9, keycode 11 (keysym 0x40, at), same_screen YES, XLookupString gives 1 bytes: (40) "@" XmbLookupString gives 1 bytes: (40) "@" XFilterEvent returns: False This is correct. However, if I press Shift-Alt-@ (that is, I press the Shift key before the Alt key), according to xev, the state modifier returned on the keypress event is 0x1: KeyPress event, serial 28, synthetic NO, window 0x3e00001, root 0x4c, subw 0x0, time 3094891814, (90,70), root:(94,89), state 0x1, keycode 11 (keysym 0x40, at), same_screen YES, XLookupString gives 1 bytes: (40) "@" XmbLookupString gives 1 bytes: (40) "@" XFilterEvent returns: False This is *not* correct; the Alt state modifier has been lost. This is a very big deal to me, because the way I tend to type, I almost always hit the Shift key before the Alt key. Furthermore, this doesn't happen 100% of the time. Occasionally the X server will work correctly; that is, the modifier keys don't depend on the order in which they are pressed. However, I've been unable to figure out what (if anything) I did to get it to work correctly.
See also the downstream bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189518
Bumped this up to major, as a) it's significantly affecting my productivity, and b) it's a regression on the previous working behaviour.
*** This bug has been marked as a duplicate of 2871 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.