Re: [gdm-list] GDM - gdmdynamic and Sun Ray support

Thanks Brian.

Taking a step back, a Sun Ray is just an example of a "Thin Client".
All Thin Clients can dynamically attach to servers and need a desktop
served to them when they do.  gdmdynamic is the interface
used to setup and tear down desktops when needed.  For the purpose
of GDM, I don't want to over-focus on Sun Ray (even though it's
the product I work on), the value of gdmdynamic is (at least
potentially) broader than that, and should remain so.

Here's a blog entry regarding Sun Ray for home use in case
that's of interest in putting this into perspective:

There are some interesting announcements coming out soon
which may make in-home use more attractive.


Brian Cameron wrote:


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.

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:

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

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

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.


gdm-list mailing list
gdm-list gnome org

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