Multiseat, Fast-user-Switching

[Tim Dijkstra]

On Tue, 19 Sep 2006 16:54:56 +0200
Fabian Steiner <lists at fabis-site.net> wrote:

> > 5) Hal should know about connection DISPLAY <-> device.
> >    Maybe implemented through some fdi files?
> 
> So far, the common idea was to use an usb keyboard with an integrated
> hub and to associate that hub with the display. 

How did you try to 'associate hub with display'? I still have no idea
how this multi-seat thing works. How do the device files (/dev/*) on the
client end up on the server? Or how else can the X server access the usb
keyboard connected to the client?

However it works, I imagine that there must be some configuration on the
server that says, client at IP A, has display B and devices C, D and E.
This configuration can then also be used by hal.

> > With this information, we can have the following scenario:
> > a) user plugs in USB key
> > b) hal gets kernel event.
> > c) hal announces new device available on system bus.
> > e) g-v-m on $DISPLAY asks hal to mount the key
> > f) hal verifies that $DISPLAY of session-dbus is authorized for device
> > g) hal verifies that owner of session-dbus is on active VT
> > 
> > Here f) would be irrelevant for f-u-s and g) irrelevant for multi-seat.
> > On could also imagine that c) is changed so that hal only announces on
> > session-dbus' of which it knows they are authorized. You still would
> > need verification though.
> 
> This sounds quite interesting and it is probably the way how the whole
> thing should be handled. But again I would like to point out that we
> shouldn't depend on a particular desktop environment (e.g. I don't have
> g-v-m installed in KDE, but use the built-in feature to automount which
> is based on HAL and not on additional tools).

Sure, g-v-m was just an example. The essential part is that some request
comes in to hal through dbus, which we have grant or deny based on some
info. Steps a) through e) are IIRC how it goes know, steps f and g would
be new.

grts Tim