[PATCH 1/2] xfree86: use a thread for the generation of input events

[Mark Kettenis]

> From: Adam Jackson <ajax at redhat.com>
> Date: Thu, 16 Dec 2010 10:32:21 -0500
> 
> On Wed, 2010-12-15 at 23:08 +0100, Mark Kettenis wrote:
> 
> > Yes, that is the additional locking that's necessary.  I'd say you'll
> > need a mutex that you lock in x86BlockSIGIO() and unlock in
> > xf86UnblockSIGIO() and lock/unlock around each event that you process
> > in the input thread.
> 
> It's more subtle than that.  BlockSIGIO is used to mean both "suppress
> input because I'm changing the input state", and "suppress signals
> because I don't want my usleep()s to wake up early".  So you really need
> as a first pass to change the callers to say what they mean, and the
> former case should be xf86BlockInput (which then happens to call
> BlockSIGIO for now, but turns into a mutex in the threading change).

BlockSIGIO is also used to "suppress silken mouse because I'm messing
with the graphics hardware state".  Of course "suppress input" has
"suppress silken mouse" as a side-effect, but it is something to keep
in mind as well.