Archive for June, 2007

Moving the mouse handling code into a separate thread

June 16, 2007

(In a puny attempt to write my SoC project progress to my mentor, I
decided to expand it and share my thoughts with you)

Today, we have two methods to register the pointer devices on Xorg
server
: (1) under SIGIO and (2) put they fd on EnableDevices set.
There is also the silken mouse concept, which means updates fired during
sigio handler (in the case of hw cursor).

We always try to prioritize silken – i.e. when the device emits a move
event, it will be “painted” on the screen and the WaitFor loop still
continue sleeping on select() – But the problem with SIGIO is that it
can blocks if the main thread is wedged doing kernel stuff (like
paging). It can’t interrupt a program in D state.

So, the basically idea is to do a separate thread which takes care the
mouse handling code without using SIGIO. I did an approach and some
questions were raised up:

(1) With (silken/hw cursor) or without the input thread seems to be
equal in perfomance (tested with three video cards: ATI Rage XL, GeForce
FX 5500 and GeForce2 MX/MX 400). I’d tested with a gnome-session started
and ran ‘x11perf -putimagexy500’. The cursor never lag the mouse in both
situations. At least no performance regressions :) Fine.

(2) But I think that (1) is not the exactly problem which we’re trying
to solve. Daniel Stone said once to me that having a tiny footprint that
needs to be kept in memory, it wouldn’t need to wait to be paged into
the active set all the time. Here Daniel’s transcription: “Currently it
works _almost_ like this, but SIGIO is in the same process, with a very
large memory footprint. So if any part of the X server is waiting to be
paged in to memory, then you’ll be completely blocked on disk I/O. This
is the problem we have today: under heavy disk and memory loads, we end
up blocked on I/O. OTOH, the input thread won’t get paged out, because
its active set will be extremely small”. But how to keep this resident?
Is it inner to the thread?

(3) Another thing that is breaking my head is to not have such a
mechanism to do a real performance test. How to know if the thread has
advanced or not the overall performance? Maybe using the ‘time’ tool?
Maybe something with xtest? I don’t know.

(4) So far I’m not facing any problem concerning the thread safety.
Yesterday, on the IRC, Mercury and Clee tell me to test the input
thread on SMP machines to really do it parallelized. I haven’t done it
yet. Some another tips here?

The input thread (using clone syscall) is on my Linux machine. The patch
applies with the last git evdev and xserver. You can see it here:

http://web.inf.ufpr.br/vignatti/tmp/xorg-input-thread.diff

I’ll really appreciate comments.

multiseat input hotplug

June 2, 2007

This week I spent a good time trying to understand the new input hotplug of devices on X and liked a lot. With this new subsystem the multiseat’s life will becomes easier. I’ll briefly explain here to you.

Before the hotplug sweetness, to add a new mouse/keyboad on X was only possibly on initialization time. Both of Xorg drivers, “evdev” and “mouse”, made a hack to try initializations “on the run”. This all was a mess and difficult a lot the configuration of the multiseats. But this world has changed.

Now what people are doing is starting the X server without any input device configured. The X server provides an API which listen all that happen on HAL. The HAL is notified when some device is plugged/unplugged and, trough an D-Bus external application it exchange messages with X. This all give to us a commodity to plug devices in a security and free way.

So well. An other problem with the kdrive (i.e. Xephyr, the X server used on nowadays multiseat) infrastructure is that it still not exists an interface that take care the hotplug. And it was exactly what I did on these last days. I implemented it and sent to the X people my patch waiting for a review.

Therefore, soon I’ll post some scripts showing how to use this new wonderful subsystem.