This is very interesting work. I hope this work generates more interest because I have difficulty using multiple display devices on the same system right under KDE. (I'm aware this work may not be germane to my issues, but it's good to see people working the area nonetheless.) Thanks for the hard work.

Does it have full 3d accel on both seats?

Yes both heads should have full acceleration.

Very useful job, David. A lot of people would be happy to be able to make multiseat setup on one graphic cards without black magic. And you didn't mention 3D acceleration, are both seats capable of running OpenGL programs?

yes as commented above, both should be able for 3D, sharing the GPU between them.

Not sure you'll get great perf with it but it'll work fine for compiz most likely.

One of the biggest issues of running distributions inside a cgroup is lack of means to run X11.

You might be able to get help from people working on cgroups if this will integrate with what they are doing.

Final one is faking X11 server to think it has a display but is really only rendering to a surface to display.

don't think this will change anything in that area, not sure what stops X from running inside a cgroup though. We have Xvfb where X renders to a virtual framebuffer, though what to do with the surface after X is finished rendering to it is the problem, you still need to display it for it to be useful.

Xvfb is normally not that useful in side openvz and other container like tech ie cgroup.

Once you put a OS inside a container you don't want it seeing that the out side exists. So want the OS inside the container to be able to start up its X11 server as close to normal as able yet not know the other X11 server that is running out side the container exists. Then you don't want it interfering with the outside screen display either.

Now if inside a cgroup the X11 server in there could render to a surface that was assigned on it and the X11 server outside the container could say have this surface rendered here. That solves the graphical part of the containment problem. That still leaves the event feed issue.

Even being able to virtual terminals for containers independent to host virtual terminals so allowing OS in container to run more like a normal install would be useful.

This could also be used to extend items like vnc interfaces copying like virtualgl method. opencl to compress the stream from the buffer.

You said to be useful it has to be displayed. True. But nothing says it has to be displayed on the same card it was rendered on.

I don't know if this would make paravirtualisation of the Linux graphical stack simple as well. Basically a driver that passes a buffer through.

...does this mean that I can put two users using one computer at the same time if they have their own user accounts and own mouse/keyboard/monitor? If not, what's missing?

Yes if all the TODO items are done, myself and whot did it today using the startx scripts, some stuff may need fixes after that.

The main problem left with multi-seat is user-space configuration tools and integration into things like gdm.

no screenshots=bullshit

Thanks, man! This is some really interesting work!

As soon as I have some time I _will_ be testing your code! (I'm actually planning this for the middle of April, since I've been very busy and I have to use my spare time).

I can also make user-space configuration code.

first I'd like to say thanks and good job. As i understand it this is specifically working for the open source ati drivers. There is no chance this would work for using fglrx drivers? Thanks

any open source driver can in theory do this, but so far I've only hacked it up for radeon..

Closed source driver I've no idea about, since I've no source.