Log in

No account? Create an account

July 2017
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

airlied [userpic]
two X servers one graphics card.

So sane multi-seat handling was something I wanted to make KMS do at some point and designed for but never quite implemented.

So in an attempt to maybe get help out people who are interesting in this I've gotten two seats on a single card working here to a demoable level.


contains a kernel patch + libdrm patch.

The kernel patch pretty much contains 3 pieces:

(a) ability to create "render" device nodes with an attached list of output resources it controls (crtcs/encoders/connectors).
(b) hardcoded render node setup for my X1900 - two parts - core drm creates 3 devices nodes, radeon driver assigns hardcoded
resources to the nodes - in this case render node 0 gets a crtc + DVI + encoders, and node 1 gets the other crtc/DVI/encoders, and
render node 2 gets no outputs.
(c) drm mapping fixups for multiple device nodes - this is something we should probably cleanup independently of this patch.

the libdrm patch just contains support to use an env var to pick the device path.

With this xorg.conf and the two startx wrappers I can run two X servers separately.

(a) define a kernel/user interface to set seats and nodes up. The DRM control node is there specifically for this purpose but I never got around to specifying this interface. It basically needs a few methods:
1. Create new render node with output configuration.
2. Remove render node.
These would have to rely on their being no users of the render or legacy device nodes in advance. The kernel would
also have to get the driver to validate the output configuration. The output configuration would be a list of IDs for crtcs/encoders/connectors.

(b) maybe add a drm device path to xorg.conf so each card section can specify one, would help get away from BusID also.

(c) make a sane userspace interface to use it all - I suspect you'd need something in gdm/ConsoleKit to configure this sort of
thing, you'd have to construct per-card multi-seat profiles with a list of the outputs and stuff you want on each seat etc.

At this point I'm just trying to flesh out my backlog of projects and figure out how long they will take to do properly, feel free if someone is interested in picking this up and running with it.


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?

Re: Hmm

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.

Question/Suggestion. Will this work with cgroups

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.

Re: Question/Suggestion. Will this work with cgroups

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.

Re: Question/Suggestion. Will this work with cgroups

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.

In practical terms...

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

Re: In practical terms...

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.

use with other drivers

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

Re: use with other drivers

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.