So we finally have a working code to do the arbitration of the VGA legacy instructions. The code is separated in three pieces: vgaarb module [0], which is the arbiter itself inside Linux; the libvgaaccess [1], a set of user space functions to access the arbiter; and xf86VGAarbiter [2], the implementation of the library inside Xorg.

Basically we wrapped all the functions of the Xorg which deals with VGA (those wrapped by the RAC and few others) using the lock/unlock functions of the libvgaaccess. Really ugly.

I used a part of the money that I earned on the SoC 2007 to buy a laptop to me. My university friends found a good price of a MacBook and we went to the shop in a total of 6 people (!) to buy this laptop trying to get some discount. It cost R$ 3400 (about USD 1800), a very cheap value to the Brazil standards.

Fine. My MacBook arrived one week ago. The shiny laptop is cool, but the OS really not. I tried to accustom myself for at least one week with that OS and I failed. The reason why is better explained by these guys below:

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.

The page fault notifier does (almost) all that I need to trace exactly which piece of code inside X is causing the page faults. So, as I said here, I compare the notifier’s output with the symbol table of X binary disassembled. Believe me, it works!

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).