Well, FWICT, the problem stems from the device being marked as "frozen" and never getting "thawed" ... look at FreezeThaw in dix/events.c you might want to break in that function when frozen=TRUE (break FreezeThaw if frozen != 0). It's a small static function and might be inlined by gcc optimizations, so I'd recommend building the server with "-O0 - ggdb3" (which is good measure whenever using gdb any ways). On Oct 16, 2009, at 15:22, Pelle Johansson wrote:
No problem, I want it fixed as much as anyone. FWIW I've tracked it down (using watch points, of all things. nice to see them finally working) to this backtrace:
#0 0x00000001000dc731 in AddPassiveGrabToList () #1 0x00000001000d020c in ProcGrabButton (client=0x1007df330) at events.c:5176 #2 0x00000001000cbaf4 in Dispatch () #3 0x00000001000ddc41 in dix_main () #4 0x0000000100013f52 in server_thread () #5 0x00007fff86aeaf66 in _pthread_start () #6 0x00007fff86aeae19 in thread_start ()
The passive grab added there is never removed (until the window is unmapped), and it's the one making events queue up when the X server is switched to. The client calling Grab is always the same for the lifetime of the server, the wm maybe?
It is used here: #0 0x00000001000d74b4 in CheckGrabForSyncs (thisDev=<value temporarily unavailable, due to optimizations>, thisMode=<value temporarily unavailable, due to optimizations>, otherMode=0) at events.c:1474 #1 0x00000001000d4331 in CheckPassiveGrabsOnWindow (pWin=<value temporarily unavailable, due to optimizations>, device=0x1007e0a70, xE=0x114452bd0, count=1, store=0x11581cb90, scount=2) at events.c:3338 #2 0x00000001000d4711 in CheckDeviceGrabs (device=0x1007e0a70, xE=0x11581cb90, checkFirst=0, count=2) at events.c:3445 #3 0x0000000100081b2c in ProcessOtherEvent (xE=0x11581cb90, device=0x1007e0a70, count=2) at exevents.c:1059 #4 0x000000010009fed0 in ProcessPointerEvent () #5 0x00000001000fa0c4 in mieqProcessInputEvents () at mieq.c:476 #6 0x000000010000e965 in ProcessInputEvents () #7 0x00000001000cb70b in Dispatch () #8 0x00000001000ddc41 in dix_main () #9 0x0000000100013f52 in server_thread () #10 0x00007fff86aeaf66 in _pthread_start () #11 0x00007fff86aeae19 in thread_start ()
Giving up for today now, -- Pelle Johansson
16 okt 2009 kl. 23.32 skrev Jeremy Huddleston:
Hmm... I wonder if somehow the keyboard and mouse are getting dropped as master for some reason... I saw a problem like this earlier (like 5-6 months ago) and couldn't reproduce it, so I figured I was nuts.
I'll look into this. Thanks for the additional info. It seems like it's actually a 1.5 to 1.6 server regression.
I just wish I could actually trigger it. I've got multiple xevs open, xterms, clicking around to finder, back to X11... nothing... =/
--Jeremy
On Oct 16, 2009, at 14:05, Pelle Johansson wrote:
16 okt 2009 kl. 20.33 skrev Jeremy Huddleston:
Did you try nuking the xkb directory with the alpha3 shipped server or using the alpha1 server binary in alpha3? So many libs changed during alpha1 to alpha3 that I want to eliminate client- side issues.
I tried nuking the directory, no change. The other one is a bit to painful for me right now. But I've tested with gdb, the difference when it works or not (for keyboard events) is here:
mi/mieq.c:471: { /* process slave first, then master */ dev->public.processInputProc(event, dev, nevents);
if (master && dev->coreEvents) master->public.processInputProc(masterEvents-
event, master, nevents); }
The first (slave) call always goes to DeliverFocusedEvent. The master one also goes there while the server is not stuck, but when it is that call goes to EnqueueEvent. Does this tell you anything? -- Pelle Johansson _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev