Not so much, but here are the news:
* For the final evaluation period on the Summer of Code, Daniel suggest me to start my [own X server tree](http://gitweb.freedesktop.org/?p=users/vignatti/xserver.git;a=summary). So I'm maintaining this one with the last bits of the X server input thread implementation and always trying to keep all the things up to date with the upstream tree. Everyone is very welcome to test it and report me the few - I expect - bugs. * The last new regarding the thread implementation is that we're unfortunately dealing with **critical sections** inside the X event queue (mi/mieq.c), so mutex is needed there (just to note: currently, mutex is only implemented using pthread (X11/Xthreads.h), so we also need implement something that is pthread-independent). Probably can exist other pieces of code that might be in an unpredictable way resulting some race conditions (didn't note anything strange yet!). * I finally managed how to implement the page fault notifier without any patch inside the kernel. The read_cr2() can be called directly since the page fault notifier runs with interrupts disabled. The implementation can be found [here](http://web.inf.ufpr.br/vignatti/code/page_fault_notifier.c).
It’s being a great adventure to lock the X input thread on the memory. I’m touching a lot of things that I’d never imagined before :)
To trace the pages that are faulting when I move the device pointer I’m using my own ultra mega super kernel’s page fault notifier. It’s very simple, but as the things are not always perfect, it needs a little patch in the kernel.
This week I tried to lock in the physical memory the Xorg’s input code using mlock(). To do this I traced the code minutely and locked all the text and data related to input. I didn’t get success. The mouse still lags when the system is paging (you might remember that with mlockall() all worked wonderful except that it eats much memory). So what might be happening is that something is not locked yet. To guarantee it I searched for a user-space tool that traces page fault. I only found the ’truss’ command on Solaris. Linux (my OS) doesn’t provide no one (‘strace’ don’t do this).
In the last week, I did some cool experiments to see the effects of the D state acting on the X server process when I start it with and without the input thread and always mlock’ing it.
This mail that I’ve sent to xorg mailing list tells the current state of my project.
cut here - Hi guys.
As you might noted here [1], my GSoC’s project is to do a separate mouse thread for the X server. Now, I’m really stucked with it and I need some good ideas from you before go to the next steps.
(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).
Certainly, my great new is that I was accepted as a student of X.Org Foundation sponsored by Google, on Summer of Code 2007. The project’s name is Moving the mouse handling code into a separate thread and in this link you can see what does this mean specifically.
