| Summary: | Screen saver does not stop when using krdc | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdenetwork | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | PATCHAVAIL --- | ||
| Severity: | major | CC: | be4youcome, bugwatch, darrella, kb9vqf, slavek.banko |
| Priority: | P1 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | Patch to remove FIXME comment | ||
|
Description
Darrell
2014-04-02 20:16:35 CDT
This will become a show stopper in R14 to anybody who uses remote connections. When the remote machine enters DPMS mode and the monitor is off, trying to connect does not reset DPMS. The screen saver keeps trying to run. If the screen saver finally stops the remote desktop, which does seem to happen now and then, at that point the remote desktop freezes. Walking over to the remote system and physcially moving the mouse or touching the keyboard restores the monitor but the desktop is frozen and unusable. The problem does not occur when only the screen saver is running. The trigger point is when the monitor enters DPMS mode and is off. SSHing into the remote box and running 'xset dpms force on' does not seem to cure the problem. Looks like part of the problem is caused by xflux. Disabling xflux stops the freeze problem but does not stop the screen saver. With some after thought, why is the screen saver trying to run at all when the monitor has entered DPMS mode? Note: SSHing into the remote machine and running 'xset dpms force on' does indeed succeed --- as long as the DISPLAY environment variable is defined. For example, SSH and then run 'DISPLAY=:0 xset dpms force on'. For testing purposes I used 1 minute for screen saver activation and 2, 3, and 4 minutes for the DPMS Power Control settings. I tested connecting to a remote TDE system using Remmina. The remote system was in DPMS mode. I connected without problems and the screen saver stopped running. Seems then the problem is krdc and not krfb. Testing with the latest TDE GIT (using the new libvncclient) on local and remote Slackware 14.1 systems. Connecting to the remote system after the remote system enters DPMS off does not resolve the screen saver problem. As previously mentioned, the screen saver problem arises only after the monitor enters DPMS off. When the screen saver is running and the monitor has not yet entered DPMS off, connecting to the remote system stops the screen saver. After entering DPMS off the screen saver no longer is running as can be verified using SSH to the remote system. Yet connecting via VNC activates the screen saver and the screen saver cannot be disabled through the VNC connection except through continual mouse motion. After entering DPMS off and then connecting with VNC, which momentarily stops the screen saver, then waiting a second or two to concurrently use SSH to kill the screen saver process results in a 'No such process' error. Then the screen saver starts running again. Repeat until insane. OK, thank you for the detailed information. This is likely a problem in kdesktop_lock; to ease debugging can you post the [General] and [ScreenSaver] sections of your ~/.trinity/share/config/kdesktoprc file on the remote machine (i.e. the one running krfb)? Thanks! kdesktoprc ========== [General] AutoLineUpIcons=true Enabled=true SetVRoot=false [ScreenSaver] DPMS-dependent=true DelaySaverStart=false Enabled=true HideActiveWindowsFromSaver=true HideCancelButton=false Lock=false LockGrace=60000 Priority=19 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=600 UseTDESAK=true UseUnmanagedLockWindows=false kcmdisplayrc ============ [DisplayEnergy] displayEnergySaving=true displayPowerOff=20 displayStandby=12 displaySuspend=15 Created attachment 2427 [details]
Patch to remove FIXME comment
There is a FIXME comment in tdebase/kdesktop/lock/main.cc:68 that is not needed. The GUI controls exist.
|