X input event generation thread
Tiago Vignatti
tiago.vignatti at nokia.com
Mon Aug 23 01:17:09 PDT 2010
Hi,
So here is the work I've revived, together with the great help of Fernando
Carrijo. It's about the "threadification" of the input event generation code:
http://cgit.freedesktop.org/~vignatti/xserver/log/?h=inputthread
git://anongit.freedesktop.org/~vignatti/xserver[inputthread]
configure.ac | 9 +
dix/main.c | 13 ++
hw/xfree86/common/xf86Events.c | 23 +++
include/dix-config.h.in | 3 +
include/opaque.h | 4 +
include/os.h | 18 ++
mi/mieq.c | 70 ++++-----
os/Makefile.am | 5 +
os/WaitFor.c | 5 +
os/connection.c | 8 +
os/inputthread.c | 368 ++++++++++++++++++++++++++++++++++++++++
11 files changed, 487 insertions(+), 39 deletions(-)
create mode 100644 os/inputthread.c
It's was relatively simple and straightforward to implement because the
current input signal handler runs exactly on the same path. I'd guess the most
challenging part was the hotplug of devices - we had to add a pipe to poke the
input thread when a device is (un)plugged and some other minor details were
implemented also trying to avoid races.
There's a lock in mi queue, so whenever the input thread is enqueueing, it
gets locked until all the work is done and the lock released so the main
thread can performs the dequeuing.
As I said in some other email, the input thread is not something
extraordinary which would bring some nice and visible performance
improvements. The main benefit the fact of it being an alternative for the
SIGIO handler mechanism, which has some problems (e.g. not being able to
malloc in signaling time or the cursor jumping, because SIGIO can't serve when
when the server is in D state). Besides, it will be opening space to a nice
cleaning up and eventually other threading works - one might want to thread
the rendering or maybe all x keyboard mapping part of the server. I don't
know. I envision some code organization creating some sort of /inputgeneration
directory separating everything related with it (ptrveloc.c, getevents.c, part
of xf86Events.c).
Right now we don't want to proceed deviating too much from the current xserver
code before you guys take a look on it and give the feedback. So lemme know
what do you think, please.
Cheers,
Tiago
More information about the xorg-devel
mailing list