[Top][All Lists]

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

Re: Screensavers for the console

From: M. Gerards
Subject: Re: Screensavers for the console
Date: Sun, 11 May 2003 01:05:03 +0200
User-agent: Internet Messaging Program (IMP) 3.1

Quoting Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:

> On Sun, May 11, 2003 at 12:00:30AM +0200, M. Gerards wrote:
> > /* Start the screensaver.  */
> > error_t ssaver_start (void);
> > 
> > /* Stop the screensaver.  */
> > error_t ssaver_stop (void);
> I would like to see several stages, that correspond to modern power saving
> facilities of display hardware.

What do you mean? Which stages? These functions are called by the graphics
driver to display the graphics the screensaver has to show.

> > /* Kind of states that should be saved/restored with
> >    display_save_state and display_restore_state.  */
> Nothing is saved.  After a wakeup event, the generic code will have to do a
> complete refresh.

What if the resolution was changed? (I assumed here that a framebuffer and if
the vga driver would support graphics for screensavers as I proposed the mode
should be restored before switching back to the console).

> > int display_supports_grapics (void);
> graphic support can only be implemented by device specific screensavers
> coming with the graphic display hardware driver.  There has to be a limit,
> and my current limit is that I don't any graphicish in the console
> interfaces.  What happens internal to a display driver, I don't care.
> If you can find a way to have the same screensavers communicate via
> graphicish display drivers over an internal interface, so that
> screensaver_flying_horseshit can be used with a vga and braille driver, then
> I am fine with that.  But that would be opaque to the generic code.

This interface is an internal interface that should be supported only if the
driver supports screensavers like these.
> I believe that any code that handles graphic needs a lot of careful design
> to achieve an acceptable universality and performance.  Again, you are
> talking about an underlying framebuffer interface without actually carrying
> it through.  

The interfaces look universal to me and are high performance, but please correct
me if I'm wrong. 

> Of course, if you want to carry it through, that would be
> great, but I think that would have to be started from scratch, and not put
> half-heartedly on top of the text console.

Can't the framebuffer be implemented as a plugin for the console-client, or
isn't that what you said?


reply via email to

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