SystemD/Udev Multi-Seat Support For X.Org

[Nobu]

No, you see a working system getting replaced with something that is in development and unnecessary for most use cases, unless you are willing to argue that web servers and render nodes need to be instant on devices, of course.

Hmm, sounds like every software/program out there that intends to replace some other software/program. Oh, you meant unstable/untested. Well, I'm sure they'll test it before pushing it on the masses; it is Xorg we're talking about, after all.

(...you shouldn't be using bleeding-edge Xorg releases in a production environment anyway)

[pingufunkybeat]

No, you see a working system getting replaced with something that is in development and unnecessary for most use cases, unless you are willing to argue that web servers and render nodes need to be instant on devices, of course.

This fixes a LONG standing bug preventing multiple users from using the computer at the same time. For a multi-user system like Unix, this is rather important.

Why are you running X on servers and render nodes anyway?

[daniels]

If I understand correctly, this will FINALLY fix the problem with disappearing peripherals when using multiseat.

For those who do not use multiseat, the problem is that the new InputClass method of adding peripherals is incompatible with multiseat setups. So is hotplugging, which makes ALL X servers listen to ALL peripherals at the same time, breaking multiseat. You have to use InputDevice and explicitly disable hotplugging in order for multiseat to work. If you unplug the mouse or keyboard, your X session becomes deaf, and only a logout will fix it.

So if you accidentally lose the connection to one of your mice or keyboards (this happens quite often when there is some fluctuation on the USB bus, such as when plugging in a USB stick or a camera), you must log out. This happens at least once a day with my cheap mouse, and once a week for one of the three other peripherals.

So this is great news, which should fix MAJOR breakage.

While this patchset is definitely really useful, you can still use InputClasses to have working multiseat setups with hotplug. Instead of an InputDevice section with hotplug disabled, just change it to an InputClass section which matches the exact same device your InputDevice would use. Job done.

I first implemented multiseat for Ubuntu in 2004, and I believe it still works just as well to this day. This just improves it.

[pingufunkybeat]

While this patchset is definitely really useful, you can still use InputClasses to have working multiseat setups with hotplug. Instead of an InputDevice section with hotplug disabled, just change it to an InputClass section which matches the exact same device your InputDevice would use. Job done.

Obviously you know X better than I do, but are you sure?

I know that you can define an InputClass to be specific enough to match a particular input device. The problem was that I could not find an option which ties an InputClass to a particular seat.

Specifically, ServerLayout can refer to a specific InputDevice, but not to a specific InputClass, or at least I haven't found a way to do it, which is why I gave up. I've just checked with "man xorg.conf" with xserver 1.10.3

If you can tell me how it's supposed to work, I'd be really really happy!

[yotambien]

Multiseat rocks! The single coolest, most amazing thing I've ever made Linux do.

Hey, this really sounds very cool. I haven't followed multiseat development at all, and after reading some bits here and there I'm left with some practical questions:

- Do I need a videocard per seat?
- Is it easy to get running? Like, is this already in a state where I install something through my package manager and be done?
- What happens to 3D acceleration in a multiseat configuration?

We are two at home, both adicted to the internets (so we spend a lot of time in front of our respective computers). Right now we have a Vista desktop plus two laptops (Vista + linux), and I'm thinking in getting myself another desktop. Would you say it makes sense to set up a multiseat linux system on the existing desktop instead of going for another one? I'm thinking that it'd have to run Windows on a virtual machine and handle whatever it is I may be doing in linux. Would this push things too much for a rather basic dual core CPU? Also, I imagine the wiring of peripherals may get a bit messy if I wanted the systems to be in different rooms...

[pingufunkybeat]

Hey, this really sounds very cool. I haven't followed multiseat development at all, and after reading some bits here and there I'm left with some practical questions:

- Do I need a videocard per seat?

That's the cleanest, easiest, and more reliable solution.

There are options with nested X servers (Xnest or Xephyr) and the like, but you lose some stuff (3d acceleration). agdf did some work to make two X servers run on a single radeon, but those patches are out of date now.

One card per seat is what pretty much everyone uses. I got an extra PCI HD4350 for a silly amount of money -- even that's an overkill for casual browsing.

MAKE SURE to use similar gfx cards, preferably running the same driver. It might work with other combinations (Nvidia + AMD, Intel + AMD, etc), but this is rare, and why risk it?

- Is it easy to get running? Like, is this already in a state where I install something through my package manager and be done?

You don't even need to install anything, just update some config files (most notably, kdmrc). Not sure if gdm works with multiseat now, I remember reading that they broke it.

It's not hard if you follow a tutorial, like this one: http://sadevil.org/blog/2010/04/04/multiseat-on-debian/

- What happens to 3D acceleration in a multiseat configuration?

With one card per user, nothing. It works as before.

We are two at home, both adicted to the internets (so we spend a lot of time in front of our respective computers).

This is our situation, and the solution is really good for both of us. In fact, we swap seats all the time, treat them as two computers, and everything works well.

I have a PhenomII quad core and 4GB ram, and that's plenty. A dual core should be enough for most situations. Of course, the other seat gets a bit sluggish if I issue "emerge -udjv @world", an hog all the memory, but that can be planned around

[yotambien]

Thanks, this is awesome! Will save me good money and space and make for an interesting little thing to do!

[pingufunkybeat]

Thanks, this is awesome! Will save me good money and space and make for an interesting little thing to do!

Not to mention electricity!

[daniels]

Obviously you know X better than I do, but are you sure?

I know that you can define an InputClass to be specific enough to match a particular input device. The problem was that I could not find an option which ties an InputClass to a particular seat.

Specifically, ServerLayout can refer to a specific InputDevice, but not to a specific InputClass, or at least I haven't found a way to do it, which is why I gave up. I've just checked with "man xorg.conf" with xserver 1.10.3

If you can tell me how it's supposed to work, I'd be really really happy!

Ah, I hadn't thought of the separate-layouts-in-one-file approach. It'll work if you use one config file per seat. If you file a bug on X.Org to add support for limiting InputClasses through ServerLayout, I'm sure someone will pick it up at some stage.

[pingufunkybeat]

Ah, I hadn't thought of the separate-layouts-in-one-file approach. It'll work if you use one config file per seat. If you file a bug on X.Org to add support for limiting InputClasses through ServerLayout, I'm sure someone will pick it up at some stage.

So if I split xorg.conf into two files, one per seat, the peripherals will be tied to the right seat magically?

I'll have to try that, thanks!