Multiseat, Fast-user-Switching

[Tim Dijkstra]

Op Fri, 22 Sep 2006 00:23:07 -0400
schreef David Zeuthen <david at fubar.dk>:

> 
> Hi all, 
> 
> sorry for the lag,

Same here. I'm running out of time these days.

> On Tue, 2006-09-19 at 15:11 +0200, Tim Dijkstra wrote:
> > On Mon, 18 Sep 2006 21:46:28 +0200
> > Fabian Steiner <lists at fabis-site.net> wrote:
> 
> 
> One idea occurred to me at OLS while talking to ajax (of X.org fame)
> was the following. Assume each X.org server on the system claims the
> name
> 
>  org.x.Server.<DISPLAY>
> 
> on the system bus. So if you have four seats in your system, you'd
> have
> 
>  org.x.Server.0.0
>  org.x.Server.1.0
>  org.x.Server.2.0
>  org.x.Server.3.0
> 
> or something. A single object /org/x/Server is exported with the
> interface org.x.Server.Instance that implements one method
> 
>  IsPidConnected (IN int pid, OUT boolean isConnected)

Maybe also
  
  GetVirtualTerminal()

This can be cached.

> that simply returns TRUE if the given UNIX process id is connected to
> the X server. This is pretty straightforward to implement.
> 
> Now, we'd then have a very simple process claim the name
> 
>  org.x.Server
> 
> on the system bus too. That system bus service will export a single
> object /org/x/Server with the one interface org.x.Server that
> implements a single method call
> 
>  GetDisplayForName (IN string uniqueSystemBusName, OUT string display)
> 
> that returns the DISPLAY (e.g. 0.0, 1.0, ...) for a given unique name
> of the system message bus. 

That sounds sensible, it will however take some time to a) get it in X
b) get that X in distro's. But the patch in X wouldn't be to big. Also
we could for the time being make the GetDisplayForName-program do some
other hacks.

> 
> Right. Some random thought: One idea I've been toying with is a
> org.fd.ConsoleKit service on the system messages that provides a very
> simple, yet powerful, piece of information, namely

You like kits, don't you? ;)

>  - what seats are available
>    - async signals when seats are added / removed
>    - for each seat 
>      - what devices are available for the seat
>        - probably just expressed as HAL UDI's 
>          - same UDI can appear for multiple seats - allow seats 1-5 to
>            use CD-RW device A and seats 6-9 to use CD-RW device B
>          - typically just the HAL UDI of the videocard and a USB hub

I guess multi-seat configurations are pretty static. I mean, some
administrator will assign certain devices to a seat during setup, it
will not change that often.

>      - what sessions are on each seat
>        - async signals when sessions are started / stopped
>        - async signals session comes to foreground / background

This would mean lots of polling, grepping through proclist and other
hacks. Or it would mean patching all login-managers, getty, etc.
Doesn't sound like the way to go. Maybe I'm misunderstanding you...

I think we only need:

> plus some lookup methods like GetSessionIdForX11Display() to e.g. get
> a Session object from a DISPLAY variable.

and

  IsSessionActive(session)

which would return true when the session is on the the active VT (or
it's multi-seat equivalent). 
If we assume only X can have active sessions, we could also have a
	GetActiveSession()
In the x.org.server service you introduced above.
 
> Then when someone calls a method on HAL, we'd
> 
>  - determine DISPLAY of caller (via org.X.Server service)
>    (and we can cache this in HAL)
>  - determine Session of caller (via org.freedesktop.ConsoleKit)
>    (and we can cache this in HAL)
>  - compare to info.seat to determine device ownership
>  - see what privileges we need (ties in with PolicyKit, most actions
>    would probably be restricted to only active sessions, others might
>    be allowed even if you are an inactive session)
   - Which implies checking if the session is active.
> 
> Personally I think f-u-s is the most interesting
> case to get right

Me too.

> This all ties in very much with PolicyKit - right now we have a lame
> pam module to determine if a user is on the console. We can do much
> better. In fact it might make sense for the ConsoleKit bits to live in
> PolicyKit.

Yes, I agree.

grts Tim