Yes, This is a single Sun Ray 2FS with 2 like monitors directly
connected.
I discovered that I broke it when I introduced a
"utresadm -a -c default -t default 1280x1024x60" ... Something I like to
use because of the various KVM's scattered about. I had set this
shortly after joining the 2 servers in fail-over. As soon as I removed
the default and cycled the thin-client I was back in business.
Thanks for the response.
Keith
Message: 2
Date: Sat, 2 Jun 2007 13:50:52 -0700
From: ottomeister <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Dual-Head broke after establishing
fail-over
To: "SunRay-Users mailing list" <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
On 5/31/07, Ives, Keith-P59429 <[EMAIL PROTECTED]> wrote:
> I HAD dual-head monitors working on 3.1 rev.120879-06. 2 servers,
> identical configs.
> When servers were stand-alone, dual-head worked as designed on both
> systems without any special parameters set.
> After joining the 2 servers in a failover group, my dual-head broke...
> only 1 monitor active. The thin-client is a 2FS.
So this is a pair of monitors attached to a single Sun Ray 2FS, not a
multihead group constructed from multiple Sun Ray units, right?
Is this happening on all of your 2FSs, or only some?
The 2FS should drive both monitors, provided that it knows they're
there. This means that they must both be powered up and connected and
responsive to DDC before the 2FS contacts the Sun Ray server and tells
it how much screen real estate it has, because by default the server
will create a desktop that will occupy that amount of real estate. Oh,
and DDC must report that the monitor can support at least one timing
that the Sun Ray can drive, but if this used to work in the past with
these same monitors then that's probably not the issue here.
If that's all as it should be then, barring bugs, there are three ways
you can end up with only one monitor being driven. They all boil down
to the 2FS being presented with an X desktop whose width is such that it
will fit onto the first monitor. In that case the 2FS will present the
desktop on the first monitor and won't drive the second monitor. One
way is to hotdesk an existing small desktop to the 2FS, the second is to
override the default behaviour by using 'utxconfig' to constrain the
size of a newly-created desktop, and the third is to override the
default behaviour by using 'utresadm' or 'utsettings' to constrain both
the monitor timing and the size of the desktop.
If you're at this 2FS with a logged-in desktop then start by running
'xdpyinfo | grep imension' to find out how big your desktop is.
Presumably it's small enough that it fits onto the first monitor. Then
the question is "how did it get to be that size?" If you know you
created it on some other single-monitor Sun Ray then that's the answer.
If you don't know how the desktop got to be the size it is then look for
'utxconfig' or 'utresadm' records that would force it to a specific
size. If you're feeling paranoid then do this on both servers and make
sure that they agree, to rule out the possibility that the configuration
data store is not being replicated properly.
If that doesn't explain what's going on then it's worth trying to create
a new desktop on the 2FS to see whether it gets the desired result.
Make sure both monitors are powered up and connected to the 2FS (check
KVMs and A/B switches, which can interfere with DDC) then restart the
2FS (hit Control+Power) to force it to refresh its idea of what monitors
are attached and to report its findings to the server, then log out and
see whether the next X desktop (showing a login greeter) spans both
monitors. Actually, don't judge on the basis of the greeter alone
because they can have some strange behaviours. Instead log back in and
see what the logged-in desktop looks like, and/or run 'xdpyinfo' to get
the actual desktop dimensions.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
