Jon/Others: Since things are still in the early stages of the GDM redesign, it probably makes sense to try and hammer down the requirements for gdmdynamic and Sun Ray a bit better. http://www.sun.com/software/sunray/index.jsp Note that Sun Ray Server Software (SRSS) is available for free to Linux users, and such users also depend on GDM for this to work: http://wwwcip.informatik.uni-erlangen.de/~simigern/sunray-debian/ In short, the way that Sun Ray works is that the Sun Ray server may have some displays attached directly and these are treated like normal displays by GDM. In other words DISPLAY :0 may be a monitor actually attached to the Sun Ray server machine. In addition, the Sun Ray network may have any given number of Sun Ray client devices attached to the same network as the server. The client devices let the server know that they are present over the network, and the server sets up the device so that it appears as a normal X display to the server machine, even though the device is actually located over the network. So, the Sun Ray server might treat the first one it discovers as display :100, the next as :101, etc. Upon discovery, the Sun Ray server software tells the display manager to start managing this display. When it is time to stop managing a display (like if it gets unplugged), the Sun Ray server likewise tells the display manager to stop managing this display. The gdmdynamic program is used for managing and unmanaging these displays. This functionality might be of general use outside of a Sun Ray context. I am not aware of anybody using this for other purposes, but there may be other situations where it might be of value to be able to control when various displays are managed or unmanaged. I could imagine that other multi-user terminal-server type environments might find some use in this sort of functionality if they wanted to support the ability to hotplug displays like Sun Ray does. Because testing this with an actual Sun Ray network is cumbersome, I wanted to share with you the attached tarball which contains scripts that allow you to simulate a Sun Ray environment using Xvfb. This is also useful for stress-testing GDM in a multi-user environment where the daemon needs to manage a large number of displays, like in a terminal server situation. There also might be some value in being able to manage virtual displays using this sort of technique in general, perhaps for automated testing. The tarball contains a README which explains some of the internal details of gdmdynamic and how to set up the scripts to work using the GDM stable branch. I just tested it with GDM 2.20 and verified that these scripts work okay. Perhaps seeing the code actually work might help clarify the requirements. Jon, I was hoping this might help you understand how Sun Ray works with GDM. Since I know you are focusing on the core stuff, perhaps we could discuss further how this should be implemented in the new GDM. Perhaps this is something you would want to tackle, or if you want someone here at Sun to do this integration, then perhaps you could explain how you think this should fit in with the new architecture? I'm sure the Sun Ray team would prefer if the interfaces they depend on (namely gdmdynamic) were to remain stable. However, if there is a compelling reason to refactor or redesign how the Sun Ray software interacts with GDM, then we can explore this also. I suspect the Sun Ray team would be agreeable to changes in the interfaces if there is good reason, and if it is possible for them to tell at runtime which interfaces to use, depending on what version of GDM is running. Brian
Attachment:
gdmdynamic-vfb.tar.gz
Description: GNU Zip compressed data