Re: [gdm-list] Multi-seat and multi-display support design

[Chris Tyler <chris tylers info>]

On Mon, 2009-03-09 at 14:06 +0800, Halton Huo wrote:
> Hi gdm guys,
> 
> After Ray and Brian's help, I finish the design for Multi-seat and
> multi-display support in ConsoleKit and newGDM. Please visit the
> following link to review it.
> http://wiki.genunix.org/wiki/index.php/design_for_newgdm_consolekit_multiseat_multidisplay
> 
> I've already start coding based on this design, if anything wrong or
> something need more discussion, please feel free to write me an email.
> 
> Thanks,
> Halton.


Hi Halton,

This is good work. I'm looking at this from the point of view of
multiseat Linux systems on commodity PC hardware.

When working with local multiseat systems, it will be necessary to
specify the keyboard-pointer-video card-sound device combination (let's
say KPVS for short) for the new seat, specifying zero or more devices
for each. There will be at least two KPVS scenarios:

- static: the KPVS devices are known in advance and should always be
configured the same way.

- dynamic: extra hardware shows up, and it needs to be configured for an
extra seat, or assigned to an existing seat (as happens in the current
single-seat situation when you add a mouse or keyboard). The KPVS device
groupings need to be determined on-the-fly, probably with manual
intervention.

I'm probably missing something, but I don't see how KPVS information is
either configured into ConsoleKit or passed through ConsoleKit to the X
servers in the design linked above.

To me it sounds reasonable that DeviceKit would discover devices,
ConsoleKit would be responsible for grouping them into seats, and GDM
would handle display management, but it's also possible that DeviceKit
could assign properties that identify which seat a particular device
will belong to and ConsoleKit would simply aggregate devices with the
same property values into a seat.

Other notes:

* There is a need to handle multiple seats via multiple outputs from one
video card. This is typically done using layers -- for example, starting
an X server with multiple screens to manage the card, and then running
one Xephyr server on each screen with its own keyboard/pointer pair (via
evdev). Creating a generic framework for layered servers would support
this plus other layered scenarios (Xdmx-on-X, potentially some remote
display protocol situations where foundational software has to be
started before the X server).

* In the case of multiple local video cards, the second and subsequent
seats do not really have a VT assigned to them. 'IsConsole' seems to
identify seats with VT-switch capability, and I presume that this will
set the 'is-local' property for sessions on that seat (?). We need to
also identify local sessions which do not have VT capability, so that we
can do sane things at the PolicyKit and session levels -- granting
access to local hardware such as the CD-rom drive and usb flash drives
as well as permitting system shutdown, for example.

--
Chris
(writing from seat 0 of a 4-seat system)