Defining seats

[David Zeuthen]

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()

 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

 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.

 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.

 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?

    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).

 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.

    (initially gdm would probably write out cheesy X.org configuration
     files; at least until X.org can start up in an embryonic state).

Thoughts?

> We need to be a little careful that we don't interfere with all the
> nice Xorg display hot plugging work.  So, how can we cleanly determine
> if a display should be part of a new seat or be attached to (or a
> clone of) an existing one?

Yeah. As Daniel pointed out that's probably not going to be a problem
just yet.

      David