multiseat

[Adam Jackson]

On Thursday 28 July 2005 08:46, Jon Smirl wrote:
> On 7/28/05, Daniel Stone <daniel at fooishbar.org> wrote:
> > Input is hard.  How do you associate a particular input device to a
> > particular user?  Now imagine the world of USB, where you have to deal
> > with hotplug input devices.  Oh, and don't forget real users, who will
> > want to do audio, and plug in USB thumbdrives.  If you plug in a
> > thumbdrive with your GPG key on it, you don't want someone else to get
> > their grubby mitts on it.
>
> PAM will have console groups which include screen, keyboard, audio,
> mouse and USB ports. When you login to Linux you are assigned
> ownership of the devices in the console group. You own USB ports so
> things that are plugged into those ports automatically belong to you
> too.

Just don't add hubs, or reconfigure the topology between reboots, or change 
kernels.  Oh, and remember that the three leftmost ports on the first card 
are yours but the right port and the second card are Jimmy's (scale that out 
to about four seats and then just start beating yourself on the head with a 
pipe wrench to relieve the pain).

> > VGA routing is a bitch.  If you don't believe me, stick four utterly
> > random cards in one machine, start four X servers, and watch it quickly
> > collapse in a heap.
>
> Benh already has a working prototype of VGA arbitration for the
> kernel. It was discussed at Kernel Summit this year.

The arbitration idea is lovely but it assumes that the card gives a damn when 
you tell it not to decode the VGA space, and there are many video cards that 
will stick their fingers in their ears and go LA LA LA I CAN'T HEAR YOU when 
you try.  You could assert that those cards are broken, but that's sort of 
the point: hardware is broken and will actively defeat attempts to be used in 
a multiseat setup.

> > That and trying to deal with four separate heads when the VT system only
> > has the concept of one.  Anywhere from one to four heads can be present
> > on a four-user system, and you have to deal with that accordingly, and
> > DTRT with sharing VTs, and what to do when someone hits the console.
>
> This was discussed at Kernel Summit too. The solution is to give the
> VT system the boot since it is single user.

... which just defers the problem to userspace, which now has to cope with the 
kernel renumbering the USB busses across reboots and whatever else breaks 
between now and 2.6.next.

Multiseat X almost kinda sorta works.  Multiseat VTs is slightly more possible 
if you kick them out to userspace, but still a broken idea, because people 
expect the console to have a well-defined set of input devices all the time 
and the brain-damaged nature of USB makes that impossible to guarantee.

And yet when I say "just don't use VTs", people give me a look like I have a 
cat growing out of my neck.

> > It's a surprisingly non-trival problem space, trust me.
>
> Work has been going on this area for the last year.

You do know that about a third of the multiseat support in 7.0 is Daniel's 
code, right?  He knows what he's talking about here.  Oh, speaking of, you 
also know that 7.0 has multiseat support that works (as well as multiseat 
ever works) on stock 2.6 kernels?

Let's try less preaching to the choir, k?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050728/571a06eb/attachment.pgp>