- This topic is empty.
-
Posts
-
I use many of the C50LE for digital signage. They use Autologin and AutoConnect to boot directly into a VMWare View session. Since upgrading to 11.1.031, my screens go black after 5 minutes. It looks like its the thin client screensaver because the connection is still active and moving the mouse brings everything back. It is not the VM screensaver or power settings as I have V10LEs and C50LEs running 11.1.015 connecting to the same VMs without this issue. If I disable AutoConnect, the thin client will stay at the Linux desktop indefinitely without the screen going black. If I then manually connect to the VM, the screen does not, usually, go black (one time it did).
Could the connection to the VM be preventing the “Screensaver=0” portion of the INI file from being applied? Is there a way to still have the thin client autoconnect, but delay it for a few seconds to make sure everything in the INI is applied properly?
Autologin=yes CountDown=60
That works to delay the login to the thin client. I am looking for a way to delay the AutoConnect to the VMWare session.
I have more testing to do, but I may have found a work around. It seems that a single user interaction with the VM, mouse or keyboard, may be enough to prevent the screen from going black, indefinitely. Many of my thin clients are used for displays do not have mice and keyboards. Today I found that one C50LE that I had been working with Friday, was still displaying properly. I restarted it and the screen went blank after 10 min. After being the screen back by moving the mouse and clicking a few times, I left it idle and the screen has not gone black again.
Now the question is whether the interaction fixed the problem or cycling in and out the black screen fixed it. To test this I will restart the C50LE and interact with the VM a bit then leave it idle. If the interaction is what is fixing it, it should never go black. If not, its cycling in and out of the black screen. I will also be testing whether a remote shadow interaction is enough to keep the screen active or if a physical mouse needs to be used. I will post the results back here.
**********************************************
I ran through the tests outlined above. As long as there in any kind of interaction with the C50LE, either locally or through VNC, the screen will not go black (assuming you have it set that way). While its a work around, I am still waiting for Wyse tech to get back to me as it is still an issue for me.Have you tried using a previous version of rdesktop? Our environment was having problems with the new wyse_rdesktop package. But pulling the rdesktop package off of 11.1.015 and installing that instead worked well.
A Wyse Support Technician sent emailed me the following addon and it seems to have fixed the problem.
xset_no_blank-1-0.sletc11sp1.rpm
He said it will likely be included in the next firmware. Since its not in 11.1.052 (or the 11.1.053 beta) it might be a while. Anyone having this issue may want to contact support and request this file.
Digging up an old post, but, I think I must be missing something.
We have an environment with about 300 R50s. Some of these are autologin devices, where, upon terminal startup/restart, they immediately launch a view session and connect to their appropriate VM. If the user doesn’t interact with the mouse at all for the first 10 minutes it is up, the terminal will go idle and blank the screen. If they move the mouse after that, or even before it, it NEVER goes blank. Until the next restart of course.
We were provided the xset_no_blank-1-0.sletc11sp1.rpm, and I do see it enabled in our AddOn Manager on the suse side (along with other working verified addons like the new View client and the mixed envionment imaging addon). We still see the issue.
We are on the latest R50 firmware, and we also have specified in the wlx.ini screensaver=0 (I’ve taken that out for testing, either way the issue remains) and powermanager=0,0. Is there anything else we should be trying? Wyse has not been much helped. They mentioned this addon, but, they also stated a CIR is still open about this issue.
Our wlx.ini:
;*************************************************************
;* General 1 *
;*************************************************************FirmwareServer=xxxxxxxxxxx
FirmwareUserName=xxxxxxxxxx
FirmwarePassword=xxxxxxxxxx
UPGRADE.IMAGE_ROOTPATH=/wyse_mixed/$PLATFORM/
Rapportserver=xxxxxxxxxxxxxx
Update.Mode=Both
PowerButtonAction=reboot
Update.Preserve_changes=yes
Privilege=None
Autopower=yes
Autosignoff=yes
Shutdowncounter=5
IniFileSource=cache;*************************************************************
;* General 2 *
;*************************************************************; When using a pre-SLEDTC11 SP1 firmware use Keyboard= instead of Keyboard.layouts=
Keyboard.layouts=us
MouseSpeed=1
EnableBanner=yes BannerMsg=xxxxxxxxxxx
AudioVolume=100
NewAddons=dhclient_hostname-1-0.sletc11sp1.rpm,xset_no_blank-1-0.sletc11sp1.rpm,mixed_env_upgrade-1.0.0-01.00.sletc11sp1.rpm,vmware_viewclient-2.0.0-1049726.00.02.sletc11sp1.rpm;*************************************************************
;* General 3 *
;*************************************************************ImportCerts=yes
Certs=xxxxxxxx.p7b;xxxxxxx.p7b;*************************************************************
;* Display *
;*************************************************************Desktop=xxxxxxxxx_logo.bmp Layout=Stretch
DesktopColorDepth=24
PowerManager=0,0;*************************************************************
;* Time *
;*************************************************************Timeserver=xxxxxxxxxx
Timeformat=”24-hour format”
TimeZone=”US/Eastern” ManualOverride=1;*************************************************************
;* Network *
;*************************************************************DisableVNC=no
VncPasswd=xxxxxxxxxx
VNCAuthTypes=vnc
VncPrompt=yes
Autologin=yes
Defaultuser=guest
ChangeAdminPassword=xxxxxxxxxx;*************************************************************
;* VIEW *
;*************************************************************;
;- View Session 1 –
;- Each line but the last must end with a ‘ ‘ –
;
CONNECT=VMWARE_VIEWCLIENT
Description=”View Client”
Host=xxxxxxxx
DomainName=xxxxxxxx
Autoconnect=yes
Fullscreen=yes
Interactive=no
DisableMenuBar=yes
DesktopSize=fullscreen
Reconnect=yes
ReconnectSeconds=3
Username=xxxxxxxx
Password=xxxxxxxx
SecureMode=warnbefore
LocalCopy=noFor the hell of it, I threw up our D50D we’re testing on, with the latest firmware of 11.2.038, set him up for autologin, using the same INI parameters (but removed the noblank addon), and he shows the same behavior. Blank screen after 10 minutes of inactivity after restart of the terminal. One minor difference: his monitor’s light is still green, where as the R50s the LCD light goes amber (same exact LCD), but nonetheless, still blank screens.
I removed the noblank add on because I am ASSUMING by now, the fix would be built into the firmware.
It would appear, assuming our INI and Addons are all correct, this issue has followed models/firmwares.
and now some new testing has thrown me off.
I made one of my R50s NOT autologin, simply sit at his view login, and sure enough after 10 minutes, he went idle. This would seem to prove it’s not View/VM related, but strictly terminal.
I am wondering if it’s monitor related? I’ve tested on an HP LE1911 and HP L1910, same symptoms. Trying to get my hands on another random LCD>
My teammate had a good suggestion. We’re testing/live with 19″ LCDs from HP, connected to the terminal via a VGA cable with DVI adapter (that comes with the terminals). He’s wondering what happens if we go straight through with DVI, so, I’m going to grab another monitor with this capability and see what we get.
Update: a 22″ HP LCD with a straight through DVI-D cable produced the same results. Going to try a monitor from a different manufacturer, since we’ve now tried 4 HP LCD models with no luck. Grasping at straws now.
Update 2: used a Samsung LCD, same exact issue.
I had the same exact problem myself
I had already had an issue with vmware view clients not letting a user choose their resolution to accommodate poor eye sight, so I have a secondary launch script that asks the preference beforehand, it stays active in the background for the entire session, and sets the desktop resolution back to the previous state on logout.
long story still going, I added in an xset -dpms in there when rdp launched, and hae xset +dpms in there for when it closes down. So for the entire run session of the connection, the thinclient will not turn off the screen.
My problem actually even went a little further, in that moving the mouse would not bring the screen back, once it went black, it never came back.
- You must be logged in to reply to this topic.