> From: Tiago Vignatti <tiago.vigna...@nokia.com> > Date: Tue, 28 Sep 2010 19:08:14 +0300 > > In two days I'm going for two weeks of vacation, so I'll AFC meanwhile. > Anyway, don't hesitate to review and comment please!
What problem does this solve again? If the input thread is going to run the same code as the SIGIO handlers do now, I fear this isn't going to fly. That code simply isn't thread-safe. The biggest issue the code that draws pointers. On multi-card setups, that will cause the input thread to switch the VGA arbiter to the device on which the pointer is visible. If that happens while the main server thread is drawing on a different device bad things will happen (typically things just lock up). Of course the same problem exists with SIGIO. After realizing how much code was run from the SIGIO signal handler, and the VGA arbiter issues related to that we decided to disable SIGIO on OpenBSD (encouraged by Alan C.'s statement that Solaris does the same). As far as I can tell, the only effect of this is that it disables the "silken mouse". Quite a few OpenBSD users tested that change, and all of them indicated that they noticed no difference whatsoever. So I'm wondering whether we shouldn't simply remove the SIGIO code and let the main event loop handle input events. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel