So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/ from X11 as the focused application. I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it. Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped. I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself. Thanks, Jeremy
Jeremy, I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues). -John On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change. In the mean time, can you atleast confirm two things for me? 1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way) 2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/ X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/ Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place) The resulting install *should* work if my assumption is correct that it's a server related issue Thanks, Jeremy On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com
wrote: So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/ from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
Hrm, I just noticed I can only reproduce it if I actually click an X11 window to make X11 active. If I click the dock item the windows work. As usual minimizing all the windows and restoring them resolves the issue. gitk is also affected btw (was just looking though the changes to see if I can spot something). -- Pelle Johansson 16 okt 2009 kl. 15.57 skrev Jeremy Huddleston:
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change.
In the mean time, can you atleast confirm two things for me?
1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way)
2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/ X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/ Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place)
The resulting install *should* work if my assumption is correct that it's a server related issue
Thanks, Jeremy
On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com
wrote: So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/ from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
Please remove me from the DList. Thank you. On 16 Oct 2009, at 19:16, Pelle Johansson wrote:
Hrm, I just noticed I can only reproduce it if I actually click an X11 window to make X11 active. If I click the dock item the windows work. As usual minimizing all the windows and restoring them resolves the issue. gitk is also affected btw (was just looking though the changes to see if I can spot something). -- Pelle Johansson
16 okt 2009 kl. 15.57 skrev Jeremy Huddleston:
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change.
In the mean time, can you atleast confirm two things for me?
1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way)
2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/ X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/ Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place)
The resulting install *should* work if my assumption is correct that it's a server related issue
Thanks, Jeremy
On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com
wrote: So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/ from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
johan stalpaert johan.stalpaert@pandora.be
Remove yourself the same way you signed up. See the link at the bottom. On Oct 16, 2009, at 10:59, johan stalpaert wrote:
Please remove me from the DList. Thank you.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
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. --Jeremy On Oct 16, 2009, at 10:16, Pelle Johansson wrote:
Hrm, I just noticed I can only reproduce it if I actually click an X11 window to make X11 active. If I click the dock item the windows work. As usual minimizing all the windows and restoring them resolves the issue. gitk is also affected btw (was just looking though the changes to see if I can spot something). -- Pelle Johansson
16 okt 2009 kl. 15.57 skrev Jeremy Huddleston:
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change.
In the mean time, can you atleast confirm two things for me?
1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way)
2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/ X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/ Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place)
The resulting install *should* work if my assumption is correct that it's a server related issue
Thanks, Jeremy
On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com
wrote: So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/ from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
No, not yet, but I'll make sure to try that. I haven't actually downloaded alpha3 yet, I'm running the server tip from Oct 13 right now... This made me remember when I first saw this issue. It was just before alpha1 was released when I was trying to build the 1.6 server anyway... I thought then that I messed it up somehow, that's why I didn't bring it up myself. One strange thing I noticed now while testing is that the events are delivered when I minimize the window, so they have to be queued up somewhere, but stuck, and then when the window is minimized they finally get unstuck. They are all sent to the window minimized last. This is easily reproducable if you have the issue: start two xev get the server stuck type a key into one of the windows change front window using the window menu type another key make sure the window you want to minimize first is the active one minimize using the window menu. You should see all the KeyPress and KeyRelease events delivered to the window minimized last, can someone reproduce this? -- Pelle Johansson 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.
--Jeremy
On Oct 16, 2009, at 10:16, Pelle Johansson wrote:
Hrm, I just noticed I can only reproduce it if I actually click an X11 window to make X11 active. If I click the dock item the windows work. As usual minimizing all the windows and restoring them resolves the issue. gitk is also affected btw (was just looking though the changes to see if I can spot something). -- Pelle Johansson
16 okt 2009 kl. 15.57 skrev Jeremy Huddleston:
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change.
In the mean time, can you atleast confirm two things for me?
1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way)
2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/ X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/ Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place)
The resulting install *should* work if my assumption is correct that it's a server related issue
Thanks, Jeremy
On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com
wrote: So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
_______________________________________________ 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
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
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
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
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
Yeah, sorry I wasn't more clear. It's at the second backtrace below that dev->deviceGrab.sync.other is written to which in turn causes FreezeThaw to freeze the events (CheckGrabForSyncs calls ComputeFreezes at the end). Where it's supposed to be cleared I don't know. I'll see if I have time to get a -O0 server compiled this weekend, obviously otherMode can't really be 0 there it has to be an optimization thing, and there's some inlined frames missing. But I'm pretty full booked... -- Pelle Johansson 17 okt 2009 kl. 01.42 skrev 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 ()
Jeremy, sorry for the delay in my reply. I finished the test you asked for. On Fri, Oct 16, 2009 at 6:57 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
hrm... ok. Thanks for the info. I'll be building some versions of the server incrementally from what was released in alpha1 through what is in alpha3 and will let you know when they're available... hopefully with these we can atleast hone in on the problematic change.
In the mean time, can you atleast confirm two things for me?
1) Test my xkb hunch: Install alpha3 Nuke the /opt/X11/share/X11/xkb directory Does the problem go away? (note that the 1.7 server will fail to startup this way)
This did not help. The problem persists.
2) Ensure it is actually a server bug: Install alpha1. Backup its X11.bin cp /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin /tmp/X11.bin.alpha1 Install alpha3 Restore alpha1's X11.bin sudo cp /tmp/X11.bin.alpha1 /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin Nuke the /opt/X11/share/X11/xkb directory (important since alpha1's X11.bin fails keymapping if that directory is in place)
The resulting install *should* work if my assumption is correct that it's a server related issue
You are right, yes, this works. -John
Thanks, Jeremy
On Oct 16, 2009, at 01:29, John Koren wrote:
Jeremy,
I use rxvt and xterm and both lock up equally with alpha2 and alpha3 with or without X11.bin-1.7.0901. Unfortunately, I do not have time for debugging and thus I am just monitoring closely this issue. alpha1 is working adequately for me (with some strange but relatively minor issues).
-John
On Thu, Oct 15, 2009 at 10:46 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
So, I've been trying for an hour or so, and I can't seem to reproduce this bug where mouse/keyboard events stop being sent when switching to/from X11 as the focused application.
I haven't heard much since alpha3, but I'm wondering if that's because people are too scared to try alpha3 after the problems mentioned with alpha2. I really want to squash this issue since it's the only problem I am aware of with this release, but I need some help to actually reproduce it.
Can someone please confirm whether or not this issue is still present in alpha3? Also, please confirm that it's there in the 1.7 server as well as the 1.6 server shipped.
I'll be building a bunch of "drop in" server binaries for testing if I can't actually reproduce this myself.
Thanks, Jeremy
_______________________________________________ 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
participants (4)
-
Jeremy Huddleston
-
johan stalpaert
-
John Koren
-
Pelle Johansson