GNOME.org
 

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


Ray:


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.


So, you are saying that it shouldn't support the "I don't care" option.
In other words, it should only start displays that are defined?


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


That seems reasonable.


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?


I was just saying that having separate configuration for the Xorg
command and "additional arguments" makes it easier, I think, for GDM
to add arguments it may need to add.  Though, if we redesign GDM so
that it doesn't need to add any special arguments, then you are right
this isn't needed.


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?


Xorg isn't started with a VT when you use Xnest/Xephyr, an attached
display with its own separate graphics card, if you use Xvfb, with
XDMCP, and probably a host of other situations.

On Solaris, VT is not yet supported, so VT isn't used at all
currently.  When it will be added, users will be able to enable it
or disable it.  It would be nice if GDM just autodetected if VT is
to be used or not, and added the argument if appropriate.


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


Agreed.  Though VT is a bit special.  GDM can easily autodetect whether
it should use VT or not.  Though, on Solaris the special $vt string
could just be translated to nothing if VT is not available.


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.


I think Halton and I must have misread your previous comments.  I just
wanted to make sure we were on the same page.

Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]