… here I’am :)

Being quick about my last months: finished my Master course, moving to Helsinki tomorrow (!), got my first real job. Yessh, three great steps in my crazy life and I’m very happy with it! Hope to stay closer with the desktop communities again ;)

One thing that I learned with open communities is when you send a proposal idea and no one replies. This seems to be odd at first but it isn’t. If you did something strange or wrong then at least someone will reply. OTOH if you did something that can be promiser and no one objects, then great! 99% that you did something interesting :)

Given that I’ll not work towards this cursor’s shortcut idea soon, I’m posting a mail that I recently sent to dri list and didn’t see much excitement there. So the bits are preserved here for future references.

Trying to put some order with all the multiseat documentation found on Web, today I updated the following:

Multiseat’s article, in X.Org Foundation wiki: http://wiki.x.org/wiki/Development/Documentation/Multiseat

Multiseat’s history, in Wikipedia: http://en.wikipedia.org/wiki/Multiseat#History

So if you are trying to setup or help in development, probably the foundation’s wiki has the most up to date and centralized references. Also, please, if you have more helpful information, don’t be afraid to update the wikis. Our future grandsons will be thankful  :)

This week our laboratory at university released the MDM utility to ease the process of installation and configuration of a multiseat box. The idea is that the end-user should not use some boring and hard howtos anymore to deploy it. Just installing a distro package must be enough now. Try it, use it, report the bugs and send the patches! :)

But I would like to call attention here because we’re still relying on the ugly Xephyr solution to build the multiseat on a simple PC machine (there are people selling this solution. Sigh). A lot of cool stuffs arriving in the linux graphics stack are lacking with this solution. So lets try trace the roadmap here that we can follow in the short/medium-term to build a good one solution:

Unfortunately that model which I described some weeks ago to put the input event delivery of the X server in a separate thread wouldn’t be an advantage. I precipitated myself thinking that it could be feasible. Sorry :(

I started to implement all this but it showed a very boring task to grab all the globals variables which both threads touch and to lock it. So I decided to stop going in this way. It’s hard to program thinking in parallel. It’s even harder to debug a program with severals flows. More, the tools don’t help you (if you have lucky, gdb will work).