Help my Fluxbox is cursed!
|
| Author | Content |
|---|---|
| techiem2 Nov 17, 2008 7:31 PM EDT |
Ok, this is quite odd.
A couple days ago I restarted X, and since then, whenever the mouse goes over a window border for a couple ns (i.e. pretty much any longer time than just passing the border), it goes into grab and resize mode.
It doesn't seem to be the mouse as it behave perfectly normal everywhere else (as does a second mouse I plugged in).
Any bright ideas what in the world might be causing it?
It's rather annoying..... /me scratches head in confusion |
| Sander_Marechal Nov 17, 2008 7:51 PM EDT |
I have one idea. Test: Does OpenOffice behave odd? As in, it's popping up the menu all the time? I am having a problem on my latop where fake Alt keypress events are being generated inside X.org and sent to the windows. If you have Alt set to toggle grab mode, that may be it. You don't notice it normally since just a single Alt keypress/release usually doesn't do anything (except in OpenOffice.org where it pops up the menu). I have checked all my hardware and input systems. No kepyresses. X.org generates them. Try running Xev, the X event monitor (from an xterm, and redirect output to a logfile). It should pop up a new window. Any X event on that window will be logged. Mouse over the edge and wait for the grab bug to occur. Check the logfile and see what causes the grab event. |
| NoDough Nov 18, 2008 9:32 AM EDT |
Also, it's not unusual for a computer to become confused about the state of the keys (i.e. the computer sees a key-down event, but misses the key-up event and therefore believes that the key is being held down.) If that's the case it can be corrected by pressing and releasing the offending key. Of course, not knowing which key is the offending key means pressing and releasing several keys. Hope this helps. |
| techiem2 Nov 18, 2008 9:41 AM EDT |
Well, OpenOffice and everything else is working perfectly normally except for the resize thing, so it doesn't appear to be a stuck key (I don't have a key bound to that anyway). I ran xev and resized the window a bit. Here's the log: https://techiem2.no-ip.com/keys.log I have no idea what I'm looking for. :) |
| Sander_Marechal Nov 18, 2008 11:14 AM EDT |
I found one strange thing in your log file:Quoting:KeyPress event, serial 26, synthetic NO, window 0x2800001, root 0x328, subw 0x0, time 2901946047, (422,208), root:(424,228), state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False That's a keypress and keyrelease of the left shift. But they occur in the same nanosecond. Nobody can press and release a key that fast so I assume that you didn't actually press that key. Does the left shift trigger anything in your window manager (like resizing)? But the logfile is a bit dirty. Please try this: close all windows except your xterm that you use to start Xev with. Then make the bug happen by using as few keypresses and mouse movements as possible (making fvor the shortest logfile) . Remember exactly what you did (pressed key X to do blah, moused to Y to do foo, closed Xev by doing quux, etcetera). The post the logfile and your description of what you did. The logfile should show exactly every mouse movement, mouse click and keypress you made, and any other Xevents coming in. You should be on the lookout for anything Xev says you did but that you didn't do (like the left shift above). If you just want to test if it's ghost keypresses or not then it's easier. Run Xev (don't redirect the output) and leave it on the foreground for about 10 minutes or so. Make sure you can also see the xterm at the same time. Don't touch the mouse or keyboard. Xev should not report anything after starting up. If you see that every second or 30 seconds or whatever it is getting a keypress/release combo or something else, then that is likely to be your problem. |
| techiem2 Dec 02, 2008 8:26 PM EDT |
Well, the problem seems to have fixed itself somehow. I shut down to replace my wired keyboard and old wireless mouse with a new wireless set and now the problem is gone. So whether it was the reboot or the new peripherals...who knows... :) |
| ColonelPanik Dec 02, 2008 11:14 PM EDT |
Sander_Marechal I looked at what you quoted for a heck of a long time and even knowing
from your post what was the problem I still had trouble seeing it! I may be weird but I may not be weird enough for Linux? |
| Sander_Marechal Dec 03, 2008 2:47 AM EDT |
@Colonel: For each block, look at the second line, third statement. It says "time" with a value of 2901946047. So the keypress happened at 2901946047 and the keyrelease also happened at 2901946047. At *exactly* the same microsecond. That's physically impossible. The fastest I have ever been able to do is 40 microseconds or so between the keypress and keyrelease. Does that make more sense? Xev logs everything. It logs key presses, key releases, mouse movements and windows signals received from other programs. So, when you log a Xev session it is very useful to know what keys you pressen and what mouse movements and clicks you made. That makes it much easier to (a) look at the logfile and associate every block with a certain action and (b) look for events that were not caused by you but by a bug. |
| ColonelPanik Dec 03, 2008 1:38 PM EDT |
Thanks, I would have just replaced the keyboard and mouse first. The first "admin" I ever got to know said: "If I can't fix the problem in 5 minutes I will just reinstall!" That idea made me lazy. I need a cheat sheet: For problem xxx run this command For problem yyy run this command That would be a cheat sheet thicker than a networking book from Carla, eh? |
| Sander_Marechal Dec 03, 2008 2:49 PM EDT |
Bigger than a stack of encyclopedias I think. |
You cannot post until you login.