Hey Tiago, What ever happened to your work to create a separate thread for input enqueue? I seem to recall you came across this issue during that work and had something working.
On May 18, 2011, at 08:24, Donald Kayser wrote: > 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. > > 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. > > 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. > > Regards, > Donald > > > On May 17, 2011, at 5:46 PM, Peter Hutterer wrote: > >> On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote: >>> Thanks for the quick response Jeremy. I was aware that I would miss >>> events during this test, but that was better than freezing. I have >>> not tried 1.10.x, but I will. We are trying to release a product >>> soon and changing to a new server and distribution is not >>> straightforward or the best move on our part. I might have to >>> consider any other solution for the short term. I am glad to hear >>> that we are not the only ones to have this problem and that it might >>> already be solved. I will look further at 1.10.x and go from there. >> >> I think this bug may still be there (possibly in a different incarnation) in >> 1.10. I haven't had any success reproducing it yet though. >> I know at least one of these got fixed in the last couple of server >> versions, but I can't seem to find the commit for it now. >> >> I suppose the quickest fix is to put OsBlockSignals() and OsReleaseSignals() >> around the part that must not be interrupted and rewrite it to be as short >> as possible. If you have a good description of the bug I'd love to hear it >> so we can look at a proper fix. >> >> Cheers, >> Peter >> >>> On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote: >>> >>>> Ignoring SIGIO will just result in dropped events. I seem to >>>> vaguely recall that this issue was addressed at some point in the >>>> past year or two since 1.7.x was active. Have you tried 1.10.x or >>>> master? >>>> >>>> On May 17, 2011, at 13:34, Donald Kayser wrote: >>>> >>>>> I am developing a system that include's the debian/squeeze >>>>> distribution of xorg-server, version 1.7.7. I have come across a >>>>> scenario where mouse movements on one screen and a touch on >>>>> another screen will cause the Xorg process to freeze in an >>>>> infinite loop in the function mieqProcessInputEvents(). I have >>>>> traced the problem down to a small window during which a call to >>>>> mieqProcessDeviceEvent can be interrupted by a signal and mess >>>>> up the miEventQueue.head and tail. It appears that in some place >>>>> in this stack a new event is being enqueued while the screen is >>>>> changing and device messages get swapped to the wrong screen and >>>>> back and forth. >>>>> >>>>> I put a global variable in mieqProcessDeviceEvent to indicate to >>>>> mieqEnqueue to ignore data until finished. This has solved the >>>>> problem as a test. I am now writing the code to ignore the SIGIO >>>>> signal during mieqProcessDeviceEvent and test this approach >>>>> also. >>>>> >>>>> Does anyone have a similar problem or advice? >>>>> >>>>> Thanks >>>>> Donald Kayser >>>>> xorg at kayser dot net >>>>> >>>>> >>>>> _______________________________________________ >>>>> [email protected]: X.Org support >>>>> Archives: http://lists.freedesktop.org/archives/xorg >>>>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >>>>> Your subscription address: [email protected] >>>>> >>>> >>>> _______________________________________________ >>>> [email protected]: X.Org support >>>> Archives: http://lists.freedesktop.org/archives/xorg >>>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >>>> Your subscription address: [email protected] >>>> >>> >>> _______________________________________________ >>> [email protected]: X.Org support >>> Archives: http://lists.freedesktop.org/archives/xorg >>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >>> Your subscription address: [email protected] >>> >> > _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
