[SunRay-Users] UTRESADM per user token

Nelson, Kevin (FacilicorpNB) Kevin.Nelson at facilicorpnb.ca
Thu Jul 16 17:35:18 EEST 2009

Thanks ottomeister,

I tried utxconfig and successfully set one of my tokens to 1024x768
while the rest stay at the default 1280x1024.  The command I used for
others is utxconfig -r 1024x768 -t <payflex token number>.

Thanks very much - now to incorporate this into my kiosk
script....hopefully using the "other info" field in the token setup....


Message: 2
Date: Wed, 15 Jul 2009 20:30:31 -0700
From: ottomeister <ottomeister at gmail.com>
To: SunRay-Users mailing list <sunray-users at filibeto.org>
Subject: Re: [SunRay-Users] UTRESADM per user token
	<a4209c300907152030m46a45d4ameec8a54ee4db2b2d at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

On Wed, Jul 15, 2009 at 12:04 AM, Nelson, Kevin
(FacilicorpNB)<Kevin.Nelson at facilicorpnb.ca> wrote:
> utresadm ?a ?c default ?t <payflex user token> 1024x768 at 60.
> With this command I get an error stating that if I use default for the
> then I must user default for the User Token.? Am I missing something??
> have seen posts that use default for the user token and specify a MAC
> the DTU and this works ? should this then not work the other way by
> a payflex token to use a specific screen resolution on any DTU it
> to?

You can fix the timing for a DTU regardless of the token (that's the
'-c <dtu> -t default' combination).  You can not fix the timing for a
token regardless of the DTU (that would be '-c default -t <token>',
but the command won't accept that.)

The first is allowed because it's not unusual to have a DTU that is
attached to a monitor or to other video equipment that does not
respond to DDC but must nevertheless be driven with a specific

The second is disallowed because it creates a huge risk that the
token will become unusable when hotdesked to some DTUs.  The
monitors attached to those DTUs may be unable to accept the timing
that has been tied to the token. When this happens it's very hard to
figure out what's giong on and there's nothing the user can do to
recover from it, other than getting an admin to intervene.  (If this
mode was allowed then it would also create an interesting conflict:
if both the DTU and the token have a forced timing, which timing
wins?  But that's resolvable, it's not the reason why
'-c default -t <token>' is disallowed.)

The safer way to do all of this, provided that your monitors respond
to DDC requests, is to not use 'utresadm' at all.  Instead use
'utxconfig' to force the dimensions of the X desktop.  This allows the
DTU to choose a monitor timing that matches the desktop, and since
the DTU will never drive a timing that the monitor can not accept
there's no risk that any token will be shut out by forcing a timing that
its monitor can not accept.  'utxconfig' lets the admin set a
system-wide default for the desktop dimensions of all tokens or for
individual tokens, and it also lets the user set the dimensions for an
individual token. (That's assuming that the user has access to the
'utxconfig' command.  If you're using kiosk mode then the users might
not have access to any local commands.)


Disclaimer: These are my opinions.  I do not speak for my employer.
------- Avis de confidentialité FacilicorpNB Disclaimer -------

This e-mail communication (including any or all attachments) is intended only 
for the use of the person or entity to which it is addressed and may contain 
confidential and/or privileged material. If you are not the intended recipient of this 
e-mail, any use, review, retransmission, distribution, dissemination, copying, 
printing, or other use of, or taking of any action in reliance upon this e-mail, is 
strictly prohibited. If you have received this e-mail in error, please contact the sender 
and delete the original and any copy of this e-mail and any printout thereof, 
immediately. Your co-operation is appreciated.

Le présent courriel (y compris toute pièce jointe) s'adresse uniquement à son 
destinataire, qu'il soit une personne ou un organisme, et pourrait comporter des 
renseignements privilégiés ou confidentiels. Si vous n'êtes pas le destinataire du 
courriel, il est interdit d'utiliser, de revoir, de retransmettre, de distribuer, de 
disséminer, de copier ou d'imprimer ce courriel, d'agir en vous y fiant ou de vous 
en servir de toute autre façon. Si vous avez reçu le présent courriel par erreur, 
prière de communiquer avec l'expéditeur et d'éliminer l'original du courriel, ainsi 
que toute copie électronique ou imprimée de celui-ci, immédiatement. Nous sommes 
reconnaissants de votre collaboration.

More information about the SunRay-Users mailing list