Re: [gdm-list] gdmdynamic questions

[Brian Cameron <Brian Cameron Sun COM>]

Yan:

Note that one way you can get the behavior you want with GDM 2.20 would
be to simply create a per-display configuration file with the value
security/PamStack=gdm-autologin.  This assumes that the display you
want to autologin has a stable $DISPLAY value, but is a way you could
get autologin to work for a particular display without having to modify
the code.  This also assumes you have a gdm-autologin PAM module.  If
not, it is fairly easy to create a PAM module that simply returns TRUE
for all public interfaces to do the same thing.

Note the new GDM does not yet support PamStack configuration, or the
ability to specify configuration values per-display, so this approach
won't work with the new GDM without some further enhancements.

Brian


> > I've started working with the 2.20.8 codebase.  I guess there was a 
> > complete rewrite between 2.20 and 2.21....
> >
> > I'm trying to figure this out.  I've added a new parameter to the 
> > [server] handling code (basically cribbed your device= code) that 
> > simply prints out a test string.
> >
> > If I call gdm with
> >
> > [server]
> > 0=Standard
> > 1=Standard test=ABCDEF
> >
> > Then things work as I would expect - the string ABCDEF is printed on 
> > the terminal.
> >
> > But if I comment out server 1 and try it with gdmdynamic, the server 
> > fails to start.
> >
> > gdmdynamic -a "1=Standard test=ZYXWVU"
>
> The "test=foo" string is just an argument to #=Standard, and probably
> shouldn't be passed along via gdmdynamic.  Instead gdmdynamic should
> lookup the Standard entry and process any arguments associated with it
> when it gets the gdmdynamic request.
>
> If the config file already has test=ABCDEF then gdmdynamic should honor
> that.  Perhaps it just doesn't do that currently since there currently
> aren't any such [server] arguments that would affect gdmdynamic.  If we
> are adding new arguments that gdmdynamic needs to know about, there
> is likely code that needs to be written to make gdmdynamic smart enough
> to deal with that.
>
> ou can look at the code gdm/daemon/gdm-daemon-config.[ch] to see the
> code currently used for reading/parsing the config file for
> non-gdmdynamic displays, and for processing the [server] arguments.
> Currently I think it only supports "dev", which would likely be
> meaningless for a dynamic display.
>
> > gdmdynamic -r "1"
> >
> > then either nothing happens (X fails to start) or gdm crashes.
>
> If you have gdmdynamic configured properly (DynamixXServers=true in
> the config file), then I'd expect it to manage the display.  Though
> if it isn't working, the processing of the gdmdynamic -a argument might
> be not working properly.  The code might be assuming that
> "1=Standard test=ZYXWVU" means it is looking for a configuration section
> named [server-Standard test=ZYXWVU] or something, which would be wrong.
> Obviously the gdmdynamic parsing code may need some work.
>
> > gdmdynamic passes the string to the gdm daemon via gdmcomm_call_gdm.  
> > I can't find the other end of the connection.  Obviously pushing the 
> > 1=... string to gdm via gdmdynamic is different than pulling it from 
> > the config file  but where does the gdm daemon listen for and parse 
> > the connection?  Without a roadmap to the code it's pretty 
> > convoluted....  :-(
>
> GDM sends these messages to the daemon:
>
> GDM_SUP_ADD_DYNAMIC_DISPLAY
> GDM_SUP_REMOVE_DYNAMIC_DISPLAY
> GDM_SUP_RELEASE_DYNAMIC_DISPLAYS
> GDM_SUP_ATTACHED_SERVERS (for the -l option)
> GDM_SUP_SERVER_BUSY (just to make sure it doesn't flood the server)
>
> These are processed in daemon/gdm.c in the function
> gdm_handle_user_message.  As I say above, there might
> need to be some work to make display started via gdmdynamic as
> configurable as non-gdmdynamic displays (in terms of automatic login,
> for example).
>
> > Also, is the 2.20.X codebase in the process of being replaced by the 
> > rewritten code of 2.21+?  Ideally this would want a significant 
> > rewrite of the config file parser to allow gdmdynamic the full range 
> > of options available via the .conf file, but if the codebase is on its 
> > way out I would rather just hack something up than spend a huge amount 
> > of time rewriting the config file parser.
>
> Yes, GDM 2.21+ is replacing the older 2.20 codebase.  However, the new
> codebase doesn't support managing multiple displays at all.  So if you
> want to dig into fixing this in the new GDM rewrite, this will require
> much more infrastructure work.  In my other email, I pointed you towards
> the gdmdynamic patch for making gdmdynamic work with the new GDM, which
> you could use for managing all non-console displays via scripting rather
> than using the GDM configuration file to do so.   However, as I said in
> my other email, that patch is experimental and might require some work
> to get it to meet basic needs (aside from adding automatic login
> features you want).


--

Brian