View Single Post
Old 08-06-06, 09:37 PM   #6
Registered User
Join Date: Aug 2005
Posts: 3
Default Re: pbuffer rendering in background X-session

Thanks, Thunderbird and Aaron.

I'd forgotten about possibility of using Mesa and that might be quite a good approach for developing the work. I would be really be trying eventually to exploit hardware acceleration if I can though. Using Mesa for now is something I'll definitely try.

I've experimented with the single X server / multiple X screens and this nearly does what I'm hoping for. I've allowed a gap between the screens ( and thereby locked the mouse to the first X screen so that the user is not really aware of the existence of the second X screen that is used for the renderer server.

The remaining problem is how to configure the system so that users can locally log on/off the machine without affecting the renderer.

If I write a normal daemon (that uses no GLX resources), I can start this, leave it running, and users logging on have no effect.

Would you be able to advise me on the best approach to writing a similar daemon, but one which does need GLX reources? This is a bit more general a question, but given the trend towards GPGPU programming, one that a number of people may have an interest in.

I've used graphical login:
id:5:initdefault: (in inittab)

From inspecting Xorg.0.log, it appears that upon a user closing a session and another user logging in, the X server is not restarted, but the NV-GLX module is reloaded (have I interpreted this correctly?)

If this is the case, would there be hooks that I could use to detect when the GLX module is about to become unavailable; and, similarly, to detect when it is again available? Or, with the present X architecture, do I have to leave myself permanently logged in, if I wish to have access to GLX computation?

Many thanks

greystock is offline   Reply With Quote