<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">diff of changes on my build that get around the issue. Basically, I now throw away events when in mieqEnqueue if the event is from and old device and NewCurrentSession() has been called from mieqProcessDeviceEvent(). The logs show that we throw away about two to three events whenever the mouse is moving from screen to screen. This is less of an issue for my purposes than the freeze. We will be testing this here to see if it causes any problems that we can detect.<div> </div><div><div>diff original/xorg-server-1.7.7/mi/mieq.c modified/xorg/server/xorg-server-1.7.7/mi/mieq.c 60a61,63 > static int miInMieqProcessDeviceEvent = 0; > static DeviceIntPtr miInMieqDevice = 0; > 158a162,168 > // return if event is from old device and in call to NewCurrentScreen() from mieqProcessDeviceEvent() > if ( miInMieqProcessDeviceEvent && ( pDev == miInMieqDevice ) ) > { > ErrorF("[mi] Screen changing, tossing event from old device \n"); > return; > } > 390a401,402 > miInMieqDevice = dev; > miInMieqProcessDeviceEvent = 1; 394a407 > miInMieqProcessDeviceEvent = 0; <div><div>On May 18, 2011, at 2:22 PM, Donald Kayser wrote:</div> <blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Here is a stack trace of an event that is now being ignored and I suspect is revealing why the signal approach didn't work and maybe will give you insight:<div> </div><div>0 mieqEnqueue (pDev=0x10462d80, e=0x101f78e8) at ../../mi/mieq.c:162 #1 0x100715dc in xf86PostMotionEventP (device=0x10462d80, is_absolute=<value optimized out>, first_valuator=<value optimized out>, num_valuators=<value optimized out>, valuators=<value optimized out>) at ../../../../hw/xfree86/common/xf86Xinput.c:982 #2 0x0f6b50f0 in ?? () from /usr/lib/xorg/modules/input/evdev_drv.so #3 0x0f6b54c4 in ?? () from /usr/lib/xorg/modules/input/evdev_drv.so #4 0x1006db08 in xf86SigioReadInput (fd=<value optimized out>, closure=<value optimized out>) at ../../../../hw/xfree86/common/xf86Events.c:313 #5 0x10135f28 in xf86SIGIO (sig=<value optimized out>) at ../../../../../hw/xfree86/os-support/linux/../shared/sigio.c:118 #6 <signal handler called> #7 0x0fb02ba0 in sigprocmask () from /lib/libc.so.6 #8 0x10135834 in xf86UnblockSIGIO (wasset=<value optimized out>) at ../../../../../hw/xfree86/os-support/linux/../shared/sigio.c:297 #9 0x1006fd78 in xf86WarpCursor (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>) at ../../../../hw/xfree86/common/xf86Cursor.c:476 #10 0x1005cec8 in miPointerSetCursorPosition (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>, generateEvent=1) at ../../mi/mipointer.c:239 #11 0x100ecdac in AnimCurSetCursorPosition (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>, generateEvent=<value optimized out>) at ../../render/animcur.c:266 #12 0x1001f738 in CheckPhysLimits (pDev=0x10462d80, cursor=<value optimized out>, generateEvents=1, confineToScreen=0, pScreen=0x10249b48) at ../../dix/events.c:756 #13 0x100acf60 in mieqProcessDeviceEvent (dev=0x10462d80, event=0x105091c0, screen=0x10249b48) at ../../mi/mieq.c:402 #14 0x100ad020 in mieqProcessInputEvents () at ../../mi/mieq.c:489 #15 0x1006dd54 in ProcessInputEvents () at ../../../../hw/xfree86/common/xf86Events.c:165 #16 0x10050d1c in Dispatch () at ../../dix/dispatch.c:371 #17 0x1001d0d4 in main (argc=5, argv=0xbffffdc4, envp=<value optimized out>) at ../../dix/main.c:283 <div><div>On May 18, 2011, at 2:13 PM, Donald Kayser wrote:</div> <blockquote type="cite"><div>More notes of interest. The use of OsBlockSignals() and OsReleaseSignals() does not solve the problem. I also attempted using sigaction() to set the handler of SIGIO to SIG_IGN and this does not solve the problem. The only kludge, hack that works is setting a static variable in mieq.c that I added to indicate that mieqProcessDeviceEvent is being called, and in mieqEnqueue I check the value of the static variable and toss events if true. I have narrowed the "protected" code to the part surrounding the call to NewCurrentScreen() in mieqProcessDeviceEvent() in the top half of the function. I have not yet tried the newer version of Xorg; this is the more painful step in terms of time to solve this problem. I would have to repeat an entire product test regression if this becomes the solution. Any more ideas are very welcome. Thanks, Donald On May 18, 2011, at 10:24 AM, Donald Kayser wrote: <blockquote type="cite">I'm glad to know I'm not alone on this one. I can reproduce it at will with this embedded application and target. FYI, I will give you some details of the system. It is an embedded controller with PPC processor. We are running Linux 2.6.26 PREEMPT, debian squeeze distribution, Xorg 1.7.7. I ported the 2.6.26 kernel to load on this target. The video is two embedded C&T69030 graphics chips; I re-wrote the xf86-video-chips driver to support 4 screens. We do not use Xinerama. Our application is QT based and we use fluxbox as a window manager. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">To reproduce the problem here involves running the embedded application. On one screen supported by one of the embedded chips is a window that is being dragged upon and is consuming large amounts of cpu time. Overlaying another screen on the second embedded video chip is a touchscreen. As our application gets to the state where it is consuming most of the cpu by dragging on the first screen and one touches the second screen, this bug re-appears 100% of the time, or nearly enough. I have not had the time or platform ready to test on non PPC platform, but that is not out of my realm since we do have target systems running Intel. I have downloaded the source for the Xorg server, built it, and have been debugging it to get to this point. I will provide detailed stack traces and will narrow it down as much as I can. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">As mentioned before, I have been able to work around it, but would like a better solution. I will use the OsxxxxSignals() calls to narrow down the exact time, but I suspect it is in the call of NewCurrentScreen within the mieqProcessDeviceEvent() function. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Regards, </blockquote><blockquote type="cite">Donald </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">On May 17, 2011, at 5:46 PM, Peter Hutterer wrote: </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks for the quick response Jeremy. I was aware that I would miss </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">events during this test, but that was better than freezing. I have </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">not tried 1.10.x, but I will. We are trying to release a product </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">soon and changing to a new server and distribution is not </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">straightforward or the best move on our part. I might have to </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">consider any other solution for the short term. I am glad to hear </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that we are not the only ones to have this problem and that it might </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">already be solved. I will look further at 1.10.x and go from there. </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think this bug may still be there (possibly in a different incarnation) in </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1.10. I haven't had any success reproducing it yet though. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I know at least one of these got fixed in the last couple of server </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">versions, but I can't seem to find the commit for it now. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I suppose the quickest fix is to put OsBlockSignals() and OsReleaseSignals() </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">around the part that must not be interrupted and rewrite it to be as short </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as possible. If you have a good description of the bug I'd love to hear it </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">so we can look at a proper fix. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers, </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Peter </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote: </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Ignoring SIGIO will just result in dropped events. I seem to </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">vaguely recall that this issue was addressed at some point in the </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">past year or two since 1.7.x was active. Have you tried 1.10.x or </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">master? </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On May 17, 2011, at 13:34, Donald Kayser wrote: </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am developing a system that include's the debian/squeeze </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">distribution of xorg-server, version 1.7.7. I have come across a </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scenario where mouse movements on one screen and a touch on </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">another screen will cause the Xorg process to freeze in an </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">infinite loop in the function mieqProcessInputEvents(). I have </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">traced the problem down to a small window during which a call to </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mieqProcessDeviceEvent can be interrupted by a signal and mess </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">up the miEventQueue.head and tail. It appears that in some place </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in this stack a new event is being enqueued while the screen is </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">changing and device messages get swapped to the wrong screen and </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">back and forth. </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I put a global variable in mieqProcessDeviceEvent to indicate to </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mieqEnqueue to ignore data until finished. This has solved the </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">problem as a test. I am now writing the code to ignore the SIGIO </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">signal during mieqProcessDeviceEvent and test this approach </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">also. </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Does anyone have a similar problem or advice? </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Donald Kayser </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">xorg at kayser dot net </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:jeremyhu@freedesktop.org">jeremyhu@freedesktop.org</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">_______________________________________________ </blockquote><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote><blockquote type="cite">Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </blockquote><blockquote type="cite"> </blockquote> _______________________________________________ <a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </div></blockquote></div> </div></div>_______________________________________________ <a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a></blockquote></div> </div></div></body></html>