newsuser at famdijkstra.org
Mon Sep 25 14:33:24 PDT 2006
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
> on the system bus. So if you have four seats in your system, you'd
> 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)
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
> 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
> 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.
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
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
> 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
Yes, I agree.
More information about the hal