Version: (using KDE KDE 3.1.1) Installed from: Debian testing/unstable Packages OS: Linux When a very CPU hungry screen saver is running, the password dialog looses many characters, so you have to type your password very slowly. Please, halt the screensaver while presenting the dialog password. Great work, guys. Best regards.
Subject: kdebase/kdesktop/lock CVS commit by howells: Fix 56803 "Halt the screensaver while asking for the password" May be backportable if somebody is bored. CCMAIL: 56803-done@bugs.kde.org M +6 -0 lockprocess.cc 1.14 --- kdebase/kdesktop/lock/lockprocess.cc #1.13:1.14 @@ -657,4 +657,6 @@ void LockProcess::hackExited( KProcess * bool LockProcess::checkPass() { + setBackgroundColor(black); + stopHack(); PasswordDlg passDlg(this, !mXdmFifoName.isNull()); connect(&passDlg, SIGNAL(startNewSession()), SLOT(startNewSession())); @@ -676,4 +678,8 @@ bool LockProcess::checkPass() XChangeActivePointerGrab( qt_xdisplay(), GRABEVENTS, blankCursor.handle(), CurrentTime); + if (!rt) + { + startHack(); + } return rt; }
Not fixed, will have to revert my attempted fix :(
Subject: kdebase/kdesktop/lock CVS commit by howells: Revert fix to 56803. It breaks screensavers like slidescreen which manipulate the image of the screen before the screen was locked. the only fix I can think of is bitBlt an image of the screen to a QPixmap and bitBlt it back just before the screenaver is re-started, but I've been messing around with this for a few hours this afternoon and haven't been able to get it to work. Grrr. CCMAIL: 56803@bugs.kde.org M +5 -4 lockprocess.cc 1.15 --- kdebase/kdesktop/lock/lockprocess.cc #1.14:1.15 @@ -657,6 +657,7 @@ void LockProcess::hackExited( KProcess * bool LockProcess::checkPass() { - setBackgroundColor(black); - stopHack(); + // This was an attempt to fix 56803, unfortunately it breaks "Slide Screen" and similar + //setBackgroundColor(black); + //stopHack(); PasswordDlg passDlg(this, !mXdmFifoName.isNull()); connect(&passDlg, SIGNAL(startNewSession()), SLOT(startNewSession())); @@ -678,8 +679,8 @@ bool LockProcess::checkPass() XChangeActivePointerGrab( qt_xdisplay(), GRABEVENTS, blankCursor.handle(), CurrentTime); - if (!rt) + /*if (!rt) { startHack(); - } + }*/ return rt; }
Subject: kdebase/kdesktop/lock CVS commit by howells: Thanks Stephan... Using SIGSTOP and SIGCONT seems to be a great way of resolving 56803. There is a little issue that when the password entry dialog disappears, it doesn't get re-painted underneath, but I guess we can live with that. CCMAIL: 56803-done@bugs.kde.org ` M +4 -6 lockprocess.cc 1.18 --- kdebase/kdesktop/lock/lockprocess.cc #1.17:1.18 @@ -658,7 +658,5 @@ void LockProcess::hackExited( KProcess * bool LockProcess::checkPass() { - // This was an attempt to fix 56803, unfortunately it breaks "Slide Screen" and similar - //setBackgroundColor(black); - //stopHack(); + mHackProc.kill(SIGSTOP); PasswordDlg passDlg(this, !mXdmFifoName.isNull()); connect(&passDlg, SIGNAL(startNewSession()), SLOT(startNewSession())); @@ -680,8 +678,8 @@ bool LockProcess::checkPass() XChangeActivePointerGrab( qt_xdisplay(), GRABEVENTS, blankCursor.handle(), CurrentTime); - /*if (!rt) + if (!rt) { - startHack(); - }*/ + mHackProc.kill(SIGCONT); + } return rt; }
I, personally, would not like to see the screen saver stop, but I understand the issue regarding the password entry dialog. A better solution would be to either run the actual screen saver process at a slightly lower priority or run the password check piece of code at a higher priority than the screen saver. This way the password dialog would always be responsive and yet the screen saver doesn't have to stop. There's another issue regarding stopping the screen saver. Some screen savers actually do work in the background. Stopping the screen saver each time the PW dialog appears would not be good. How many times does the PW dialog appear because the mouse moved slightly for whatever reason?