[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?
Thanks,
Marco