X11.app sometimes screws up pointer control

[trac.macosforge.org@…]

from rdar://5325024

===
10-Jul-2007 01:25 PM Marc Bejarano: X11.app seemingly randomly occasionally screws up pointer control such that it is stuck in the top left corner of the screen. if i <Cmd>-<tab> away to another application, pointer control resumes to normal. if i right-click while X11 has the pointer stuck, i get the apple menu and then can move the pointer normally. i can close all X11 client applications with keyboard shortcuts and the pointer still remains stuck, so this pretty obviously a bug in X11.app. quitting out of X11.app and restarting it fixes the problem until the next time it strikes.

18-Feb-2008 07:32 PM Marc Bejarano: this only seems to happen when i'm using the internal display of my macbook after X11 started up with my higher resolution external monitor being the only display.

this is still happening with "XQuartz 2.1.3 - (xorg-server 1.3.0-apple9)" from ​http://trac.macosforge.org/projects/xquartz

i am now upgrading to the 2.1.4 package.

is somebody looking at this?
===

[jeremyhu@…]

The radar number in the initial report is incorrect. It is: <rdar://problem/5325034>

Thanks for reporting this Marc. I hadn't looked at it much because your initial radar mentioned this was happening on Tiger's X11 and said nothing of Leopard, so it was near the bottom of my list since I haven't been able to reproduce it.

Now that you mention it happening on Leopard, would you mind providing some information on how to reproduce this?

[jeremyhu@…]

If an X application starts, is it displayed, or is X actually frozen?

If you can start an X application, can you run 'xev' from Terminal.app. Try moving the mouse with xev focused. Is there output in Terminal.app? What about mouse clicks?

do you get key presses? Can you cmd-tilde through X windows?

[jeremyhu@…]

Please try: http://xquartz.macosforge.org/downloads/Xquartz-1.3.0-apple16.bz2

You need to install the 2.2.0.1 package first: http://xquartz.macosforge.org/downloads/X11-2.2.0.1.pkg

I will close this bug as fixed if I don't hear back from you in a week or so on results.

Thanks =)

[jeremyhu@…]

Can you please install 2.2.0.1, then try Xquartz-1.4.0-apple2

​http://lists.macosforge.org/pipermail/xquartz-dev/2008-April/000591.html

[jeremyhu@…]

Moving the milestone to 2.3, since we're reworking input a bit there. Please try out 1.4.0-apple3 and let us know how it works for you.

[jeremyhu@…]

Can you try installing the 2.2.1_rc1 package and the 1.4.0-apple4 binary. We reworked most of the input stack, so this might have just fixed itself in 1.4

[jeremyhu@…]

This is probably gone with 2.3.0-rc1 ... closing due to lack of response

[mark@…]

argh - 2.2.2 and it just happened again. I haven't been hot-swapping my monitor as much lately, so I can't swear if it has been re-introduced or if it just happens less often.

Is there a pre-built binary of the current 2.3.0 rc? I'll install the new 2.2.3 and see how that goes.

[jeremyhu@…]

you can get the rcs from ​http://xqaurtz.macosforge.org/download

[jeremyhu@…]

you can get the rcs from http://xquartz.macosforge.org/downloads sorry for the typo

[jeremyhu@…]

No response... I believe this is fixed in 2.3.0... please test 2.3.0-rc7 and if you still see it reopen with info on how to reproduce it.

[macosforge.org@…]

i haven't seen this since upgrading to 2.3.0. thanks! (and sorry for the lack of responsiveness)

[mark@…]

bum - this seems to be back.

Working combination : 2.3.x (x < 2) on PPC PowerBook 12" Failing combination: 2.3.2 on Intel MacBook 13"

Again, after switching from external monitor only, to laptop screen only, cursor gets stuck at top left in X11.app

Interestingly the other screen switch issue ( #18 - strange white rectangles) has been successfully fixed in 2.3.2 - don't know if that's related.

I no longer seem to have permission to reopen ticket, but this should be re-opened...

[macosforge.org@…]

this happened to me again today with 2.3.3 on my 13" MacBook. i was running lid closed mode and the power brick was accidentally unplugged, causing the mac to go into sleep. it got confused and refused to run run in lid closed mode so i ran with the lid cracked for a bit and hit this.

jeremy: since we can't seem to find a simple repro for the issue, can you think of any data we can capture when we stumble across the issue?

[jeremyhu@…]

The problem is that doing anything locally essentially "fixes" the problem... I'd ssh in and maybe run 'DISPLAY=:# xinput test pointer'

You'll need to figure out the unix DISPLAY to put there by checking your processes. Example:

$ ps x | grep X ... 28417 ?? S 0:00.01 /usr/X11/bin/X :4 -dpi 96 ... ...

that would mean you should set DISPLAY to ":4":

$ DISPLAY=:4 xinput test pointer ... spew of pointer info from X11

There's also a way to query the OSX pointer as well. There's probably a sample application out there that does that already... if you can't find it, I'll try to code one up in the next couple months (sorry, this isn't near the top of the priority queue)

[jeremyhu@…]

So, someone has told me of a reproducible case for this, and I've solved part of the problem. I'm looking into the remaining issues and will hopefully have something to test in 2.5.0_beta2

[jeremyhu@…]

​http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?id=52456c602c3cdd7d5eac677889a18fad37dfb7ae

[mmmbugs@…]

Cc Me!