On Wed, Oct 03, 2012 at 12:26:54PM +0800, Daniel Kurtz wrote: > On Wed, Oct 3, 2012 at 11:25 AM, Peter Hutterer > <[email protected]> wrote: > > > > On Fri, Sep 28, 2012 at 01:25:50AM -0700, Keith Packard wrote: > > > Peter Hutterer <[email protected]> writes: > > > > > > > Thanks, merged this into my tree. This should fix the remaining issues > > > > we're > > > > seeing with synaptics. > > > > > > Did you see my comments about this patch? I'm really not excited about > > > adding 12 more syscalls per WaitForSomething invocation. Seems like > > > there are two options to fix this 'correctly': > > > > > > 1) Have the synaptics driver modify the timer interval from either a > > > wakeup or block handler as appropriate. > > > > A quick git grep shows that timers are used in keybard, mouse, joystick, > > synaptics, and wacom, all of those are in the signal path. We could in > > theory fix up the lot, but it will take time. > > > > > 2) Provide a signal-safe timer value setting function in DIX. This > > > would set a global flag indicating that 'something' changed in the > > > timers. WaitForSomething could use this flag to check whether the > > > timers need fixing before computing the timeout value for select. > > > > > At the very least, the server should only be blocking SIGIO and not all > > > signals; that's half the syscalls... > > > > Both of these solutions seems to be more straightforward. Daniel? > > > Blocking only SIGIO is very straightforward. > The only reason I didn't do that is that the earlier patch used > OsBlockSignals(). > > Peter: Any reason you did that instead of xf86BlockSIGIO()?
At the time OsBlockSIGIO() didn't exist yet and calling xf86BlockSIGIO() from the DIX is a no-go. No reason it can't be changed now though to just block SIGIO. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
