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

Input events routed through another thread/process can have bad effects on latency because we can’t guarantee that it will get scheduled at the right moment. Although this is hard to see happening with the current X server threaded implementation, we must design something to avoid it. One way to improve the responsiveness is to give a high priority to the input thread and also adjust the CPU scheduling. (Note that this will not avoid problems related with page faults which usually happen in the X input flow.)

Given that GSoC ‘08 is getting close to the end, strategy number 2 showed more feasible to proceed my work. Strategy #3 would be a lot of fun but would imply a hell massive codification as well (also a little out of our scope). Unfortunately no-no for now.