Roy Schestowitz wrote:
> Harold Stevens wrote:
>> In <firstname.lastname@example.org> Roy Schestowitz:
>>> a simple way of just approaching a sleeping machine and enter the
>>> password while the CRT's come back to life?
>> Shot in the dark: if this is a typical desktop (mostly idle, especially
>> overnight), have a look at the -delay option in the xlock manpage. As I
>> read it, you might get what you want (immediate keyboard response), and
>> what you don't want (a hogged-out CPU delaying overnight tasks):
>> -delay usecs
>> The delay option sets the speed at which a mode will operate. It
>> simply sets the number of microseconds to delay between batches of
>> animations. In blank mode, it is important to set this to some
>> small number of seconds, because the keyboard and mouse are only
>> checked after each delay, so you cannot set the delay too high,
>> but a delay of zero would needlessly consume cpu checking for
>> mouse and keyboard input in a tight loop, since blank mode has no
>> work to do.
>> I've never tried this myself, but maybe it'll do what you're asking.
>> BTW--might set aside time to glance at the (many) other xlock options.
> That will serve me as an excellent starting point. If this works, I then
> need to worry about how to incorporate this into Control Center. Maybe
> I'll set up a custom accelerator using xbindkeys instead. I'll experiment
> and let you know the outcome.
> many thanks,
Your kind suggestion seems to have solved my problem for good. xlock seems
to leave aside that KDE wrapper (READ: resource hog) and picks up all
keystrokes immediately. I will know for sure tomorrow whether it is
responsive after long periods of sleep. I have just removed the default KDE
shortcut for "lock", namely CTRL+ALT+L. Instead, I use xbindkeys to run
"xlock" with the same key binding.
PS - speaking of KDE hogging resources, Slashdot has just mentioned Plasma
(more eye candy) in KDE. The sites are all down due to the Slashdot effect,
but I snatched an acknowledged copy of the little demo (