[Xquartz-dev] keyboard/mouse focus issues

[Jeremy Huddleston]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5820 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20091016/1f8e7359/attachment.bin>