Re: [gdm-list] gdmdynamic questions




Yan:

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


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