Defining seats

[William Jon McCann]

Hey David,

Sorry for the really long delay :)  Much of this has been in git for a
while now...

On 7/17/07, David Zeuthen <david at fubar.dk> wrote:
>
> Hi,
>
> On Tue, 2007-07-10 at 13:36 -0400, William Jon McCann wrote:
> > Hi,
> >
> > I'm getting to the point in the GDM rewrite [1] where need to query
> > something for what seats are available on the system.  In the old gdm
> > this was all hardwired in a config file.  I don't think this is what
> > we want.
> >
> > David and I talked about this a while back and thought that perhaps
> > gdm should just query
> > HAL for this info and then create seat objects in ConsoleKit.  This
> > was before the PolicyKit redesign.  What do we think?
>
> Yeah, I was trying out some different ideas. Originally my plan was that
> PolicyKit would enumerate what devices belong where but that got
> complicated fast. I think a much simpler solution would be that
>
>  1. For each seat, ConsoleKit provides an OS-specific mapping to
>     what devices belong to that seat. Perhaps just a simple D-Bus
>     method call on the org.ConsoleKit.Seat interface
>
>     array{String type, String id} GetDevices()

Yeah sounds good.

http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob_plain;f=src/ck-seat.xml

>  2. This would stem from reading a configuration file in /etc. It could
>     be as simple as this
>
>     [Seat Main Terminal]
>     # 1st ATI graphics card
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:01.0
>     # 1st sound card
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:10.0
>     # 3rd port of main USB Hub
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-3
>
>     [Seat Secondary Terminal]
>     # 2nd ATI graphics card
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:02.0
>     # 2nd sound card
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:20.0
>     # 2nd port of main USB Hub
>     Device=linux-sysfs:/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2

Right.  I tried a few different things and I converged on an approach
that separated the configuration files for each seat and put them in
/etc/ConsoleKit/seats.d/.  Having each seat be its own .desktop-like
file simplifies the change monitoring and management a bit.  However,
in .desktop-like files keys cannot be repeated within a group so the
Device key will contain a list.  So it would look something like:
http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;hb=HEAD;f=data/00-primary.seat

For now, I'm installing this file so that we get the same behavior we
had when we explicitly created the first seat in the code.

I haven't added any file monitoring yet.  One possibly tricky thing to
handle is what to do when a seat configuration is removed when it has
an active session on it.

>  3. The CK Manager object would emit a SeatDeviceConfigurationChanged()
>     signal when something changes. E.g. the CK daemon would watch the
>     configuration for changes using inotify or similar.

Yeah, still todo.  In addition we have Seat::DeviceAdded and
Seat::DeviceRemoved.

>  4. For Qt/GTK+ Seat configuration programs ConsoleKit could,
>     eventually, offer a D-Bus API on the CK Manager object to manipulate
>     the configuration file. I think we need to support both such an
>     API and also a configuration file format. Said Qt/GTK+ programs
>     would probably use HAL to figure out what OS-specific paths to feed
>     into it.

So, I guess the system installer (eg. anaconda etc) would by default
populate the first seat with devices?

>  5. HAL would use this and would be able to use it efficiently. We would
>     keep the mapping from CK configuration in-memory and use that to tag
>     the hal device objects with a property strlist info.seats, for
>     example, that describes what seats a device belong to:
>
>      - if info.seats is empty it means the device isn't tied to any
>        specific seat. We would allow any session to use the device
>
>      - a device may belong to more than one seat; hence why we need
>        a strlist.
>
>      - the children of a device object would inherit info.seats from
>        it's parent device object. Or should that be explicitly defined
>        in the information from CK?

Good question.  I'm not really sure yet.  However, if we expect that
CK will be queried for a list of devices per seat then it may be best
to indicate somehow whether it means only that device or that device
plus all children.  In the later case, the caller would then have to
expand that device into a tree by calling into HAL.

Maybe if the device is prefixed with a "+" or something... dunno.

>     HAL would use this information when deciding whether to allow a
>     caller to call methods on a device object and also for ACL
>     management. It would also just work on the CK signal
>     SeatDeviceConfigurationChanged() - we would just run through
>     all device objects, adjust info.seats and apply policy as
>     required (e.g. add/remove ACL's).

Yes.

>  6. gdm would get the information from HAL. E.g. it would look for
>     all video cards somehow (initially just look for all PCI devices
>     with class 0x03 but need refinement for e.g. USB video cards)
>     and also look for input devices. Then it would get all seats from
>     CK. And then it would start up X servers for each seat where
>     a video card / input device combo is exclusive for that seat.

Not really hooked up yet but:
http://svn.gnome.org/viewcvs/gdm2/branches/mccann-gobject/daemon/gdm-local-display-factory.c?view=markup

queries HAL for video cards.  Though we probably need info.seat before
we can use them.

Once we have that we can export Seat.AddSession() to the bus for gdm to use.

Jon