[Xquartz-dev] Mouse/focus problem in 2.6.0 beta2

[Jeremy Huddleston]

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 at 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev