Is it KDE's job to secure the screen/keyboard behavior when suspending to RAM or disk?
I've noticed that on wake, with a password required for wake, that the screen before sleeping is visible before it's blanked. Also, sometimes I can send keyboard input to the system before the blanked screen kicks in. The window of opportunity is pretty small for typing, and I can only read the screen for a few seconds, but it's not a secure wake. I'm testing this on a netbook which takes its sweet time doing anything.
Anyway, I don't really know which part of the stack should be handling this - wanted to get some feedback before filing inappropriate bugs.
Thanks, -Bill
On Wed, 2009-09-16 at 01:34 -0400, Bill McGonigle wrote:
Is it KDE's job to secure the screen/keyboard behavior when suspending to RAM or disk?
I've noticed that on wake, with a password required for wake, that the screen before sleeping is visible before it's blanked. Also, sometimes I can send keyboard input to the system before the blanked screen kicks in. The window of opportunity is pretty small for typing, and I can only read the screen for a few seconds, but it's not a secure wake. I'm testing this on a netbook which takes its sweet time doing anything.
Same here. It looks like KDE resumes, then detects the wakeup signal and decides it should lock the screen. The effect is definitely counterintuitive. It would be interesting to know if Gnome has the same behaviour.
poc