[Xquartz-dev] keyboard/mouse focus issues

Pelle Johansson pelle at morth.org
Fri Oct 16 15:22:16 PDT 2009


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



More information about the Xquartz-dev mailing list