Mouse/focus problem in 2.6.0 beta2
I've been running beta2 for the last couple of weeks, and have now several times run into a weird lockup condition that I have not seen in 2.5.3 or earlier releases. The system gets into a state where it doesn't seem to want to deliver mouse/pointer events to any X11 applications --- the most response I get to a click is a quick double beep, and sometimes not even that. Keyboard events are still delivered fine. Switching input focus to another window is a bit tricky, because you can't do it via pointer, but command-digit works. AFAICT the only way to get out of the problem is to quit and restart X11. Unfortunately I cannot give a reproducible way to cause the problem. I think it has generally happened when I am returning focus to X11 from another Mac application, usually Safari --- I have a Safari window in front of several X11 windows, click the yellow button to minimize Safari, click on some X11 window to start working there, and suddenly things are all pear-shaped. But it doesn't happen every time or even often, so there's probably some additional trigger condition required. Or maybe there's some sort of timing-dependent race condition? It only seems to happen when I do this fast without thinking, so I'm not 100% positive I didn't mis-click somewhere I didn't intend to, but in any case a lockup isn't expected. Anybody else seeing this? regards, tom lane
What is the output of 'xinput test pointer' during this time? Does it seem reasonable? Can you try keeping 'xeyes' running ... that might provide some visual clues. On Dec 3, 2010, at 08:16, Tom Lane wrote:
I've been running beta2 for the last couple of weeks, and have now several times run into a weird lockup condition that I have not seen in 2.5.3 or earlier releases. The system gets into a state where it doesn't seem to want to deliver mouse/pointer events to any X11 applications --- the most response I get to a click is a quick double beep, and sometimes not even that. Keyboard events are still delivered fine. Switching input focus to another window is a bit tricky, because you can't do it via pointer, but command-digit works. AFAICT the only way to get out of the problem is to quit and restart X11.
Unfortunately I cannot give a reproducible way to cause the problem. I think it has generally happened when I am returning focus to X11 from another Mac application, usually Safari --- I have a Safari window in front of several X11 windows, click the yellow button to minimize Safari, click on some X11 window to start working there, and suddenly things are all pear-shaped. But it doesn't happen every time or even often, so there's probably some additional trigger condition required. Or maybe there's some sort of timing-dependent race condition? It only seems to happen when I do this fast without thinking, so I'm not 100% positive I didn't mis-click somewhere I didn't intend to, but in any case a lockup isn't expected.
Anybody else seeing this?
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
What is the output of 'xinput test pointer' during this time? Does it seem reasonable?
Can you try keeping 'xeyes' running ... that might provide some visual clues.
Okay, it's happened again, and here's what I've been able to find out: 1. xeyes and 'xinput test pointer' seem to react the same as usual. The problem is that focus doesn't transfer from one window to another, other than by selecting a different window via the Window menu or the command-digit equivalent. I note also that the dismiss/minimize/maximize window title-bar buttons don't react: the ones on the active window have the right colors, but they don't light up with the usual x/-/+ marks when the cursor is over them. 2. I tried hiding and re-exposing X11 (choose Hide X11 from menu, then click on X11's dock icon to expose). I've found in the past that that can un-wedge X11 when it gets wedged. The behavior for this case is even more interesting: things indeed un-wedge, and all is well as far as moving focus around, *until the first mouse click*. Then it's wedged again in the no-focus-transfer behavior. The window that has focus still receives click and keyboard events, but I can't transfer focus, and window title-bar buttons are dead again. Another hide/show cycle gets me back to transferring focus normally, until I next click somewhere, and then it's wedged again. I've gone through the cycle several times now while composing this message. (I should probably mention somewhere along here that my idea of "normal" is focus-follows-mouse. But it'd be just as broken from the perspective of a click-to-focus user, since clicking in another window doesn't transfer focus either.) 3. One other new tidbit is that this time it happened *without* a focus transfer from Safari. I did have a Safari window open behind X11, but I'd just been working in a couple of X11 windows before it froze. I still don't have any idea of how to reproduce this state, but at least we can knock off the theory that it has something to do with that. Any other ideas on how to gather info? regards, tom lane
On Dec 3, 2010, at 08:16, Tom Lane wrote:
I've been running beta2 for the last couple of weeks, and have now several times run into a weird lockup condition that I have not seen in 2.5.3 or earlier releases. The system gets into a state where it doesn't seem to want to deliver mouse/pointer events to any X11 applications --- the most response I get to a click is a quick double beep, and sometimes not even that. Keyboard events are still delivered fine. Switching input focus to another window is a bit tricky, because you can't do it via pointer, but command-digit works. AFAICT the only way to get out of the problem is to quit and restart X11.
Unfortunately I cannot give a reproducible way to cause the problem. I think it has generally happened when I am returning focus to X11 from another Mac application, usually Safari --- I have a Safari window in front of several X11 windows, click the yellow button to minimize Safari, click on some X11 window to start working there, and suddenly things are all pear-shaped. But it doesn't happen every time or even often, so there's probably some additional trigger condition required. Or maybe there's some sort of timing-dependent race condition? It only seems to happen when I do this fast without thinking, so I'm not 100% positive I didn't mis-click somewhere I didn't intend to, but in any case a lockup isn't expected.
Anybody else seeing this?
regards, tom lane
Just to rule out FFM, can you try running without FFM for a while and see if it reproduces? Secondly, by "react the same as usual", do you mean you see clicks and movements at correct locations? If so, that means that Xi is behaving correctly, but the Xevents might not be. Try adding xev and seeing if that output is as expected. I recall a similar issue that we had sometime during this past year where windows would freeze upon using cmd-`. That was caused by quartz-wm grabbing the keyboard and not ungrabbing it. Can you try killing quartz-wm and restarting it when this happens? In order to do this, you'll need to change your xinit to allow for it: mkdir ~/.xinitrc.d echo <<EOF > ~/.xinitrc.d/99-debug.sh /opt/X11/bin/quartz-wm & exec /opt/X11/bin/xterm EOF You'll get an xterm window on launch which will need to stay open (or else X11 will quit)... you can use it for xev. Once you get in this state, open Terminal.app and run 'killall quartz-wm' then run '/opt/X11/bin/quartz-wm' (I'm using the full path just in case you have a problem with $PATH ... check that as well) On Dec 6, 2010, at 20:59, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
What is the output of 'xinput test pointer' during this time? Does it seem reasonable?
Can you try keeping 'xeyes' running ... that might provide some visual clues.
Okay, it's happened again, and here's what I've been able to find out:
1. xeyes and 'xinput test pointer' seem to react the same as usual. The problem is that focus doesn't transfer from one window to another, other than by selecting a different window via the Window menu or the command-digit equivalent. I note also that the dismiss/minimize/maximize window title-bar buttons don't react: the ones on the active window have the right colors, but they don't light up with the usual x/-/+ marks when the cursor is over them.
2. I tried hiding and re-exposing X11 (choose Hide X11 from menu, then click on X11's dock icon to expose). I've found in the past that that can un-wedge X11 when it gets wedged. The behavior for this case is even more interesting: things indeed un-wedge, and all is well as far as moving focus around, *until the first mouse click*. Then it's wedged again in the no-focus-transfer behavior. The window that has focus still receives click and keyboard events, but I can't transfer focus, and window title-bar buttons are dead again. Another hide/show cycle gets me back to transferring focus normally, until I next click somewhere, and then it's wedged again. I've gone through the cycle several times now while composing this message.
(I should probably mention somewhere along here that my idea of "normal" is focus-follows-mouse. But it'd be just as broken from the perspective of a click-to-focus user, since clicking in another window doesn't transfer focus either.)
3. One other new tidbit is that this time it happened *without* a focus transfer from Safari. I did have a Safari window open behind X11, but I'd just been working in a couple of X11 windows before it froze. I still don't have any idea of how to reproduce this state, but at least we can knock off the theory that it has something to do with that.
Any other ideas on how to gather info?
regards, tom lane
On Dec 3, 2010, at 08:16, Tom Lane wrote:
I've been running beta2 for the last couple of weeks, and have now several times run into a weird lockup condition that I have not seen in 2.5.3 or earlier releases. The system gets into a state where it doesn't seem to want to deliver mouse/pointer events to any X11 applications --- the most response I get to a click is a quick double beep, and sometimes not even that. Keyboard events are still delivered fine. Switching input focus to another window is a bit tricky, because you can't do it via pointer, but command-digit works. AFAICT the only way to get out of the problem is to quit and restart X11.
Unfortunately I cannot give a reproducible way to cause the problem. I think it has generally happened when I am returning focus to X11 from another Mac application, usually Safari --- I have a Safari window in front of several X11 windows, click the yellow button to minimize Safari, click on some X11 window to start working there, and suddenly things are all pear-shaped. But it doesn't happen every time or even often, so there's probably some additional trigger condition required. Or maybe there's some sort of timing-dependent race condition? It only seems to happen when I do this fast without thinking, so I'm not 100% positive I didn't mis-click somewhere I didn't intend to, but in any case a lockup isn't expected.
Anybody else seeing this?
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (2)
-
Jeremy Huddleston
-
Tom Lane