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

[Halton Huo <Halton Huo Sun COM>]

Hi Chris,

Glad to hear your feedback, please see my comments in line.
> 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.
I'm trying to get what options should be added to X command if we want
to specify KPVS. From Xorg(1), I got:

device       Xorg option               xorg.conf      
-----------------------------------------------------
keyboard     -keyboard keyboard-name  InputDevice section called  
                                      keyboard-name as the core pointer
pointer      -pointer  pointer-name   InputDevice section called  
                                      pointer-name as the core pointer 
video card   -screen   screen-name    Screen section called screen-name
sound device N/A

I do not find the corresponding option for 'sound device', any hint?

Without changing current design, the 'Arguments' value in displays.conf
can be used achieve this configuration. There could be a better way to
do that is adding KPVS key-value pair in seat configuration files.

> 
> - 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 think you're talking about HAL or DeviceKit thing for ConsoleKit.

I'm not sure when xorg.conf would be updated if extra device shows up.
Suppose HAL or DeviceKit can do that. I'd like to adding KPVS key-value
pair in seat configuration files and run-time seat properties. In this
way, the new-added device can be determined whether is part of existing
seat or not. If not, a new seat might be added. If yes, I do not know
what's next?

> 
> 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.
Solaris only have HAL now, DeviceKit is not available yet. Anyway, I
think we can left the device discovering thing for now.

> 
> 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).
Suppose there are multiple Screen sections defined in xorg.conf as
following:

xorg.conf
---------
[...]
Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
EndSection
Section "Screen"
        Identifier "Screen1"
        Device     "Card0"
        Monitor    "Monitor1"
EndSection
[...]

And there has displays.conf 

displays.conf
---------
[Display Nest]
Command=/usr/bin/Xephyr
Arguments=
UseAuth=false
Priority=0

Then we should have two seat configuration files like following:

02-monitor0.seat
---------
[Seat Entry]
SeatNumber=2
Description=
DisplayType=Nest
Keyborad=Keyboard0
Pointer=Mouse0
Screen=Screen0
Sound=
[Display ]
IsConsole=true
TtyDevice=

03-monitor1.seat
---------
[Seat Entry] 
SeatNumber=2
Description=
DisplayType=Nest
Keyborad=Keyboard0
Pointer=Mouse0
Screen=Screen1
Sound=
[Display ]
IsConsole=true
TtyDevice=

> 
> * In the case of multiple local video cards, the second and subsequent
> seats do not really have a VT assigned to them.
Why the second video card can not be assigned a VT?

>  'IsConsole' seems to identify seats with VT-switch capability,
VT implement on Solaris and Linux are little different. Solaris VT can
be turn off, while Linux VT is always on. That's why we need "IsConsole"
to define the "TtyDevice" value case by case.

>  and I presume that this will
> set the 'is-local' property for sessions on that seat (?).
No it is not true. 'is-local' property is set FALSE only start a XMDCP
display. Otherwise, it is set to TRUE. When 'is-local' is set to FALSE,
the "TtyDevice" is force to '/dev/dtremote'.

So 'is-local' and 'IsConsole' used to the determine the value of
'TtyDevice'. The logic is like following:

if (display->is_local == FALSE)
    // a remote (XDMCP) display
    tty_device = "/dev/dtremote";
else if (display->is_console == FALSE)
    // a local seat but not on console
    tty_device = "/dev/dtlocal";
else if (check_vt_avail() == FALSE)
    //on the console and VT is not available
    tty_device="/dev/console";
else
   // on the console and VT is available
   if (tty_device == NULL)
       tty_device = get_next_available_vt ();

>  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.
I'm not familiar with PolicyKit, do you mean let ConsoleKit tell whether
session is on console or not?

Cheers,
Halton.