GNOME Bugzilla – Bug 355190
[rfe] gdmgreeter continues to run during login process
Last modified: 2008-08-20 16:34:51 UTC
It would be nice if the gdm greeter process would continue to run after the user has successfully authenticated. The greeter could display a "starting, please wait" message and show a progress bar. When the desktop is ready, the greeter could be unshown. This reduces the number of transitions the user sees while logging in, which I generally believe to be a good thing. I've written a patch to implement this. It's very very rough right now because I want to solicit suggestions (release early, often). Some notes: 1: The gdmgreeter needs to be alerted when the session is finished starting. The greeter registers a property on the root window with the XID of its toplevel. Once the session is logged in, a killgreeter program (attached) is run to XKillClient the XID and remove the property from the root window. This code should probably live in gnome-session since gnome-session normally knows when to get rid of the normal login splash. This happens too soon, though -- for example, the panel is still loading its applets and nautilus may have set the background image but probably hasn't finished drawing the desktop yet. We also have to consider the case, though, of GDM being used to log into non-GNOME desktops. The most reasonable thing, I think is to add a vendor attribute to the .desktop file for the session saying "this session supports gdm splash screen". 2: Instead of calling XKillClient on the greeter I think it would be better to send a delete event. This would allow future greeter themes to do fancy things on removing the splash screen (some fadeout type effect or something). 3: More generally, it might be a good idea to have a richer interface between the greeter and the logging-in session. Having the session send the greeter approximate percentage notifications would allow the use of a real progress bar (currently I just have a pulsed one). This would be done through X events or a properties protocol. 4: I prevent the whacking of all X clients that used to occur on login. I do this because the only client that is attached is the greeter itself and whacking it sort of defeats the entire purpose. It might be possible to modify the code to whack only non-greeter processes but I'm not yet sure how I'd do this. It's worth noting that the greeter exports more than one XID so it's not enough to just compare the XID that we're about to kill off with the XID the greeter registered for itself via the root window property. 5: I haven't yet disabled the "Options" button because I am lazy. :) 6: All of this is implemented via a new greeter ctl: GDM_LOGGING_IN. I did a trivial modification to the non-fancy gdmlogin application to simply die when it gets this (by pretending that it's GDM_QUIT). This causes things to work pretty much exactly like they did before. 7: That's all, really.
Created attachment 72463 [details] [review] The patch to GDM (against CVS HEAD)
Created attachment 72464 [details] [review] The killgreeter program. *whack*
Created attachment 72465 [details] screenshot everyone likes screenshots, it seems :)
Does it make sense for GDM to be responsible for keeping track of how long the session needs to start? GDM is a display manager, and currently doesn't care much about the session it starts. Do we want to add dependencies, and interfaces to make this something GDM manages? Wouldn't it make more sense to implement such a progressbar in gnome-session directly? Remember not just GNOME uses GDM, so how will it work with other session managers aside from gnome-session? Will any problems happen if two window managers are running at the same time, since metacity will be started before the session is ready, and gdmlogin. It looks like you added a bunch of code to the greeter, but very little code to gdmlogin? Does this mean that this only works with gdmgreeter? Should probably work with both. If this sort of option does go into GDM, don't you think it should be configurable so that the sysadmin/distro can specify whether they want this feature to be turned on or not?
First point: gdm doesn't keep track of it. It merely keeps displaying the greeter since this is the only way of keeping a continuous view of the login screen while logging in. It's up to the session to manually alert gdm when to stop showing the splash. (see points 1-3 from my original report). About not working with non-GNOME desktops: I've already implemented code that only does this if X-GNOME-GDMSplash=true is set in the session.desktop file. Second point: The window manager of gdmgreeter is killed off before the session is started so there is no chance of a conflict with metacity (see the added gdm_wm_shutdown function). As for gdmlogin I just cause it to die immediately when logging in (exactly as before -- see point 6 in my original report) The distro can configure it by including or excluding the X-GNOME-GDMSplash=true line in the session.desktop files. For the sysadmin, an option could be added to the "Login Screen" administration dialog -- "Show splash screen while logging in for desktops which support it" or something.
I don't see X-GNOME-GDMSplash referenced in the patch. I think being able to configure such a feature in the session desktop file would be sufficient, or perhaps the session should advertise it supports this feature in some way and GDM should only use it if it is clearly advertised. For example, perhaps gnome-session could be called with an argument --support-dm-splash or something to check. Also, I would only accept a patch that requires configuration (such as the "X-GNOME-GDMSplash" desktop extension) if it is properly documented in the docs/C/gdm.xml file. How will this work if the user upgrades to the new GDM code with this feature but doesn't upgrade gnome-session to the version which has the new feature. Probably should handle this sort of thing gracefully. Also, I think it is probably broken to add a new executable that gnome-session calls. Why not just make gnome-session expose a new X-Atom or perhaps send the process a HUP signal or something to let it know to exit? This seems better than further cluttering /usr/bin.
K. This code was seriously not proposed for inclusion in gdm. It's very work-in-progress. The X-GNOME-GDMSplash stuff I wrote on the train last night (after submitting the patch for the first time). The intention was for the killer program to be integrated into gnome session (point 1). It was only provided as proof of concept. I've already started looking into having a more advanced communication mechanism between the session and the login screen where gnome-session can send an approximate login progress so we can have a real percentage progress bar instead of just a pulsed one. I need to brush up on my Xproperties skillz a bit, though :) Expect to see more code in the coming days. New GDM with old gnome: It's up to gnome-session to ship a .desktop file for itself. If gnome-session supports the feature then it will ship a version of this file with the X-GNOME-GDMSplash attribute. If the attribute isn't there then we assume =false.
This seems reasonable. I think a more elegant approach than using killgreeter should be used. How does GDM know what session file to check. If the user is using a different session program (like KDE) and it supports the feature, how does it know which one to check? Probably would be good to make sure this works with any session that supports the feature, not just gnome-session.
Hey Ryan. Just a thought: for systems designed to use fast-user-switching it might make sense to keep the greeter running all the time - instead of the way the flexiserver works now. Seems like your work here may be a step in that direction.
Created attachment 72745 [details] [review] updated patch this is the new patch it implements the following features above the last one: 1) the X-GNOME-GDMSplash attribute 2) the login session can now send a progress integer (0..0xffff) to the greeter to paint a real progress bar and can send progress 0x10000 to ask the greeter to exit. this enables some fancy fadeout effects on the part of the greeter in the future without changes to the protocol. i don't know how to disable the options button. please help :)
Created attachment 72746 [details] [review] helper program to send the progress to the greeter this is a little commandline utility to send the progress to the greeter. this code would live (most probably) in gnome-session and send periodic updates while logging in and then send 0x10000 at the end to cause the greeter to exit.
Can you please explain what you mean by the fast user switching stuff? As in, keep the greeter present inside the user session (just hide it) and then present it to the user when fast user switching is selected instead of starting a new X server right away? If so, it would make sense to add a method for doing this (ie: the signaling of when to show/hide) to the xproperties protocol that I've been slowly building up...
I guess I am not quite clear why people think it is a good idea for the greeter to keep running as a process. I'm not sure why this is necessary. The GDM daemon is already running in the background and there is the forked daemon process which is forked for each display running a greeter. Is there any real advantage to adding yet another GDM process running in the background? Wouldn't it make more sense for one of the existing running processes to manage progress bar stuff if progress bar stuff is needed? Why not add a new gdm-flexiserver --command option that tells GDM to display zenity with the specific %. Such a command should require Xauth like some of the existing gdmflexiserver commands, so that people can't make a progress bar appear on other people's displays. Doesn't this make more sense? It seems it would be pretty easy to implement. I wouldn't want this sort of feature on by default. It should be configurable and off by default. Also I will not accept any patch that isn't documented properly in docs/C/gdm.xml
The greeter doesn't continue running with the session. Once login is complete, the greeter dies off. If there are other ideas for fast user switching that involve the greeter still running past the login process then those are certainly not part of this patch.
Brian and I were discussing what to show when the proress bar is happening. One issue we uncovered is that we have no idea what exactly consistutes the background and what is the foreground in the current xml file. Thus the XML file should have a defined background section. Thus gdm would only show the stuff in the background section during the progress bar section.
Further to the above comment. Brian and I talked about doing the background on a different gnomecanvas level to the UI elements above it, allowing bits to be ripped down without pulling down the entire canvas.
Note that supporting background images after the GUI is dismissed is already discussed in bugzilla bug #322056. I'll update that bug to mention these comments, and we can continue discussion about that bug there. Let's just discuss the "extending the logout GUI until the session is ready" as a part of this bug. Regarding this bug, some additional thoughts.... 1) I think the command to cause GDM to stop displaying the login should be managed by a gdmflexiserver --command option. This would be better than adding a new script to pass this info along. This isn't hard. Plenty of examples. Refer to GDM_SUP_QUERY_LOGOUT_ACTION in daemon/gdm.[ch] for reference. You could use the same notify mechanism to pass the info to the GUI programs as exists in your current patch. 2) I'm not sure when it makes sense for GDM to start displaying the progress bar. Could be before PostLogin, before PreSession, or after the PreSession script is done. Since end users can customize the PostLogin and PreSession script, it is hard to predict how long they will take to run. But, still, the progress bar could be udpated after each step. After PreSession, GDM should expect that the session program started will tell it to update the progress bar 3) Perhaps the GUI should have a timeout feature so that if it seems the session isn't returning progress update info, that the progress bar starts going back and forth. Once it gets info, it could go back to normal progress. 4) I still think that the X-GNOME-GDMSplash is a bit of a hack. We are basically not turning on this feature by default and expecting distros to know to use this feature to turn it on. This is a bit ugly. Wouldn't it make more sense to just expose a gdmflexiserver --command option and if GDM receives this while waiting for the session to start, then it would pop up the progress bar dialog and gnome-session could make further calls to update the status of the progress bar. Would you be willing to work with the gnome-session maintainer to add such a feature there? Note that gnome-session already uses the gdmflexiser -command interface to query logout actions to know if it should display the shutdown/reboot options. Refer to gnome-session/gdm-logout-action.[ch] in the gnome-session source code. Since it already interfaces with GDM, I'd suspect the maintainer would be agreeable. gnome-session code should be written to ensure that if running with an old GDM that it doesn't break if GDM responds with an error like "I don't know that command" when gnome-session sends it.
1) the gdmflexiserver command communicates, as far as i know, with the main gdm daemon and not with the greeter or even the per-session slave. this would involve a lot of indirection and some intelligence on the part of the main daemon in deciding where to route the message. my original idea was actually to use an approach similar to this (i look at the code in the panel) but i decided against it. 2) as long as the gdm screen is not torn down between the time the user successfully authenticates and the time gdm decides to start displaying the progress bar i'm ok. it wouldn't hurt to hold off on the progress bar for a split second. 3) i think, actually, if the session isn't sending updates for a few seconds that the login screen should be torn down because it seems that the session doesn't support the progress notification protocol (or that something else has gone wrong). to show a progress bar sometimes that randomly turns to pulsed mode then goes back to a progress bar seems to be a bit evil. 4) gnome-session should integrate the sort of communication mechanism i have now, i think (for the reasons i state in point 1). it's clear in any case that this sort of thing doesn't belong in its own specialised binary program and that i'll definitely have to work with the gnome-session maintainer. i'm of course willing to do this. i'm quite ill right now and have some school stuff to deal with. just writing back to let you know that i haven't forgotten about this one. cheers :)
I'm not the gnome-session maintainer, but I'm planning to rewrite it... I added a few notes about splash screen plans to http://live.gnome.org/SessionManagement. Note that I'm planning to fix the lack of useful icons in the current splash. Addressing themability in some way would also be good, although it seems like just bug 322056 plus a tiny bit of themability in gnome-session would handle that. As for icons vs progress bar: the way startup works now (in a default session) is that gnome-settings-daemon, metacity, gnome-panel, and nautilus are each launched in sequence, with gnome-session waiting for each one to register itself before launching the next one, and then after that, all remaining apps are launched all at once, without waiting. gnome-session knows how big that last group is, but it really has no idea how much time it will take to start them up relative to the earlier stuff, since it's parallel rather than serial. (And you don't want to start them up serially because that would slow down login A LOT, and you don't want to start the earlier stuff up in parallel, because then you'd end up with lots of flashing and resizing.) So it's going to be hard to pick percentage values that will make the progress bar update smoothly.
Also, another problem with making GDM manage the progress bar is that this means that the progress bar will only work properly when using GDM as the display manager. It might be good to come up with a solution that is separate from the display manager for the progress bar, so that it works the same regardless of which display manager is being used?
I think in any case the program would have to be fairly tightly integrated with GDM in order to maintain the look of GDM while still logging in...
My concern with having a seperate program is two fold: extra code and visual flicker. Plus, GDM is written for GNOME. The only other project that really cares about it is XFCE. If we tell what we are doing, those with strange setups can deal with it. Hacking around a bug for 1% is insane.
I think my earlier suggestion that the session desktop file installed to /usr/share/xsessions be extended to indicate that the session will notify GDM when to stop displaying the post-login screen. Or will the session just paint over whatever GDM has on the root window when it is ready? If there is conversation between GDM and the session to make this happen, it would be best if the specification were submitted to freedesktop.org so that non-GNOME sessions can follow the same conventions.
This is already how it is. The X-GNOME-GDMSplash is exactly this. If set, it is a contract between the session and gdm. The session says "I support this protocol and will send you updates and shut you down when done". I agree with your idea about standardisation. If I were to do this I'd probably want to remove references to "GDM" in the XAtoms that the protocol uses for communication. Do you have any idea how one goes through this process?
Right, but I don't think the patch is ready. Note the issues I bring up in comment #13. I don't think it should be necessary for the session to run a program to tell GDM to stop displaying the background. Instead we should use a gdmflexiserver command. Look in daemon/gdm.h and daemon/gdm.c. Note the GDM_SUP commands. It should be easy to see how to add one, and then add the processing to gdm.c so it kills its children on that display. Also, it seems that there has been some discussion that a progress bar is not realistic since gnome-session runs things in parallel (comment #19). So do we instead just want a throbber? Do we want people to be able to specify their own throbber image (perhaps an animaged GIF or something?). I think it is okay for the new code to always get called, and expect the session to pass along the "your done" message if the xsession file has the new X-GNOME-GDMSplash setting, but it would be better if we had some way to test (e.g. call the program defined in the xsession Exec field with a known argument or something like "gnome-session --query-login-splash" and it will return "true" if it does, I support this feature. In this case, we wouldn't need the X-GNOME-GDMSplash at all. This would require a minor patch to gnome-session to add such an argument, but would probably work better if someone installs a new GDM onto a system with an old gnome-session, etc. If we don't do this sort of handshaking, we should probably check in configure to see if gnome-session is a new enough version to support the feature and only add the X-GNOME-GDMSplash setting if it is. However we decide the GDM/session handshaking should work, it should be proposed as a spec to freedesktop, and their comments may affect the way we implement. Send an email with a writeup of your specification to the xdg list (info here http://lists.freedesktop.org/mailman/listinfo/
Also, I think it would be neat if we enhanced the gdmgreeter XML to specify which tags are, in fact, the "background" image so that after authentication gdmgreeter could remove any canvas layers that are not marked as background. This way the "background" image could be defined in the XML rather than as a separate image, etc. Refer to bug #322056 (comment #11) for more details about this. Might be nice to do this along with doing this code, since they are very related.
Re: freedesktop, you should also investigate what (if anything) KDE does in this space before proposing anything, as you're likely to be flamed if they already have a perfectly good solution for this (which I think they do) and you propose something incompatible with it.
Brian: I talked with Corey about this on IRC. There are all sorts of neat things we can do. One example is scripting fade effects from the login screen to the "logging in" screen and then another fade from the "logging in" screen to the user being able to see their desktop. Taking advantage of composite for this stuff = win. (imagine, for example, the logging in screen fades to reveal your desktop) This is something that artists need to get ideas about and then demand the tools to implement (which we then provide them with).
Note that the idea of using a "background" property to specify what parts of the theme should remain after authentication has been implemented in GDM 2.19. Refer to bug #322056. So this should make implementing this sort of idea a bit easier. In that bug I make the following comment, so I'll also mention it here since I think it might be a nice approach. 1) It would be better to create some new interface with gnome-session where GDM could ask the session program (e.g. gnome-session or kde session) "do you support this feature" (perhaps by calling gnome-session with a special argument that returns true or false). If so, then GDM would display longer and gnome-session would tell GDM when to quit. Then GDM could display some sort of throbber or something in the interim. 2) If we did the above, it might be interesting if the background could be somewhat "animated". This could easily be done by supporting additional properties for items with the background property specified. Like perhaps "background-display-time=5" and "background-delay-time=5" (just suggestions off the top of my head). This way you could specify certain images that would show at certain points in time and for certain lengths in time. For example, this could be used to show little "commercial" or eye-candy images while the user waits for the session to start. In other words, after authentication GDM would show only the background images, show a throbber in the middle of the screen and the 4 corners could show various thumbnail sized images that appear and show for 1-2 seconds and then disappear. All specified by the theme file. It might also be cool to support some property like "background transition" so you could make the images fade in/out or other effects.