[SOLVED] Fluxbox Ignores First Keypress After Switching Virtual Desktops
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Fluxbox Ignores First Keypress After Switching Virtual Desktops
I've been having this problem for a while back when I had installed current but I figured that it was some problem that was due to some package I had installed that went wrong. However, I found that it was also present after installing Slackware 14.0 from scratch, so I'm guessing this bug is deeper than I thought.
The problem is simple, I type into one window in my first virtual desktop, switch desktops, and whatever window I try to type into, no matter how many times I click to make sure that the window has the focus, will ignore my first keystroke. After that it works perfectly, until I switch desktops again when it will ignore my first keystroke.
This also seems to interfere with xlock when I activate it. If I haven't typed anything in the virtual desktop that I just switched to and selected the lock option from the menu, the screen will go black behind my still visible cursor and then go back to the desktop. Pressing any key and then trying xlock will result in it successfully locking.
Searching around for others who had this problem gave me only one result, in this thread on the arch forums: https://bbs.archlinux.org/viewtopic.php?pid=1102452
The person appears to have had the same issue and says that it was resolved after an upgrade to Xorg which isn't fixing it for me since everything is as new as it's going to get for a while. Can anyone help point out what might resolve this issue for me?
I use Fluxbox with Current on two computers, and I have not encountered this.
I have a couple of troubleshooting ideas, but they are just off the top of my head.
Open a terminal in two workspaces, then start xev (I think it comes with Slackware). Try switching back and forth between workspaces, typing a couple of characters, and seeing whether xev displays output on the first keypress.
If this is a desktop, try changing out the keyboard and seeing if the problem persists. If you don't have a spare, maybe you could borrow one from a friend for five minutes or so. If it's a laptop, test with an external keyboard (the idea here is to rule out hardware).
After that keypress, all the other keypresses output proper events that look like this:
KeyRelease event, serial 36, synthetic NO, window 0x1600001,
root 0x156, subw 0x0, time 1217959, (5,244), root:(1152,461),
state 0x0, keycode 42 (keysym 0x67, g), same_screen YES,
XLookupString gives 1 bytes: (67) "g"
XFilterEvent returns: False
This is on a laptop, so I did as you suggested and tried it with an external keyboard and the result is the same as if I was using the built-in keyboard, so I assume that hardware can be ruled out as the culprit. What else do you suggest that I try?
I have no idea what might be causing this, but I realized this morning that I had omitted one suggestion--boot to a Live CD of something and test under the Live CD. If the problem occurs under the Live CD, that will point the finger at some obscure sort of hardware problem; if it doesn't, then there's something screwy with your software load.
Since you indicate that it took a while to reproduce the error in your testing, give the Live CD a nice long workout.
@frankbell Alright, finally got done with my Live CD testing. I used the GParted Live CD which comes installed with Fluxbox by default, and after extensive testing I did not see the problem come up once. Everything worked as it should, so the problem must lie within Slackware. Any suggestions on what I should try next?
@H_TeXMeX_H This seems to happen with any program that has text input. It's happened with rxvt, xterm, Seamonkey, Google Chrome, Sublime Text, just to name a few, so I don't think it's related to any one program.
A couple of other things. I spent a little more time pin pointing what triggers this and I believe that it's a little more complex than I initially thought. This is the exact process (for me at least) :
Open four windows, say some text editors, and place 2 of the windows in the first desktop and 2 of the windows in the second desktop.
Type into one window.
Shift the focus to the other window.
Press Ctrl-F2 to switch to the next desktop.
You should notice that the text line in the window is now gone, and will only reappear once you press a key.
Type into one of the text editors.
Switch focus to the second window.
Press Ctrl-F1 to switch to the first desktop.
The text line in the window should again be gone.
Note that this will only happen if I use Ctrl-F# to switch desktops, using the arrow switchers at the bottom left to switch desktops does not trigger the problem. Also, simply typing in text alone will not trigger the problem, switching windows after typing and then switching with Ctrl-F# will bring about the problem.
I have also tried deleting my fluxbox config and letting it install the defaults. This didn't fix the problem either.
1) Install the wmctrl package
2) Alter my .fluxbox/keys file.
Change key bindings:
# change to a specific workspace
Mod1 F1 :Workspace 1
Mod1 F2 :Workspace 2
Mod1 F3 :Workspace 3
Mod1 F4 :Workspace 4
# change to a specific workspace
Mod1 F1 :ExecCommand wmctrl -s 0
Mod1 F2 :ExecCommand wmctrl -s 1
Mod1 F3 :ExecCommand wmctrl -s 2
Mod1 F4 :ExecCommand wmctrl -s 3
3) Restart fluxbox or reload configuration
I left the default Control F# part from the default keys file alone but changed Workspace # to ExecCommand wmctrl -s #.This worked for me and I haven't had any problems as of yet. Marking this thread as solved. Thanks to everyone who helped