[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screensavers for the console

From: Michal 'hramrach' Suchanek
Subject: Re: Screensavers for the console
Date: Wed, 14 May 2003 15:08:08 +0200
User-agent: Mutt/1.4i

On Sun, May 11, 2003 at 01:22:33AM +0200, Marcus Brinkmann wrote:
> The interface should be restricted to events.  I think you only need one
> interface for screensaver drivers (but for clarity it could be split into
> three functions):
> error_t screensaver_event (event_type event);
> where event is one of SLEEP/POWER-OFF/WAKEUP (for example).  The program
> gets an option
> --screensave-sleep=[time1]/--screensave-power-off=[time2]/--screensave-wakeup-at=[event]
> [event] being "keypress", "output", or whatever (multiple allowed).
> Then the generic code installs a timer for time1 which stops regular updates
> and calls the screensaver_event(SLEEP), and a timer for time2 which stops
> regular updates and calls the screensaver_event(POWER-OFF).  The various
> places where input and output are handled check the current screensaving
> mode and if it is yes, and if the corresponding wakeup-at option is given,
> they call a console_Wakeup function which signals the screensaver_event
> (WAKEUP), enables regular output, refreshes the screen and reinstalls the
> timers.  This is approximately what I think would be a light-weight and
> generic screensaver interface (and, in fact, I have now given most
> details of an implementation, too).

What about console locking? In FreeBSD and GNU/Linux this is independent of
console screensaver. But for X it comes in one package. But there is built-in
screensaver in XFree86 without locking, too.

The question is: should the locking be implemented somewhere in the console, 
in the screensaver, or as a separete application?

A separate application that sits on a terminal until it receives a password or
is killed should be easy.

Implementing some support in the console itself would make it possible to
lock/unlock several virtual terminals at once. But it would have to know about
users logged in at the terminals. Afaik it does not care now.

Locking in screensaver would be probably worst choice in this context because
it has the limitation of standalone application but it may be executed
with an identitiy different from the user that is logged in at the terminal.
And it would require separate screensaver for every virtual terminal.

Michal Suchanek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]