xorg-7.2, fluxbox-1.0_rc3 When I open a window (lets say xterm), type something, switch layout to russian, type something and then switch to other window via Alt+Tab, my input freezes (can not type anything) in any window until I'm again press group switch key. Also I tried to launch two instances of 'xev' and repeat same steps (switch layout to RU, then switch to other window with Alt+Tab): pressing different keys does not produce any keyboard events. If I switch window by mouse click, bug not appears. Another window manager (twm, e16) also works. Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc104" Option "XkbLayout" "us,ru(phonetic)" Option "XkbOptions" "grp:toggle,grp_led:scroll" EndSection Reproducible: Always
Indeed, I can replicate this as well with a dvorak/qwerty dual group layout. Have you tried it with any other window managers? I'll mention this to upstream and see if they know anything about it. For anyone else wanting to test this, from inside a running fluxbox: setxkbmap us,dvorak -option -option grp:toggle Then pressing right-alt once will switch groups. From then on, window switching with alt+tab does weird things. It does seem to switch the window focus (titlebars change colours, windows are moved to the front), however: - The keyboard basically goes dead (no input into any windows, however, fluxbox keybindings continue to work) - "Focus follows mouse" gets turned off, reverting to "focus when clicked" These symptoms persist, even if you continue switching back to the original window (it will no longer recieve keyboard input), and will persist until you switch back to your primary xkb group.
Note: If you only switch window focus using the mouse and avoid hitting alt+tab altogether, everything works fine, and you can send 2nd-group input into any window.
to Jim Ramsay > Have you tried it with any other window managers? Yes, I tried this with twm, e16 and without any window manager (two instances of xterm launched via .xinitrc). Bug appears only with fluxbox. Just emerged fluxbox-1.0_rc3-r2, problem persists. Will try other *box clones a bit later... Bug also persists with different group switching keystroke, for example Ctrl+Shift. Don't know exactly which software component or combination of them produced such behavior. I've noticed this after world upgrade, which touched both Xorg and fluxbox.
I have noticed keyboard input problems in fluxbox for some time now. Sometimes the window is active but actually does not receive any keyboard input, until I select another window with the mouse and then go back to the window I wanted originally. This also happens if the window is the only window on the current desktop. Since people are suspecting multi language input, I want to add that I am using scim for Japanese/English input on my machine. However, I did not notice any connection between scim and the keyboard focus problem yet. I.e. the problem happens also when I don't use scim (switch input modes) at all. I'm on ~x86 Gentoo (updated every 2-5 days) and the problem came up about 4 weeks ago. Currently running xorg-x11 7.2, fluxbox 1.0_rc3-r2.
Just tried Openbox and it works fine, so I think problem is related to Fluxbox and not to Xorg.
I can now reproduce the problem, or part of it: - open a terminal window (urxvt) - run acroread somefile.pdf - kill acroread using ctrl-c in the terminal window - type something... keyboard input is going nowhere Strangely, this does not happen for other apps, for example just running another urxvt from urxvt and killing that with ctrl-c, the keyboard focus is still there. acroread is the only app I can reproduce the problem with 100%, although the problem occurs even while not using acroread at all, for yet unknown reasons. The problem is linked to scim in some way. It occurs only while scim is running, even if scim is inactive (no special input mode in use). The problem occurs 100% when following the steps above while scim is running, but does not occur when you quit kill scim.
(In reply to comment #6) > I can now reproduce the problem, or part of it: > > - open a terminal window (urxvt) > - run acroread somefile.pdf > - kill acroread using ctrl-c in the terminal window > - type something... keyboard input is going nowhere This may not actually be related to the issue at hand - Some apps mess with the terminal (not sure if acroread is one of them) For example, if you try a CVS update, get prompted for a password, then CTRL+C out, you may end up with the same circumstance. Typing "reset[enter]' in the terminal (even though you don't see anything appear while you're typing) should solve the problem. Was this problem you explain replicated in fluxbox, or a different wm?
It is in fluxbox, and to get keyboard input working again, all you have to do is switch to another window and then back (or if it's the only window, switch to the desktop you're currently on, as that refocuses it as well). It is not an issue of typing 'reset' in the terminal - the window simply does not get any input even though it looks active. You can't reset, you can't exit, you can't exec commands. I could not reproduce the problem yet in openbox / fvwm2, but I also couldn't get scim running properly in them either. So now I'm emerging xfce4 to test. Will report back later wether the same issue appears there or not.
I just tested with xfce4. It has the same problem - keyboard focus is simply lost after closing another window, in this case by ctrl-c on acroread. Happens only while scim is running (not active, just the scim icon shows up in the system tray). So the problem I am seeing seems to be related to scim, not fluxbox.
Upstream knows about this bug, and it is slated to be fixed before the actual 1.0 release. Upstream bug tracker reference: http://sourceforge.net/tracker/index.php?func=detail&aid=1736252&group_id=35398&atid=413960
Upstream has fixed this in their svn. I will probably roll this into another snapshot release shortly.
