Bug 2349

Created attachment 2448 [details]
Shell script to be used only for testing

Initially I thought this bug was related only to krfb, as mentioned in the krfb/krdc bug reports. I now see the same bug in my home theater PC without krfb/krdc, but I believe the bug is the same root cause.

When the monitor enters DPMS, Trinity terminates the screen saver process. I do not know whether that is expected behavior, as discussed in the krdc/krfb bug reports. After entering DPMS, using a keyboard or mouse causes Trinity to stop DPMS and restore the desktop. Trinity behaves as expected.

Programmatically restoring the desktop with a script does not provide the same expected results.

With an htpc, often a keyboard and mouse are not used but instead a remote control. I use a short shell script to restore the htpc desktop when the screen saver is running. I launch the script with my remote control through lirc. The script worked fine for several years but sometime in the past few months the script stopped working as expected.

Fundamentally the script is reduced to the following:

dcop kdesktop KScreensaverIface quit
xset dpms force on

The dcop command works as expected when the monitor is not in DPMS. That is, the same as using a keyboard or mouse to restore the desktop.

Restoring from DPMS creates strange results.

Unlike with a keyboard or mouse event, executing these two commands results in unexpected behavior. After executing the xset command, about one to ten seconds later Trinity relaunches the screen saver. This does not happen with a keyboard or mouse event.

Yet the user does not see the screen saver. Instead the user sees a light black screen, similar to a "blank screen" screen saver. At that point I again have to run the script to stop the screen saver or initiate a keyboard or mouse event.

Possibly this might be related to the patch provided in bug 1419, but only a wild guess of association because I was involved with that bug report.

The expected behavior when running the script commands should be the same as when using the keyboard or mouse. That is what I observed up until a few months ago. While the xset command is not a Trinity app or command, Trinity should see an xset event the same as a keyboard or mouse event.

Any fix provided here should also be tested with krfb as that is where the bug was first noticed.

Testing this without a remote control can be done by using two computers, ssh, and  executing the two commands. I use ssh because testing requires avoiding the keyboard and mouse on the test system while allowing observations of the test system monitor.

I ran many such tests. I set the screen saver timeout to 30 seconds by editing kdesktoprc and by editing kcmdisplayrc to Standby=1 minute, Suspend=2 minutes, and Poweroff=3 minutes. In my case my TV displays a vendor logo on loss of input, but use the xset q command to know the monitor status. The last few lines in the xset output show the DPMs status.

I am attaching a shell script for testing to observe how the screen saver is relaunched. To use the script, configure the screen saver and power management as described. Use ssh to avoid all keyboard and mouse events on the test system yet allowing monitor observation. The script contains stdout messages to help understand the bug.

Execute the script before entering DPMS to notice recovery is the same as a keyboard or mouse event. Then manually execute the script in each of the three DPMS modes: Standby, Suspend, and Off. The xset q command will indicate when the monitor is in each mode.

Important to observe is the screen saver is always relaunched, which does not happen with keyboard or mouse events that restore the desktop. Run the script many times to notice the random intervals in which the screen saver is relaunched. I have seen the screen saver relaunch in as little as one second and as long as 10 seconds.

Occasionally the desktop does not restore at all. In that case, running the script a second time usually restores the desktop (or initiating a keyboard or mouse event).

Usually restores. Sometimes I see the dcop command fail with exit code 1. Under that condition I have to use a keyboard or mouse to restore the desktop. Running the dcop command directly results in a 'call failed' error message. There will be two dcopserver processes running. Basically dcop is broken at that point. From that point the dcop command fails 100%, requiring restarting Trinity.

I am uncertain whether the screen saver should terminate in DPMS mode. The monitor does not care what processes are running while in DPMS. Regardless, the screen saver should not be relaunching. There should not be two dcopserver processes. The two commands should restore the desktop exactly the same as a keyboard or mouse event.

While not a destructive bug, the bug's root cause likely is related to the same observations related to krfb. In both cases, the bug affects usability as well as stability. Resolving this bug likely will resolve a few other bugs.