Re: [gdm-list] Patches for multi-seat and multi-display support

[Ray Strode <halfline gmail com>]

Hi,

>> I wouldn't allow ';' and ','.  I would just pick one (and I would pick
>> ';').
>> The only reason gkeyfile let's you pick, is because when the icon theme
>> spec
>> got written no one noticed that desktop files used ; instead of , so it
>> ended
>> up getting the wrong one (and when gkeyfile got written we wanted it to
>> work
>> for the icon theme files too)
>>
>> So if I want to configure my system to start two displays at boot up, with
>> any display number, I don't care, is it:
>>
>> DisplayNumbers=-1;-1;
>>
>> ?  That's a little clunky.
>
> Should we use a keyword instead of a number to indicate "I don't care"?
I think it should be

Displays=localdisplay1;localdisplay2;

where localdisplay1 and localdisplay2 are defined in separate display
type files.
>
>>> diff --git a/data/display-types.conf.in b/data/display-types.conf.in
>>> new file mode 100644
>>> index 0000000..4c4246d
>>> --- /dev/null
>>> +++ b/data/display-types.conf.in
>>> @@ -0,0 +1,27 @@
>>> +[Local]
>>> +Command= X11_DIR@/Xorg
>>> +Arguments=-br -verbose -nolisten tcp
>
> Since "-nolisten tcp" is added via GDM configuration, it might not
> make sense to add it in the configuration file unless the user really
> wants to override the configuration setting, for some reason, and always
> add the argument.
I don't think it makes sense in the new world of consolekit display
configuration for gdm to be adding command line arguments to the X
server anymore.

I don't think we want a giant security/DisallowTcp toggle.  Each
display type can decide whether it makes sense to allow tcp or not
(For instance, Local would probably disallow tcp connections by
default, and your Xvfb sunray stuff would probably allow tcp by
default).

>> Why is Command and Arguments two separate things?  I'd do this as
>>
>> Command= X11_DIR@/Xorg $display -br -verbose -nolisten tcp $vt
>>
>> Then $display and $vt would get substituted with whatever display is
>> specified in the seat display configuration.
>
> I think this could work either way.  I think the difficulty here is
> that some arguments get added on-the-fly, such as "-nolisten tcp'
> and the $display and $vt values.
>
> Specifying the arguments allows GDM to do its magic adding arguments
> that are needed, and allows the user to specify additional arguments
> that might be needed.  Perhaps a flag to enable a needed extension or
> something.
I'm not sure I follow? Isn't it g_shell_parse_argv() either way?

> With your suggestion above, how would GDM behave if you left out the
> "$vt" and the user obviously intends to start a VT display?  Should
> GDM add the argument anyway, or should it fail because you messed up
> the config file?
In Linux, Xorg is always started on a vt.  If you don't give a vt
argument then it chooses the next available vt.
Unless the seat config file explicitly gives a VT (via a
VirtualTerminal=8 line or whatever) in the seat config, then $vt
should expand to "".
I guess Xorg doesn't work that way on Solaris?

Either way, I don't think GDM should try to second guess the
configuration.  The config files could be broken in other ways and GDM
wouldn't be able to fix it
(Say a sysadmin wrote Xvbf instead of Xvfb for an X server).

>> If you did each entry as a separate file, like you did for seat
>> configuration,
>> this will be a lot more managable.  E.g.,
>
> In our first proposal, we suggested having these in separate files.
> But, in private discussion on March 4, 2009, you said the following:
>
>> Well, let me take a step back and say somethings that I think are
>> right:
>>
>> 1) A seat represents the monitor, keyboard, mice, and usb hub that the >
>>  user is sitting at.
>> 2) Usually there is one display (X server) per seat (although things
>>    get a little muddied when you think about fast user switching)
>> 3) There is one session at a time per display
>> 4) There are only a handful of display types (local X server, XDMCP X
>>    server, Xvfb X server for SunRay)
>> 5) There could be a large number of seats (and correspondingly a large
>> number of displays)
>>
>> Given 4 and 5, we should have two sets of definitions (not sure what
>> Jon's opinion is here).  One that defines the display types (basically
>> what canned X server command lines to run), and one that defines the
>> static seat configuration that uses those display types (basically X
>> servers to start at start up).
>>
>> So I could imagine having some displays types (forgive the contrived
>> syntax):
>>
>> {Local: command=/usr/bin/Xorg $display -br -verbose -auth $auth
>>  -nolisten tcp $vt},
>> {Remote Machine: command=/usr/bin/Xorg $display -br -verbose -auth
>> $auth -indirect $vt}
>> {Local VNC: command=/usr/bin/Xvnc $display -auth $auth -query
>> localhost}
>> {Headless: command=/usr/bin/Xvfb $display -auth $auth}
>>
>> and then a static configuration like:
>>
>> {Seat 1: type=Local}, {Seat 2: Remote Machine, vt=12}, {Seat 3: Local
>> VNC}, {Seat 4: Headless}, {Seat 5: Headless}, {Seat 6: Headless}
>>
>> Which would start a normal X server on the first available vt, a
>> special X server that brings up a chooser on vt12, a local VNC server
>> that allows remote clients to vnc in and login, and then 3 framebuffer
>> displays.
>>
>> You could think of the display type as a "class" and the static
>> configuration as "instances of the class".
>>
>> There could be other seats, too, that aren't statically configured,
>> but dynamically set up at runtime.  For instance, GDM sets up some
>> XDMCP displays.  Each time a user connects to GDM via XDMCP, a new
>> remote seat would get created dynamically to logically map to that
>> user's monitor, keyboard, and mouse.
>>
>> Now the question is how we represent that in config files.  I'd say
>> you could do the static configuration by dropping files in
>>
>> /etc/ConsoleKit/seats.d
>>
>> but then you still need a place to define display types.  Maybe,
>>
>> /etc/ConsoleKit/displays.d
>
> To me, it sounded like you were suggesting that the seats be defined in
> a single static configuration file.
Which part in the quoted text suggests that?  To me it seems like I said:

1) There are two distinct peices of information we need to store: seat
configuration and display types
2) How we represent those configurations should be by dropping a bunch
of files in seats.d and displays.d

I admittedly didn't go back and reread old discussions on this before
doing the consolekit review, but I don't see how what you quoted
contradicts anything I said in the review.

> However, I suggest that we drop this logic from this patch and address
> this later if it turns out to be something people really want.
Sounds good to me.

--Ray