trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] Latest tsak patch report (GIT hash 6cfb160)

From: Darrell Anderson <humanreadable@...>
Date: Sun, 22 Apr 2012 22:07:56 -0700 (PDT)
> I have also repaired the desktop lock in GIT hash
> 50739c9--you should no longer have the desktop and icon problems you were
> experiencing earlier. If they do persist please let me know!

After rebuilding this took a long while to test because I could not discover any repeatable patterns. Because of that, the testing was confusing.

Here is what happens on my desktop with the latest patches.

============================================
When in graphical login mode and TSAK enabled:

* Pressing Ctrl-Alt-Delete causes a Secure Desktop Area dialog to appear. Because of the nature of the process I could not grab a screen image. Here is an image with my digital camera:

http://humanreadable.nfshost.com/trinity/build_logs/tde-lock-4.png

* The Switch User and Logoff Menu buttons are ghosted/disabled. I don't know how to enable or why they are disabled.

* When I tested as root, the image shows that no user ID is listed as who has the session locked. Perhaps that is intentional, but looks unprofessional. If the intent is to hide that root is logged in then the absence of a user name is a clue anyway.

* Selecting the "Lock Session" button, and proceeding through the process of restoring the desktop, still causes the desktop icons to disappear, the desktop context menu to stop functioning.

* Contrary to my previous report, I can log out. The process requires about 30 seconds or more to unfold, which is why I did not notice previously --- I did not wait that long.

* The disappearing acts are not repeatable. Sometimes the session restored with no ill effects.

* Selecting the Task Manager or Cancel buttons always cause the same ill effects. I never got the session to restore normally after using either button.

* The desktop remains usable. I can still use the panel icons, TDE menu, shortcuts, etc.

* For the first time I witnessed the CPU hogging reported by others. I saw this hogging only once when I invoked the Secure Desktop Area dialog. The moment I invoked the dialog by selecting the "Lock Session" button, the mouse pointer turned to an hourglass and my conky CPU usage ramped to about 68% while the frequency ramped from idle to full speed.

* The CPU hogging is not repeatable. I saw the behavior only once.

* Selecting the Lock applet icon works differently: causing the TSAK Ctrl-Alt-Delete dialog to appear immediately. I found this inconsistent and therefore confusing. I would have thought the Lock icon would invoke the "Secure Desktop Area" dialog.

* Using the Lock applet icon results in the same loss of functionality.

* I preset my screen saver to 1 minute and while in Lock Session mode the screen saver activated as expected.

============================================
When in graphical login mode and TSAK disabled (useSAK=false, uinput not loaded):

* Pressing Ctrl-Alt-Delete exits the session to TDM.

* In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead, a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image:

http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-4.png

* Same ill effects and I can log out but the logout process takes a long time, about 30 seconds.

* The Cancel button is always ghosted.

* I am not able to again to lock the session.

* There are a bunch of dcop socket files in /tmp/.ICE-unix.

============================================
When in command line login mode:

* Pressing Ctrl-Alt-Delete exits the session to the command line.

* In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image:

http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-3.png

* The "Desktop Session Locked" dialog Cancel button is ghosted/disabled.

* Typing my password restores the desktop, but:

* Just before the "Desktop Session Locked" dialog appears, sometimes I momentarily saw the TSAK Ctrl-Alt-Delete dialog.

* tdmrc:useSAK=false during these tests. Besides, this is command line mode, and TSAK should never be involved.

* Most often upon restoring the desktop, like before, desktop icons disappeared, the desktop context menu ceased to function.

* Occasionally, when the desktop icons did not disappear and the desktop context menu still functioned, before returning to the desktop I was always presented with the "Desktop Session Locked" dialog multiple times. Sometimes the dialog reappeared only once, but sometimes more often.

* I can log out but the logout process takes a long time, about 30 seconds.

* Always I am not able to again to lock the session.

============================================
With both the graphical login mode with TSAK disabled and command line login:

* Sometimes two pipe files in appeared /tmp/tdesocket-global: kdesktoplockcontrol and kdesktoplockcontrol_out. They do not disappear when the screen is unlocked. Looks like some more housekeeping needed.

* The two pipe files did not always appear. I don't know the pattern to repeat.

* Seems to me that in these two modes, when TSAK should be out of the picture (but possibly inadvertently isn't), the process should work exactly the same as in KDE3, except with different dialogs: screen saver and then dialog.

* The Cancel button in all dialogs should be enabled all the time.

============================================

Overall, I am unable to discern patterns to repeat the events I am sharing. Hence the ugly report. Let me know what further testing you want or need. Testing this locking mechanism is one of the more time consuming tests because of the weird events, which require restarting the session because only one lock is allowed and then the feature stops working.


Darrell