multiseat

[Jon Smirl]

Greg, is USB numbering unstable across reboot, if so can we fix it? 

Is it possible to use USB port number like, 2-2.3:1.0, to stably
assign mouse0, mouse1, etc? Same for keyboards.

This is part of the console group problem I talked about earlier. The
base system really needs to support this so that we don't rebuild it
in each app.

On 7/30/05, Daniel Stone <daniels at fooishbar.org> wrote:
> On Sat, Jul 30, 2005 at 12:57:35AM -0400, Jon Smirl wrote:
> > On 7/29/05, Daniel Stone <daniels at fooishbar.org> wrote:
> > > On Thu, Jul 28, 2005 at 11:06:24AM -0400, Jon Smirl wrote:
> > > > Check out udev. It addresses your complaints about USB renumbering.
> > >
> > > No, it really does not, especially across reboots.  We found that the
> > > only way to actually preserve your devices was to have a /dev/multiseat
> > > directory controlled by a daemon which gets kicked by hotplug events,
> > > and then uses some hand-wavey heuristics to try to work out which mouse
> > > it is.
> >
> > The USB port numbers like 2-2.3:1.0 are consistent across reboots
> > unless you move the wires around. Does that work to assign the mouseX
> > dev node? Are there more specific problems? Maybe they can be fixed in
> > udev.
> 
> I don't udev keeps the mapping consistent, necessarily.  This is why we
> wrote our own userspace scripts and configuration files to keep policy.
> 
> > This is a good argument for the one hub per seat scheme. You would
> > track the hubs and then assign anything plugged into them to the user.
> > Since mice/keyboards are interchangeable you don't need to track the
> > via a serial number.
> 
> Most keyboards are USB hubs, which makes things a little more
> convenient, but as I said before, you do not get guaranteed numbering
> across reboots.
> 
> Multiseat is not trivial.  It does not work out of the box on a standard
> system.  It takes a lot of effort to get it working out of the box when
> you have a configurator that works out which keyboards and mice are
> where (via polling all the relevant event devices and saying 'now press
> some keys on keyboard three'), and you have your own policy helpers.
> With carefully selected cards.  Even then you get fun like everything
> works fine if you kick the primary card first and then the three ones
> that aren't decoding VGA, but fails when you don't do the primary card
> first.
> 
> It would be nice if we fixed all the drivers to not be so VGA-centric,
> and if udev kept numbering for the same devices vaguely consistent
> across reboots, etc, etc.  And it would all be useful work.  But it does
> not work out of the box, and won't any time soon.
> 


-- 
Jon Smirl
jonsmirl at gmail.com