| Summary: | kdesktop_lock contains irritating bugs | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Roman Savochenko <rom_as> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | bugwatch, kb9vqf, rom_as, slavek.banko |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | 898 | ||
| Bug Blocks: | |||
| Attachments: |
SAK realization into KDM fix patch
SAK realization into TDM fix patch (updated for latest GIT) SAK realization into TDM fix patch (updated for latest GIT) SAK realization into TDM fix patch (updated for latest GIT) |
||
Your patch fixes the bugs that are already fixed - see bug #690 and commits 1e2983ad and 5486d8e2. Please update your patch to include only new repairs. The following likely all are related: 884 tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket' 898 tsak process taking 90-100% of CPU 906 SAK realization is mostly buggy for KDM 925 [kdesktop] SAK driven secure dialog is not available for use Created attachment 508 [details]
SAK realization into TDM fix patch (updated for latest GIT)
Created attachment 509 [details]
SAK realization into TDM fix patch (updated for latest GIT)
Created attachment 510 [details]
SAK realization into TDM fix patch (updated for latest GIT)
(In reply to comment #5) > Created attachment 510 [details] > SAK realization into TDM fix patch (updated for latest GIT) This patch defeats the entire purpose of the SAK system--the SAK should never be visible to any application other than the root-owned tsak daemon. If the SAK does become visible then the entire SAK system is compromised and the user should be informed of this fact, not lulled into a false sense of security. Comment on attachment 510 [details]
SAK realization into TDM fix patch (updated for latest GIT)
Patch deleted per information from Tim about how SAK functions.
Regarding these issues stated by the original reporter: - Disable SAK from config file (by UseSAK=false) do not work. - Exit from wait dialog by Ctr+Alt+Del do not work. - High CPU consumption on wait SAK. 1. The reason this happens is TDM performs no housekeeping. tsak creates some pipe/socket files in /tmp/tdesocket-global/tdm. Those files are not deleted during a reboot, X server restart, or intentional disabling from within KControl. The next time TDM starts, tsak sees the existing pipe/socket files and ignores the tdmrc UseSAK setting. An appropriate solution is to delete those pipe/socket files 1) during a reboot/halt (when TDM terminates), 2) X server restart (which TDM allows), or when a user disables tsak in KControl. Some operating systems perform this housekeeping automatically, which probably is why some people never see this issue. Some systems assign /tmp to tmpfs in RAM and never see this problem. Usage of tsak should not depend upon the presumption of operating system housekeeping. TDM should perform this housekeeping. 2. I am unable to use or test tsak because when tsak is enabled, I am presented with the Ctrl-Alt-Delete dialog from tsak. Pressing Ctrl-Alt-Delete does nothing. I never am able to obtain access to the TDM login dialog. I have to manually kill the tdmtsak process and then the tsak dialog disappears and I can login. I suspect the problem is a conflict for using the Ctrl-Alt-Delete keyboard shortcut. That shortcut is hard-coded into both tsak and TDM. 3. I have been unable to replicate the high CPU usage, but my testing has been limited because I am unable to use tsak. The Ctrl-Alt-Delete conflict with TDM prevents me from accessing the login dialog. Another bug with tsak is ownership of /tmp/tdesocket-global is assigned to the system's primary login account. Ownership of that directory is determined by the account UID listed in the tdmrc MinShowUID key and then that account number is grabbed from /etc/passwd. Although that directory is assigned ownership to the primary user ID, that user is not allowed to view the contents of /tmp/tdesocket-global. That makes sense in a way because the directory is created by tsak, but ownership should be root:root. I suspect tsak is merely grabbing that information from TDM rather than parsing tdmrc directly. I haven't looked into this bug report yet in any detail. I know this is somewhat frustrating for many users, but rest assured that I will look into it once some other bug reports I am working on are closed. I assume that those who are having problems getting the Ctrl+Alt+Del keypress recognized are using either non-US keyboard layouts or PS/2 keyboards? I am not frustrated by this bug report. Just adding information that I hope helps resolve the problem. :) Yes, I am using a keyboard connected through a PS/2 port. Same with testing in a VirtualBox virtual machine. I use the OSE version, which does not support USB, therefore I don't think I can change that. Is tsak hard-coded to a particular type of keyboard? I have a USB wireless keyboard on another computer. Would that help with testing? (In reply to comment #11) > I am not frustrated by this bug report. Just adding information that I hope > helps resolve the problem. :) OK. :-) I know there are others on the ML that want to throw the whole SAK idea out, so Priority #1 is probably to make sure that it can actually be switched off if needed. > Yes, I am using a keyboard connected through a PS/2 port. Same with testing in > a VirtualBox virtual machine. I use the OSE version, which does not support > USB, therefore I don't think I can change that. > > Is tsak hard-coded to a particular type of keyboard? It isn't supposed to be, but it does rely on udev, and I don't know if PS2 keyboards are handled differently than USB ones (udev is a complete disaster from an application developer's point of view BTW). > I have a USB wireless keyboard on another computer. Would that help with > testing? No, not really. I know USB keyboards tend to work, but if you want to verify that this is true on your machine it would be a confirmation that non-USB keyboards are the problem. I've been meaning to set up a VirtualBox test environment for a while, and will need to do so to debug this problem. Tim Yes, I agree the housekeeping issue will resolve half the frustration because then people at least can disable the feature. Right now they can't because of those persistent pipe/socket files. As I mentioned, when a user disables tsak in KControl they expect just that. My experience is once the pipe/socket files are created TDM or tsak is ignoring the tdmrc UseSAK key and that is where users get frustrated and confused. tsak should look for those pipe/socket files only after performing a readEntry on tdmrc. Probably TDM should do the housekeeping as that is what controls tsak. I noted three places where those files should get purged. I'll test the USB keyboard later. I tested a wireless USB keyboard. No difference here --- I could not get past the dialog to the TDM dialog. This is a Slackware system, with udev and hal running. When tsak is disabled (tdmrc UseSAK=false and all pipe/socket files deleted) pressing Ctrl-Alt-Delete raises a shutdown/reboot dialog. The shorcuts of Ctrl-Shift-Alt-PageUp and Ctrl-Shift-Alt-PageDown also work as expected but do not work when tsak is enabled, which I suspect is proper operation. Although most of the problems with TSAK have been addressed through bug report 898, there remains some cleanup work required. * On a slower machine, the TSAK Ctrl-Alt-Delete dialog appears momentarily before the Desktop Session Locked dialog appears. Users with fast machines likely do not see the momentary appearance. The dialog should not appear at all. Especially when in command line login mode (startx), which means TSAK is not supposed to be in the picture at all. Not to mention that appearing momentarily like that does not look "high quality." * Many users are accustomed to using Ctrl-Alt-Delete as a logout shortcut. That shortcut works except when useSAK=true. The missing element is the Logout button is ghosted/disabled in the dialog. This feature remains to be fully implemented. * The Switch User button also is not yet implemented. * The Secure Desktop Area dialog does not show root's account name in the dialog. Just the single quotation marks with nothing in between. Non root account names appear as expected. Testing the latest patches: In graphical login mode (TDM), with useSAK=false or true I now no longer momentarily see the SAK dialog before seeing the other dialogs. In command line login mode (startx), I still momentarily see the SAK dialog before seeing the lock desktop dialog. The Logoff Menu button is now available, which means being able to again use Ctrl-Alt-Delete to logout, but I found the name of the button confusing. TDM offers a Menu button, but the button name implies some kind of menu will appear, which never does. I do not have Confirm Logout enabled. I think tradition is better here and we just name the button Logoff. The busy cursor issue addressed in the patch in GIT hash 4d538e40, resolves the problem with the desktop locking dialogs but not with the Secure Desktop Area dialog. With useSAK=true, DelaySaverStart=true, UseUnmanagedLockWindows=false, pressing the Lock Session button activates the busy pointer. I had the screen saver delay set to 60 seconds, but the screen saver never appeared. I tested this several times. With useSAK=true, DelaySaverStart=false, UseUnmanagedLockWindows=false, the screen saver never starts. Instead the background goes black. Possibly the screen saver is starting but only momentarily and then is interrupted. I was using the polygons screen saver, which has a black background. Regardless, there is no screen saver action. Pressing the Lock Session button also does not activate the screen saver, regardless of the DelaySaverStart setting. Selecting the Lock applet icon with DelaySaverStart=false starts the screen saver immediately. (In reply to comment #16) > Testing the latest patches: > > In graphical login mode (TDM), with useSAK=false or true I now no longer > momentarily see the SAK dialog before seeing the other dialogs. > > In command line login mode (startx), I still momentarily see the SAK dialog > before seeing the lock desktop dialog. You always will unless SAK is disabled in kcontrol. What is happening is that kdesktop_lock is trying to use the SAK system, but it is unavailable due to tsak not being started, so it is falling back to the unlock dialog. The alternative would be to permanently hang at the Ctrl+Alt+Del screen if tsak is not running when it should be, which wouldn't be a good idea usability-wise. ;-) > The Logoff Menu button is now available, which means being able to again use > Ctrl-Alt-Delete to logout, but I found the name of the button confusing. TDM > offers a Menu button, but the button name implies some kind of menu will > appear, which never does. I do not have Confirm Logout enabled. I think > tradition is better here and we just name the button Logoff. This should be fixed in GIT hash a9ad871, let me know if it is not on your system. > The busy cursor issue addressed in the patch in GIT hash 4d538e40, resolves the > problem with the desktop locking dialogs but not with the Secure Desktop Area > dialog. Can you please give exact steps to reproduce this problem? > With useSAK=true, DelaySaverStart=true, UseUnmanagedLockWindows=false, pressing > the Lock Session button activates the busy pointer. I had the screen saver > delay set to 60 seconds, but the screen saver never appeared. I tested this > several times. > > With useSAK=true, DelaySaverStart=false, UseUnmanagedLockWindows=false, the > screen saver never starts. Instead the background goes black. Possibly the > screen saver is starting but only momentarily and then is interrupted. I was > using the polygons screen saver, which has a black background. Regardless, > there is no screen saver action. > > Pressing the Lock Session button also does not activate the screen saver, > regardless of the DelaySaverStart setting. > > Selecting the Lock applet icon with DelaySaverStart=false starts the screen > saver immediately. Regarding all of the screen saver problems, kdesktop_lock reads the system screen saver configuration from kdesktop, so if the screensaver is not set to auto-start on the desktop, it will never auto-start when the lock is engaged. I suppose I could provide a configuration option for this ("Ignore Desktop Screen Saver Settings" or similar) if needed. (In reply to comment #15) > * The Secure Desktop Area dialog does not show root's account name in the > dialog. Just the single quotation marks with nothing in between. Non root > account names appear as expected. Fixed in GIT hash a090f7e. Regarding my previous Note about the screen saver starting automatically, despite DelaySaverStart=true, and then no dialog appearing. I repeatedly replicate the problem with these settings: [ScreenSaver] DPMS-dependent=true DelaySaverStart=true Enabled=false Lock=false LockGrace=60000 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 UseUnmanagedLockWindows=true Changing Enabled=true made no difference. Restoring Enabled=false and changing UseUnmanagedLockWindows=false resolved the problem. [ScreenSaver] DPMS-dependent=true DelaySaverStart=true Enabled=false Lock=false LockGrace=60000 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 UseUnmanagedLockWindows=false I realize the old style dialog setup works differently. No complaint about those differences. The bug is I can't escape the screen saver. Nothing I do invokes the dialog. I have to press Ctrl-Alt-Backspace to escape the lock process. Killing the screen saver through another console results in a black screen but no recovery. Killing the lock process ends the session. There is a bug here with UseUnmanagedLockWindows=true. :( Another bug: Using kwriteconfig to make the changes to the three keys with no GUI controls do not take effect immediately. I have to restart the session to see the changes of those three keys. Is there something else I need to do to make the session aware of the new settings? I thought kwriteconfig did that. I have not yet tested the latest patches. > I have not yet tested the latest patches.
I just pushed a patch (hash e92e82b) that *should* resolve a number of the remaining lock system problems, including the irritating DCOP warning messages in ~/.xsession_errors.
I was able to restore the old style lock behaviour on the latest GIT sources, with no problems, using these settings:
[ScreenSaver]
Enabled=true
Lock=false
LockGrace=60000
Timeout=60
UseUnmanagedLockWindows=true
DelaySaverStart=false
Let me know which problems are still present...
Thanks!
I should also note that using the old-style unmanaged windows disables the SAK feature, as the old code cannot properly deal with the SAK dialog. Try these settings. Notice Enabled=false. [ScreenSaver] DPMS-dependent=true DelaySaverStart=true Enabled=false Lock=false LockGrace=60000 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 UseUnmanagedLockWindows=true My screen goes black (blank screen saver?) and I can't exit the lock process. Keep those settings (Enabled=false) and change UseUnmanagedLockWindows=false. I am immediately presented with the dialog and can exit the lock process. Keep those settings (Enabled=false) and change DelaySaverStart=false. The screen goes black but upon a key press or mouse movement I am presented with the dialog and can exit the lock process. Keep those settings (Enabled=false) and change UseUnmanagedLockWindows=true. The screen goes black but upon a key press or mouse movement I am presented with the dialog and can exit the lock process. Keep those settings (Enabled=false) and change DelaySaverStart=true. This returns us to the original settings for this discussion. My screen goes black and I can't exit the lock process. I'm still testing other fixes and will report again. As mentioned previously, I have to restart the session for each change. Using kwriteconfig does not seem to update the session. (In reply to comment #23) > As mentioned previously, I have to restart the session for each change. Using > kwriteconfig does not seem to update the session. This is with the recent patch in GIT? I made specific efforts to fix that problem. Ok, this is weird. I started my session with these settings: [ScreenSaver] DPMS-dependent=true DelaySaverStart=true Enabled=false Lock=false LockGrace=60000 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 UseUnmanagedLockWindows=true Based upon my previous post, those settings result in the screen going black and no dialog, requiring me to use Ctrl-Alt-Backspace to escape. This indeed happens. I restarted the session with the same settings. From within konsole I performed the following: kwriteconfig --file kdesktoprc --group ScreenSaver --key UseUnmanagedLockWindows false That change should have used the newer dialog and avoided the older dialog. Yet when I selected the Lock Desktop applet icon, the screen went black and no dialog. Upon pressing Ctrl-Alt-Backspace and restarting the session, the same steps worked as expected. I was presented with the dialog. Within the same session, from within konsole I performed the following: kwriteconfig --file kdesktoprc --group ScreenSaver --key UseUnmanagedLockWindows true This time the change took effect and I was presented with the black screen and no dialog. I repeated this entire sequence twice with the same result. Seems kwriteconfig sort of works and sort of doesn't. Let me know whether you can or can't confirm. I can confirm the black screen problem related to UseUnmanagedLockWindows=true and DelaySaverStart=true. That is an illegal combination of the variables, and therefore will not function. I could force DelaySaverStart to false when UseUnmanagedLockWindows is true; would this be acceptable? All other combinations of those two settings work on my test system. Also, I have not seen any settings application problems when manually editing kdesktoprc via nano or kwrite, so I would suspect a problem in kwriteconfig unless you continue to experience problems when manually setting the variables in kdesktoprc. (In reply to comment #26) > I can confirm the black screen problem related to UseUnmanagedLockWindows=true > and DelaySaverStart=true. That is an illegal combination of the variables, and > therefore will not function. I could force DelaySaverStart to false when > UseUnmanagedLockWindows is true; would this be acceptable? I should clarify that kdesktop_lock would silently force this condition, and that there would need to be similar logic in the kcontrol module to make this requirement visible to the user in a graphical fashion. (In reply to comment #27) > (In reply to comment #26) > > I can confirm the black screen problem related to UseUnmanagedLockWindows=true > > and DelaySaverStart=true. That is an illegal combination of the variables, and > > therefore will not function. I could force DelaySaverStart to false when > > UseUnmanagedLockWindows is true; would this be acceptable? > > I should clarify that kdesktop_lock would silently force this condition, and > that there would need to be similar logic in the kcontrol module to make this > requirement visible to the user in a graphical fashion. Logic added to kdesktop_lock in GIT hash 5d28683. The proposed resolution for the conflict sounds good.
To make that visible to the user, as the GUI controls don't yet exist --- unless you plan to add them pronto, whenever the user selects the UseUnmanagedLockWindows check box, which turns the key setting to true, that the DelaySaverStart check box resets to unchecked (false) and automatically is ghosted/disabled.
That is what we want anyway. In KDE3, with the older dialog, when the user locks the desktop the screen saver activates immediately. That is the same as DelaySaverStart=false.
A remaining catch to all of this is when Enabled=false then the code has to select a screen saver, which the default blank screen should suffice.
I tested this in KDE3. For example:
Enabled=false
Saver=KPolygon.desktop
Then KPolygon is run as the screen saver despite Enabled=false.
As a further test:
Enabled=false
Saver=
The screen went blank and the dialog appeared when expected. I did not check my process list but I presume the blank screen saver activated. Matching that behavior seems good. That is, something like this:
if UseUnmanagedLockWindows==true
// Use old style dialog
{
if Enabled==false && Saver==something
activate something;
else if Enabled==false && Saver==empty
activate blank;
}
My apologies for my noob C++ skills. :-)
Regarding the kwriteconfig quirk, I never checked kdesktoprc to validate the change took, regardless of the bug behavior. I just checked that and the change does takes place. Therefore the problem is only the conflict of the two settings and kwriteconfig is not involved.
I haven't yet tested the other fixes. Getting there.... :-)
Oops. I see you already pushed a patch. I'll test again. (In reply to comment #29) > A remaining catch to all of this is when Enabled=false then the code has to > select a screen saver, which the default blank screen should suffice. Should it? My thought on the matter is that if the screen saver is disabled for kdesktop via the kcontrol module, then the screen saver should be disabled for that entire session, including while the desktop lock is active. This might be done, for instance, to save resources on multi-user remote desktop systems, or for any other case where a screen saver is simply not wanted, but the desktop lock itself is needed. We're probably describing the same goal. :-) Substitute "blank screen saver" in everything I wrote to "blank screen." They probably are not the same event yet provide the same effect. My thinking is when the user locks the screen with DelaySaverStart=false, that the dialog does not appear right away, regardless of which dialog is being used. That would mean a blank screen for when Enabled=false and a blank screen saver for when Enabled=true and Saver=Blank. Is that better? (In reply to comment #32) > We're probably describing the same goal. :-) Substitute "blank screen saver" in > everything I wrote to "blank screen." They probably are not the same event yet > provide the same effect. > > My thinking is when the user locks the screen with DelaySaverStart=false, that > the dialog does not appear right away, regardless of which dialog is being > used. That would mean a blank screen for when Enabled=false and a blank screen > saver for when Enabled=true and Saver=Blank. > > Is that better? I understand what you are saying, but it still doesn't make sense to me. if the saver is disabled, then the lock dialog should be shown 24/7 with no saver, no fake blanking, etc., in effect giving DPMS full control of any blanking/sleep/standby modes needed. In effect, I am saying that DelaySaverStart should only have any effect when a screen saver is actually configured and enabled. If the screen saver is completely disabled, then it should have no effect whatsoever. Make sense? :-) Okay --- when Enabled=false then DelaySaverStart is ignored. I understand. Now try this: DelaySaverStart=false Enabled=false UseUnmanagedLockWindows=true I understand that DelaySaverStart is ignored. Select the Lock applet icon and the screen goes blank immediately. Oops. The old style dialog should appear immediately. Keep those settings and change UseUnmanagedLockWindows=false. The dialog appears immediately as expected. Something is not quite right with the old dialog && DelaySaverStart=true. :( Regarding the previous hang problem with the following settings: [ScreenSaver] DPMS-dependent=true DelaySaverStart=true Enabled=false Lock=false LockGrace=60000 Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 UseUnmanagedLockWindows=true No lock up. Screen goes blank but the dialog appears when prompted. Fixed. (In reply to comment #34) > Something is not quite right with the old dialog && DelaySaverStart=true. :( I meant old dialog (UseUnmanagedLockWindows=true) and Enabled=false. (In reply to comment #34) > Okay --- when Enabled=false then DelaySaverStart is ignored. I understand. > > Now try this: > > DelaySaverStart=false > Enabled=false > UseUnmanagedLockWindows=true > > I understand that DelaySaverStart is ignored. Select the Lock applet icon and > the screen goes blank immediately. Oops. The old style dialog should appear > immediately. > > Keep those settings and change UseUnmanagedLockWindows=false. The dialog > appears immediately as expected. > > Something is not quite right with the old dialog && DelaySaverStart=true. :( Quite possible as I personally switched to the "new" system some time ago and never looked back. :-) I'll see what I can do to replicate/fix the problem. (In reply to comment #34) > I understand that DelaySaverStart is ignored. Select the Lock applet icon and > the screen goes blank immediately. Oops. The old style dialog should appear > immediately. On further thought, how does this behavior deviate from the old KDE3 behavior? The whole purpose of the UnmanagedWindow option is to restore the exact same behavior that was present in KDE3. Yeah, on further thought perhaps there is no difference. :-) Latest patch testing update: ======================================================================= useSAK=true The Secure Desktop Area dialog does not show root's account name in the dialog. Just the single quotation marks with nothing in between. Non root account names appear as expected. ======================================================================= The Logoff Menu button. I now see the "Confirm logout" dialog. I have Confirm logout disabled. When I do not press Ctrl-Alt-Delete and logout through other options, then the Confirm logout dialog does not appear. The two methods function differently, but seems to me that when a person purposely disables Confirm Logout that pressing Ctrl-Alt-Delete should perform as before and just log out. Perhaps the Logout Menu button should be disabled/ghosted when ksmserverrc:confirmLogout=false? Or the button does not appear at all when ksmserverrc:confirmLogout=false? ======================================================================= The busy cursor with the Secure Desktop Area dialog. Steps to reproduce: useSAK=true DelaySaverStart=true/false UseUnmanagedLockWindows=false Press Ctrl-Alt-Delete. Select Lock Session. Mouse pointer icon is busy. ======================================================================= Bug: useSAK=true DelaySaverStart=false UseUnmanagedLockWindows=false Enabled=true The Secure Desktop Area dialog appears and the background goes blank/black. Seems to me the background should not go blank/black, nor should the screen saver should kick in -- yet. I'm using the polygon screen saver, which has a black background. I suspect the screen saver barely activates when the modal dialog appears, which freezes the screen saver. To me, DelaySaverStart=true means: When UseUnmanagedLockWindows=false, the Secure Desktop Area dialog appears, the background does not go blank/black (screen saver does not yet activate). When the user selects Lock Session, then DelaySaverStart=true takes effect. When UseUnmanagedLockWindows=true, because there is no related dialog asking the user what to do next, then DelaySaverStart=true takes effect immediately and the screen saver activates when enabled. Change DelaySaverStart=true and the background does not go blank until after selecting Lock Session, as expected. I had the screen saver delay set to 60 seconds and this time the screen saver appeared. Fixed. ======================================================================= Bug: TDM/startx useSAK=true/false DelaySaverStart=true UseUnmanagedLockWindows=false Enabled=true Saver=KPolygon.desktop Timeout=60 Pressing the Lock Session button (or pressing Ctrl-Alt-L): Background goes gray. Ctrl-Alt-Delete dialog appears. Mouse cursor is not busy. 60 seconds later the screen goes black. The screen saver never activates. TDM/startx useSAK=true/false DelaySaverStart=true/false UseUnmanagedLockWindows=true/false Enabled=true Saver=KPolygon.desktop Timeout=60 Pressing the Lock Session button (or pressing Ctrl-Alt-L): Background goes black immediately. The screen saver never activates. ======================================================================= In command line login mode (startx), I still momentarily see the SAK dialog before seeing the lock desktop dialog. Can we add a simple test whether TDM is running? If not running then don't try to display the TSAK dialog. (In reply to comment #39) > Latest patch testing update: > > ======================================================================= > useSAK=true > > The Secure Desktop Area dialog does not show root's account name in the dialog. > Just the single quotation marks with nothing in between. Non root account names > appear as expected. This works here (I get 'root' in the dialog). You may need to debug why KUser is not populated as root on your system. > ======================================================================= > The Logoff Menu button. I now see the "Confirm logout" dialog. I have Confirm > logout disabled. When I do not press Ctrl-Alt-Delete and logout through other > options, then the Confirm logout dialog does not appear. The two methods > function differently, but seems to me that when a person purposely disables > Confirm Logout that pressing Ctrl-Alt-Delete should perform as before and just > log out. Perhaps the Logout Menu button should be disabled/ghosted when > ksmserverrc:confirmLogout=false? Or the button does not appear at all when > ksmserverrc:confirmLogout=false? The button in kdesktop brings up the menu regardless of the configuration option. It is also labelled "Logoff Menu", so I don't see a problem here. > ======================================================================= > The busy cursor with the Secure Desktop Area dialog. Steps to reproduce: > > useSAK=true > DelaySaverStart=true/false > UseUnmanagedLockWindows=false > > Press Ctrl-Alt-Delete. > Select Lock Session. > Mouse pointer icon is busy. Interesting. It seems to need an X11 event to jar it into action. Definitely a bug. :-) > ======================================================================= > Bug: > > useSAK=true > DelaySaverStart=false > UseUnmanagedLockWindows=false > Enabled=true > > The Secure Desktop Area dialog appears and the background goes blank/black. > Seems to me the background should not go blank/black, nor should the screen > saver should kick in -- yet. I'm using the polygon screen saver, which has a > black background. I suspect the screen saver barely activates when the modal > dialog appears, which freezes the screen saver. > > To me, DelaySaverStart=true means: > > When UseUnmanagedLockWindows=false, the Secure Desktop Area dialog appears, the > background does not go blank/black (screen saver does not yet activate). When > the user selects Lock Session, then DelaySaverStart=true takes effect. > > When UseUnmanagedLockWindows=true, because there is no related dialog asking > the user what to do next, then DelaySaverStart=true takes effect immediately > and the screen saver activates when enabled. > > Change DelaySaverStart=true and the background does not go blank until after > selecting Lock Session, as expected. > This is more likely to be a bug in how kdesktop_lock is grabbing the desktop image than a screensaver issue. For security reasons, kdesktop_lock forces the background to black if it is unable to successfully get a "pretty" background. > > ======================================================================= > Bug: > > TDM/startx > useSAK=true/false > DelaySaverStart=true > UseUnmanagedLockWindows=false > Enabled=true > Saver=KPolygon.desktop > Timeout=60 > > Pressing the Lock Session button (or pressing Ctrl-Alt-L): > > Background goes gray. Ctrl-Alt-Delete dialog appears. > Mouse cursor is not busy. > 60 seconds later the screen goes black. > The screen saver never activates. > > TDM/startx > useSAK=true/false > DelaySaverStart=true/false > UseUnmanagedLockWindows=true/false > Enabled=true > Saver=KPolygon.desktop > Timeout=60 > > Pressing the Lock Session button (or pressing Ctrl-Alt-L): > > Background goes black immediately. > The screen saver never activates. Stupid question: does the screen saver work when you use the Preview button in the screen saver kconfig module, or does it just give you a black screen? > ======================================================================= > In command line login mode (startx), I still momentarily see the SAK dialog > before seeing the lock desktop dialog. > > Can we add a simple test whether TDM is running? If not running then don't try > to display the TSAK dialog. Why not just set useSAK=false in your tdm config file? kdesktop_lock tries to shave some time off of the lock dialog appearing by not performing these relatively slow checks. Tim (In reply to comment #40) > Stupid question: does the screen saver work when you use the Preview button in > the screen saver kconfig module, or does it just give you a black screen? Never mind, I can replicate the problem here. Tim (In reply to comment #41) > (In reply to comment #40) > > Stupid question: does the screen saver work when you use the Preview button in > > the screen saver kconfig module, or does it just give you a black screen? > > Never mind, I can replicate the problem here. > > Tim The various screen saver engage problems should be fixed in GIT hash 601b75a, as well as the Secure Area lock problem. Regarding root: I found the problem: my passwd file did not have a name defined for root, only the account. Ctrl-Alt-Delete: My concern is not the code, which seems to work as intended, nor the name of the button, which with recent patching now matches actual behavior. My concern is that with KDE3, pressing Ctrl-Alt-Delete, with ksmserverrc:confirmLogout=false, simply logged out the user. No dialog. That behavior is now gone. With the new dialog this no longer happens when pressing Ctrl-Alt-Delete. When a user disables "Confirm logout," then that is what the person wants --- not to be annoyed with Yet Another Dialog. :-) The new behavior is inconsistent with the other methods available for logging out. Those other methods do not invoke the new dialog. Only pressing Ctrl-Alt-Delete invokes the new dialog, ignoring that ksmserverrc:confirmLogout=false. All I am asking is whether a logic condition can be added: if ksmserverrc:confirmLogout=false then don't show the new dialog. Just log out. Black/blank backgrounds: Users expect to see their screen saver. The screen saver never activates at all. That is the only point with those observations. useSAK=true with startx: I forgot to test useSAK=false while starting with startx. The TSAK dialog appears only momentarily and most people are unlikely to notice at all. People using slower hardware will see the dialog. I see the dialog and I have fairly fast hardware. The momentary appearance is harmless but --- "unprofessional." We often discuss how we want Trinity provide a professional or high quality impression. Image does count. :-) For myself, yes, I am unlikely ever to use TSAK because I always log in from the command line with startx. Yet I test these things in the spirit of helping the project. :-) If I installed systems for other people, I know they want a login manager. They won't see the momentary dialog because that happens only with startx. So those who see this momentary appearance are in the minority but remember that those who run systems that way are likely to be more technically competent and knowledge about computers. The impression they receive when they see that momentary dialog? I don't know. I am rebuilding now and will report later with the latest patches. :-) BTW, for the record to whom ever reads the discussions in this bug report, the interaction of all these elements and dialogs is complicated. Very complicated. I tend to be thorough with my testing, which includes corner cases. Corner cases in any engineering challenge are always difficult to resolve. There is good reason why the two of us have proceeded slowly and with a ton of patience. (In reply to comment #43) > Regarding root: I found the problem: my passwd file did not have a name defined > for root, only the account. > > Ctrl-Alt-Delete: My concern is not the code, which seems to work as intended, > nor the name of the button, which with recent patching now matches actual > behavior. My concern is that with KDE3, pressing Ctrl-Alt-Delete, with > ksmserverrc:confirmLogout=false, simply logged out the user. No dialog. That > behavior is now gone. With the new dialog this no longer happens when pressing > Ctrl-Alt-Delete. Here's my position, let me know if it makes sense. First, you can get the old behavior back by disabling TSAK. Second, I have always disagreed with KDE's mapping of Ctrl+Alt+Del to "save session and logout". Ctrl+Alt+Del always does a fast reboot of the machine itself (BIOS/DOS/Window$!=NT/Linux) outside of TDE, and training users to press Ctrl+Alt+Del to log out (only partially consistent with the key sequence's original function), then providing a configuration option to do this with no prompting whatsoever, was not really the brightest of moves from KDE IMO. My thoughts are that Ctrl+Alt+Del is a unique reserved break sequence that only privileged processes should be aware of (hence the design of TSAK) and act on, as this matches the behavior of Ctrl+Alt+Del across the history of PC compatible systems. I know there is some weak precedent set here, and I want to reverse that precedent to some extent to be more logical and consistent. Would it be better if there was a new fast logout button provided on the Secure Dialog below the Lock Screen button? > Black/blank backgrounds: Users expect to see their screen saver. The screen > saver never activates at all. That is the only point with those observations. This should be fixed, is it still not working? > useSAK=true with startx: I forgot to test useSAK=false while starting with > startx. > > The TSAK dialog appears only momentarily and most people are unlikely to notice > at all. People using slower hardware will see the dialog. I see the dialog and > I have fairly fast hardware. The momentary appearance is harmless but --- > "unprofessional." We often discuss how we want Trinity provide a professional > or high quality impression. Image does count. :-) > > For myself, yes, I am unlikely ever to use TSAK because I always log in from > the command line with startx. Yet I test these things in the spirit of helping > the project. :-) If I installed systems for other people, I know they want a > login manager. They won't see the momentary dialog because that happens only > with startx. So those who see this momentary appearance are in the minority but > remember that those who run systems that way are likely to be more technically > competent and knowledge about computers. The impression they receive when they > see that momentary dialog? I don't know. I very much agree on the image aspect of this discussion. I am actually a bit stuck as I cannot really fix it even if I wanted to due to the fact that this chunk of code is a partially privileged security system--i.e. kdesktop_lock, executing as a normal user, literally CANNOT read the status of tsak (without guessing based on a PID, which is bad practice and may fail randomly) without asking its privileged intermediary (running suid root) about the status of tsak. This would likely introduce a noticeable second or two delay as the query process is loaded, TSAK is queried, the process unloads, and the monitoring process is then loaded, finally displaying the dialog. During this time the lock dialog would appear to be busy and display nothing except the background image or black screen. This convoluted process may very well be needed, I just wanted to point out that things are not as simple as "just checking for tsak". :-) > BTW, for the record to whom ever reads the discussions in this bug report, the > interaction of all these elements and dialogs is complicated. Very complicated. No kidding! This is one reason KDE4 simplified everything--there is an old adage that 10% of the users use 90% of the features, and this lock system definitely falls into that category from what I am picking up. However, if all FOSS projects decided not to support that 10% of the userbase (mainly working professionals), Linux would not be available for any serious use in the enterprise environment at this time. Tim > This convoluted process may very well be needed, I just wanted to point out
> that things are not as simple as "just checking for tsak". :-)
Now implemented in GIT hash 22d0a67.
Tim
Note: I seem unable to use kwriteconfig to change the three keys with no GUI controls. Seems the only way I can achieve consistent results is to perform each test once, exit the session, edit kdesktoprc, delete the ksycoca cache, and start a new session for the next test. Possibly adding the GUI controls might help because that theoretically forces the session to refresh. Nonetheless, over the past several days I notice whenever I try to test different settings, often I do not achieve the consistent result. After restarting and deleting the cache then I seem to achieve consistent results. Using startx UseUnmanagedLockWindows=false useSAK=true No momentary TSAK dialog appears. :-) Using startx UseUnmanagedLockWindows=true useSAK=irrelevant DelaySaverStart=irrelevant Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. Old dialog appears when prompted. DelaySaverStart=irrelevant Enabled=false Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. Is this correct when Enabled=false? Or should the screen go blank? Old dialog appears when prompted. DelaySaverStart=irrelevant Enabled=false UseUnmanagedLockWindows=true All other keys deleted. Locking the desktop: screen goes blank. Old dialog appears when prompted. Using startx UseUnmanagedLockWindows=false useSAK=irrelevant DelaySaverStart=true Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: New dialog appears. Screen saver starts 60 seconds later. DelaySaverStart=false Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. New dialog appears when prompted. Using TDM UseUnmanagedLockWindows=true useSAK=true DelaySaverStart=false Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. Old dialog appears when prompted. DelaySaverStart=true Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. Old dialog appears when prompted. DelaySaverStart=true Enabled=false Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. Is this correct when Enabled=false? Or should the screen go blank? Old dialog appears when prompted. DelaySaverStart=true Enabled=false UseUnmanagedLockWindows=true All other keys deleted. Locking the desktop: screen goes blank. Old dialog appears when prompted. Using TDM UseUnmanagedLockWindows=false useSAK=true DelaySaverStart=false Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: kpolygon screen saver starts immediately. TSAK dialog appears when prompted. New dialog appears after pressing Ctrl-Alt-Delete. DelaySaverStart=true Enabled=true Saver=KPolygon.desktop ShowLockDateTime=true Timeout=60 Locking the desktop: TSAK dialog appears. kpolygon screen saver starts 60 seconds later. TSAK dialog appear when prompted. New dialog appears after pressing Ctrl-Alt-Delete. Using TDM UseUnmanagedLockWindows=false useSAK=true Pressing Ctrl-Alt-Delete: Secure Desktop Area dialog appears. Cancel button works. Task Manager button works. Logoff Menu button works. DelaySaverStart=true Lock Session button: TSAK dialog appears. Screen saver starts 60 seconds later. TSAK dialog appear when prompted. New dialog appears after pressing Ctrl-Alt-Delete. DelaySaverStart=false Lock Session button: Screen saver starts immediately. TSAK dialog appear when prompted. New dialog appears after pressing Ctrl-Alt-Delete. DelaySaverStart=false Enabled=false Saver=KPolygon.desktop Lock Session button: Screen saver starts immediately. Is this correct when Enabled=false? Or should the screen go blank? TSAK dialog appear when prompted. New dialog appears after pressing Ctrl-Alt-Delete. Conclusion: All seems to be working, except the possibility of the screen saver starting when Enabled=false and Saver=something. I don't see that as a bug per se. More of a curiosity. I'm just reporting what I saw. :-) No unexpected busy mouse pointers observed in these tests. I understand the desire to use Ctrl-Alt-Delete as a privileged key sequence. There is some merit to the argument. Yet the proverbial damage has been done. Trinity users previously were KDE3 users and Ctrl-Alt-Delete is the keyboard shortcut for logging out. The challenge is somewhat similar to what tech writers face with registered trademarks. Most people call tissues Kleenex but tech writers know better and know to change such usage. Yet tech writers know they can't stop everybody from saying Kleenex. Xerox/photocopy is another example, as is "right-click." Although Ctrl-Alt-Delete has somewhat a tradition of being reserved for privileged sequences, what is done is done. Asking KDE3/Trinity users to change might start a riot. :-) I still hope that Ctrl-Alt-Delete could go straight to the logout without a dialog --- but only when ksmserverrc:confirmLogout=false. In the possible desktop combinations: TDM/startx, useSAK=true/false, only TDM/useSAK=true introduces a dialog when the user presses Ctrl-Alt-Del. The other three modes logout without event. In all modes I can select the Logout applet button, Log Out from the TDE menu, Log Out from the desktop context menu and I am not presented with the dialog. Those three options require a mouse. I use all four methods regularly and just as often as not, my hands are on the keyboard when I want to logout. Only in the one desktop mode does pressing Ctrl-Alt-Delete invoke the dialog. This mode seems inconsistent when compared to the other modes, but I agree that is not a good argument. The real argument is how will admins configure their computers and that then becomes the consistent mode for all affected users. Likewise for single home users. If the user wants the full TSAK layer, then the user sees that as consistent. I probably have less weight to throw into this specific discussion because I am a startx user, which renders useSAK=irrelevant to me. If I did use TDM, or I setup and configured systems for other people, I would not use TSAK simply because I don't need that level of security here and most people don't either. TSAK is targeted at a vertical set of users who need that security. Thus I'm admitting that except in testing, I am unlikely to ever be annoyed by the dialog because in the other modes when I press Ctrl-Alt-Delete I logout with no dialog. As the old saying goes, I really don't have a dog in the fight. I'm just sharing my observations after several straight days of "grueling" testing. As I mentioned previously, my reasoning is simple: When a user disables "Confirm logout," then that is what the person wants --- not to be bothered with a dialog. I'm still in favor of no dialog when ksmserverrc:confirmLogout=false. With that all said, you decide. :-) You've done a helluva job getting TSAK and locking to work well! Remaining items to close this bug report: * Whether to add a logic test for ksmserverrc:confirmLogout=false. * Whether the screen saver starting when Enabled=false and Saver=something is a bug. > With that all said, you decide. :-) I'm going to keep the current behavior, as those who want to use Ctrl+Alt+Del to log out with no warning should just disable SAK support IMHO, as they are already using the standard SAK combination for a non-secure purpose. > You've done a helluva job getting TSAK and locking to work well! Thanks! :-) > Remaining items to close this bug report: > > * Whether to add a logic test for ksmserverrc:confirmLogout=false. As stated above, I'm not going to do this. Users can still disable SAK to get the old behavior back. > * Whether the screen saver starting when Enabled=false and Saver=something is a > bug. This should be fixed in GIT hash c5ad26a. I'm going to tentatively close this bug report. If you run another set of tests and find that something broke due to hash c5ad26a, please reopen this report! Release 3.5.13.1 On my notebook Ctr+Alt+Del don't work yet and I can not login. Possible I will to constrain for return my patch for direct Ctr+Alt+Del processing. I have update now my kdebase to current branch v3.5.13-sru and again try enable TSAK for it's current state check: - At once TSAK enable into kdmctl will been started three process tsak and keys combination Ctr+Alt+Del lock and do not work for main function - call exit dialog; - After reboot I have TSAK dialog before KDM and Ctr+Alt+Del do not work and no one tsak process executed in this time. My KDM work into theme mode. On my test machine I have KDM in classic mode - without theme. Strangeness with three running tsak I see too. However, Ctrl+Alt+Del for me works without any problems. (In reply to comment #58) > On my test machine I have KDM in classic mode - without theme. Strangeness with > three running tsak I see too. However, Ctrl+Alt+Del for me works without any > problems. I think what you are seeing is normal behaviour. tsak forks one process for each keyboard device detected on your system, and also forks one master process which monitors for keyboard hotplug events. Therefore, if your system advertises two keyboard devices (which is not that uncommon) you would see three tsak processes. (Odpověď na komentář #59)
> (In reply to comment #58)
> > On my test machine I have KDM in classic mode - without theme. Strangeness with
> > three running tsak I see too. However, Ctrl+Alt+Del for me works without any
> > problems.
>
> I think what you are seeing is normal behaviour. tsak forks one process for
> each keyboard device detected on your system, and also forks one master process
> which monitors for keyboard hotplug events. Therefore, if your system
> advertises two keyboard devices (which is not that uncommon) you would see
> three tsak processes.
My test machine is a virtual machine in a Linux KVM. It has a single keyboard. When I looked into /proc/_number_/fd which /dev/input/ every single tsak uses, I see that all thee have as fifth handle /dev/input/event0. It does not seem like normal behavior.
(In reply to comment #60) > (Odpověď na komentář #59) > > (In reply to comment #58) > > > On my test machine I have KDM in classic mode - without theme. Strangeness with > > > three running tsak I see too. However, Ctrl+Alt+Del for me works without any > > > problems. > > > > I think what you are seeing is normal behaviour. tsak forks one process for > > each keyboard device detected on your system, and also forks one master process > > which monitors for keyboard hotplug events. Therefore, if your system > > advertises two keyboard devices (which is not that uncommon) you would see > > three tsak processes. > > My test machine is a virtual machine in a Linux KVM. It has a single keyboard. > When I looked into /proc/_number_/fd which /dev/input/ every single tsak uses, > I see that all thee have as fifth handle /dev/input/event0. It does not seem > like normal behavior. Interesting! Can you do the following for me in a terminal as root and post the output? killall -9 tsak /opt/trinity/bin/tsak There will be a bit of debug spew that will terminate with something along the lines of "Hotplug monitoring process started". This output will include everything I should need to know if tsak is working normally or if there is a glitch. Thanks! (Odpověď na komentář #61)
> Interesting!
>
> Can you do the following for me in a terminal as root and post the output?
>
> killall -9 tsak
> /opt/trinity/bin/tsak
>
> There will be a bit of debug spew that will terminate with something along the
> lines of "Hotplug monitoring process started". This output will include
> everything I should need to know if tsak is working normally or if there is a
> glitch.
>
> Thanks!
# killall -9 tsak
# /opt/trinity/bin/tsak
[tsak] Found 1 keyboard(s)
[tsak] Reading from keyboard: (AT Translated Set 2 keyboard)
[tsak] AT Translated Set 2 keyboard+tsak
[tsak] Device created.
[tsak] Hotplug monitoring process started
Although correctly listed one keyboard, again runs three processes.
(In reply to comment #62) > (Odpověď na komentář #61) > > Interesting! > > > > Can you do the following for me in a terminal as root and post the output? > > > > killall -9 tsak > > /opt/trinity/bin/tsak > > > > There will be a bit of debug spew that will terminate with something along the > > lines of "Hotplug monitoring process started". This output will include > > everything I should need to know if tsak is working normally or if there is a > > glitch. > > > > Thanks! > > # killall -9 tsak > # /opt/trinity/bin/tsak > [tsak] Found 1 keyboard(s) > [tsak] Reading from keyboard: (AT Translated Set 2 keyboard) > [tsak] AT Translated Set 2 keyboard+tsak > [tsak] Device created. > [tsak] Hotplug monitoring process started > > Although correctly listed one keyboard, again runs three processes. I was slightly incorrect in my earlier reply; in fact each keyboard requires two processes, one for input (keys to X11) and one for output (LED commands to keyboard). Adding in the hotplug monitoring process gives three processes, exactly as described. The only way to alleviate this cosmetic issue would be to move to threading, however this would be quite a bit of work with possible instability for minimal gain. (Odpověď na komentář #63) > I was slightly incorrect in my earlier reply; in fact each keyboard requires > two processes, one for input (keys to X11) and one for output (LED commands to > keyboard). Adding in the hotplug monitoring process gives three processes, > exactly as described. > > The only way to alleviate this cosmetic issue would be to move to threading, > however this would be quite a bit of work with possible instability for minimal > gain. Ah, this explains the situation. For me, in this case everything is working properly. So it is necessary to examine the behavior kdm/tdm with theme - reported in comment 57. (In reply to comment #58) > On my test machine I have KDM in classic mode - without theme. Strangeness with > three running tsak I see too. However, Ctrl+Alt+Del for me works without any > problems. For me no different for classic and theme KDM. For all: - No the tsak processes start on kdm start. In my system configuration kdm link lying and used from /usr/bin/kdm where I also try place tsak link. Where into the sources place for start the tsak processes for test? - If I enable tsak into kdmctl then Ctrl+Alt+Del strong lock the combination for generic functions. Besides if I logout the session I take tsak dialog and three tsak process but the combination also do not work. My system has UDEV version 168, which yet working with HAL. I have plane for adapt HAL to udev(systemd)-197. For now hal work without events notifications from udev by deprecated support that through socket by rule "socket:@/org/freedesktop/hal/udev_event". Then I can see to tsak using udev for events observing and next will use that into hal. (In reply to comment #65) > For me no different for classic and theme KDM. For all: > - No the tsak processes start on kdm start. In my system configuration kdm link > lying and used from /usr/bin/kdm where I also try place tsak link. Where into > the sources place for start the tsak processes for test? > - If I enable tsak into kdmctl then Ctrl+Alt+Del strong lock the combination > for generic functions. Besides if I logout the session I take tsak dialog and > three tsak process but the combination also do not work. My system has UDEV > version 168, which yet working with HAL. I also have tested and have the problems on last UDEV(197) and XOrg. Possible there is distributive specific problem for ALTLinux. I can build LiveCD/USB for easy reproduce its for your and possible place here http://www.trinitydesktop.org/wiki/bin/view/Documentation/LiveCDs . > > - If I enable tsak into kdmctl then Ctrl+Alt+Del strong lock the combination
> > for generic functions.
TSAK lock not only Ctrl+Alt+Del into X-session and also into console but holding keys repeating lock also.
(In reply to comment #66) > ... I can build LiveCD/USB for > easy reproduce its for your and possible place here > http://www.trinitydesktop.org/wiki/bin/view/Documentation/LiveCDs . My LiveCD/USB build here: ftp://ftp.oscada.org/OpenSCADA/Work/ALTLinux/Live/ALTLinux_6-OpenSCADA_0.8.1-TDE_3.5.13.1-i586-LiveCD_USB.iso (In reply to comment #67) > > > - If I enable tsak into kdmctl then Ctrl+Alt+Del strong lock the combination > > > for generic functions. > TSAK lock not only Ctrl+Alt+Del into X-session and also into console but > holding keys repeating lock also. This behaviour is by design. If you do not wish Ctrl+Alt+Del to be reserved as a system-wide secure attention key, then do not enable tsak. Upon review of this bug report, I have determined that the issues first reported have already been resolved. I am marking this report as RESOLVED FIXED; while I cannot lock the report, please do not change its status again. New bugs should be filed where needed, as this report is growing long and unwieldy. Roman, please open a new bug report for the tsak issues you have reported. This report is not the correct forum to discuss those loosely related issues, and appending them to this report only serves to hinder classification of bug severity and makes future discussion and possible resolution of the new bug more difficult. |
Created attachment 480 [details] SAK realization into KDM fix patch - Disable SAK from config file (by UseSAK=false) do not work. - Exit from wait dialog by Ctr+Alt+Del do not work. - High CPU consumption on wait SAK. Patch for fix the problems included. Also SAK dialog have problems into Screen lock. Real I see SAK dialog flashing before Screen unlock dialog.