Re: Screensavers for the console

[M. Gerards]

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

> I think that's a bit off.  I don't say that it is unreasonable, but it
> doesn't match what drove the console.
> 
> First, the console itself is independent of mode, and it doesn't support
> graphics per se.  That means that any driver independent code should not
> know about implementation details like graphic modes etc.  For the generic
> interface, the console is a two dimensional array of cells.  Each cells
> holds one unicode character and one attribute struct.  The existing
> attributes are colors, bold, underlined etc.  If you want to add one or two
> attributes bits, then we can talk about that, but graphic mode is a totally
> different concept.  If you want to go in that direction, you should turn it
> upside down, and write a console client which doesn't have the two
> dimensional text cells as underlying assumption, but a framebuffer.  For
> optimization, the framebuffer drivers might still support something like a
> hardware cursor and fast glyph display from a font (by loading the font to
> the video memory, for example), but it would be conceptionally totally
> different.

Ok, that is why I designed the screensaver interfaces this way, to make it
possible to display graphics when available. I just proposed adding graphics
support to the vga driver because it seems like a nice thing to me (Low res.
modes are easy to support and usable on all cards AFAIK). What I proposed is not
something like a framebuffer, a framebuffer will support more fancy graphics.
 
> The other question is how screensavers fit into the console.  There are
> basically two models.  One is driver independent screensavers.  Those would
> be something like: "Clear all screen cells" on sleep, and "Rewrite text
> cells" on wakeup.  Inbetween, you could display fortune cookies, scrollling
> text, unicode animations.  Alternatively, instead clearing the screen, you
> could make the unicode characters drop from the screen, and such things. 
> All this could be implemented without any driver specific code, or changing
> the driver interface, but with the generic functions that exist today.

Please have a look at the interfaces (I forgot to include them with this mail,
I've sent them a few minutes later). They are quite generic and can do all this
and more.

> The other thing is something that really saves something, rather than burn
> CPU cycles.  That would be a driver specific screen saver.  In fact,
> screensavers could be drivers themselves, and some could use the generic
> interface and some hardware specific interfaces (and in some cases a display
> driver would come with its own screensaver drivers because of special
> synchronisation needs, whatever).  For those screenservers, in particular
> blanking and power save mode are worthy.  Only screensavers that ship with a
> display driver could do funky stuff like graphic mode.  If you want a
> generic graphic interface, you are talking about framebuffer support, and
> my opinion on that is above.

Absolutely, I thought about this when I wrote the interfaces:

 /* Switch the display on or off. Set ONOFF to 0 to switch it on and 1
   to switch it on. This function should only be implemented if supported
   by hardware.  */
error_t display_onoff (int onoff);

Perhaps this interface is not needed and it should be handled by the console
client as you proposed because a screensaver and turning of the screen for
powersaving can be handled differently.

Thanks,
Marco