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

[Mark Kettenis]

> From: Adam Jackson <ajax at redhat.com>
> Date: Mon, 13 Dec 2010 12:52:53 -0500
> 
> From: Tiago Vignatti <tiago.vignatti at nokia.com>
> 
> The current SIGIO signal handler method, used at generation of input events,
> has a bunch of oddities. This patch introduces an alternative way using a
> thread, which is used to select()s all input device file descriptors.
> 
> A mutex was used to control the access of the mi queue by the main and input
> threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
> proper communication between them was also used.
> 
> [ajax: Build fixes for non-Xorg, per-OS defaults]
> Reviewed-by: Adam Jackson <ajax at redhat.com>
> Co-authored-by: Fernando Carrijo <fcarrijo at freedesktop.org>
> Signed-off-by: Tiago Vignatti <tiago.vignatti at nokia.com>

Setting my philisophical objections about making the X server
multi-threaded aside, I think there are still serious issues with this
diff.

First, the autoconf bits suggest that the input thread is optional.
But I can't see any evidence of that in the code changes.  I really
*don't* want a threaded X server on OpenBSD, but with this diff the X
server has to be linked against libpthread and will call
pthread_create(), which is really bad.  Also realize that pthreads
support was only made mandatory in the 2008 version of POSIX.  I don't
think it is a good idea to rely on it being available for another
couple of years or so.

Second, how does the silkenmouse behaviour actually work with this
diff?  The event queueing stuff is a bit of a maze, so I'm not sure
how it actually works, but either:

The mouse cursor is updated from the input thread.  In that case there
is either a lot of locking missing or the locking is done on such a
granular level that it effectively disables silkenmouse support.

or

The mouse cursor is update from the main thread, effectively disabling
the silkenmouse behaviour.